tl;dr: last paragraph.
Dixi quod… >Russ Allbery dixit: > >>If this license analysis is correct, then we have to do this for every >>binary on the system that's covered by the GPL v2, since I believe some […] >The csu are included, and TTBOMK some of it comes from GCC >and some from the libc in question, so, probably yes. Ah. Got it. GPLv2 §3 says: | control compilation and installation of the executable. However, as a | special exception, the source code distributed need not include | anything that is normally distributed (in either source or binary | form) with the major components (compiler, kernel, and so on) of the | operating system on which the executable runs, unless that component | itself accompanies the executable. This clause is generally interpreted like this: If you link against something normally on the system (kernel, libc, compiler), but don’t put that (as upstream distributing precompiled binaries) into the same distribution as you program linked against it, it need not be GPL. But this interpretation is generally restricted to dynamically linked binaries… So that’s relatively vague. I have no idea whether it may help in general or in the specific case. I’d suggest to ask the FSF (as licence author), Felix von Leitner (as dietlibc author – note I have not analysed eglibc and klibc on whether they also force the mksh-static binary to be GPL), and maybe d-legal whether the distribution of a binary statically linked against dietlibc (GPL), the toolchain (kernel headers and GCC startup files, normally with an exception clause) and the binary’s regular source code (GPL compatible) causes the other parts to become subject to GPLv2 §3 as “complete source code”. Might also be worthwhile to look at Cygwin, whose licence statement interprets (current wording; it seems to change over time, and they switched to GPLv3 in the meantime, but the idea has been there for longer): | The Cygwin™ API library found in the winsup subdirectory of the | source code is also covered by the GNU GPL (with exceptions; see | below). By default, all executables link against this library (and in | the process include GPL'd Cygwin™ glue code). This means that unless | you modify the tools so that compiled executables do not make use of | the Cygwin™ library, your compiled programs will also have to be free | software distributed under the GPL with source code available to all. They basically say: by linking against the import library (eglibc has a rough equivalent in libc_nonshared.a) you always include parts of the library, so it’s GPL. (They have a special exception for open source software, but make actual money from selling commercial licences for people to link their applications against the Cygwin libc.) Now dietlibc contains no such exception, *and* it’s linked statically here, which makes this relatively hard to excuse. (Again, klibc and eglibc would need looking at; currently, I’m treating them the same, except only klibc pulls in linux-libc-dev AFAICT, so the others do not cause it to be added to Built-Using.) As for dynamically (against eglibc and possibly klibc; dietlibc does not currently support it) linked binaries… as far as I can tell, it is like this: The binary itself may be GPL, but for it, the exception causes “anything that is normally distributed” to not be subject to it, so it doesn’t matter. (Binaries linked against GPL libraries will be the same; the GPL library causes the main program, but not the system components, to be GPL – if you follow the FSF interpretation, which Debian does, and not the Python/Usenet one.) The system component itself will have an exception clause, so it doesn’t cause this either. I just looked at klibc: for shared binaries, only interp.o from usr/klibc/interp.S is added, which is so trivial it’s not even copyrightable. (klibc’s “dynamic” link mechanism is……… “different” and tricky. It’s not ELF shared objects.) For eglibc, the situation is well understood AFAIK, and it contains exception clauses for things like crt1.o IIRC. So, current Policy wording may indeed be correct in that it requires the B-U for static executables (even the startup objects part), but not for dynamically linked ones, since those libcs in Debian that do support that either do not infer the GPL on the executable or have exception clauses for that case, and since neither the executable nor any other (non-system, but Debian even considers OpenSSL non- system much to my chagrin, so basically all) libraries it links against cause the GPL to be applied to the system library part. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
