Bug#709382: mksh: broken Built-Using handling
Russ Allbery dixit: In the meantime, please don't add Built-Using for libgcc. The libgcc license does not require it, due to the runtime exception, and essentially The dietlibc licence does require for libgcc to be added there (GPL without exception clause). bye, //mirabilos -- Hi, does anyone sell openbsd stickers by themselves and not packaged with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709382: mksh: broken Built-Using handling
Thorsten Glaser t...@mirbsd.de writes: Russ Allbery dixit: In the meantime, please don't add Built-Using for libgcc. The libgcc license does not require it, due to the runtime exception, and essentially The dietlibc licence does require for libgcc to be added there (GPL without exception clause). I think you mean that dietlibc requires that *dietlibc* be added, right? If not, I'm confused. I don't see any reason why dietlibc's license would change something about libgcc's license. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709382: mksh: broken Built-Using handling
Russ Allbery dixit: The dietlibc licence does require for libgcc to be added there (GPL without exception clause). I think you mean that dietlibc requires that *dietlibc* be added, right? No, I meant it like that. If not, I'm confused. I don't see any reason why dietlibc's license would change something about libgcc's license. dietlibc is GPL, so a derivate is also GPL. The mksh-static and lksh binaries, when linked against dietlibc, consist of dietlibc, libgcc and mksh derived source code, but the final binary is the work whose exact sources must be available. bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” -- Tonnerre, psychoschlumpf and myself in #nosec -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709382: mksh: broken Built-Using handling
Thorsten Glaser t...@mirbsd.de writes: Russ Allbery dixit: If not, I'm confused. I don't see any reason why dietlibc's license would change something about libgcc's license. dietlibc is GPL, so a derivate is also GPL. The mksh-static and lksh binaries, when linked against dietlibc, consist of dietlibc, libgcc and mksh derived source code, but the final binary is the work whose exact sources must be available. 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 stub code from libgcc is *always* included statically in every binary, even if the binary is built dynamically. (Or at least there's a good chance that this will happen.) I've never heard the FSF, who are responsible for all the licenses in question, interpret the licenses this way. So I'm quite dubious that this analysis is correct. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709382: mksh: broken Built-Using handling
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 Hmm. stub code from libgcc is *always* included statically in every binary, even if the binary is built dynamically. (Or at least there's a good The csu are included, and TTBOMK some of it comes from GCC and some from the libc in question, so, probably yes. Ouch. I've never heard the FSF, who are responsible for all the licenses in question, interpret the licenses this way. So I'm quite dubious that this analysis is correct. I’m not dubious it’s correct, but it’s likely nobody would care… but I’d rather not be the one making this decision. Whom to involve, d-legal? 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
Bug#709382: mksh: broken Built-Using handling
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
Bug#709382: mksh: broken Built-Using handling
Thorsten Glaser t...@mirbsd.de writes: 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. Debian can't use this exception anyway because of the last clause. Since we *are* a distribution, all the components are considered to accompany the executable. 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”. debian-legal isn't really the correct venue. It's just a discussion list of people who want to talk about legal issues. It has no formal role in license review in the project and frequently arrives at conclusions that the project then doesn't follow. I hadn't thought about it from the angle of the GPL license on the source code to the executable. I knew the exception for the libgcc license let you basically do whatever you want as long as you built with GCC and thought that would be sufficient, and didn't think about the implications of the license on the binary requiring that the libgcc source be available. We probably need to have a broader discussion about this, but I think I'm going to start with leader and see if Lucas has an opinion about where to start with making decisions here. One option available to leader is to ask for an opinion from external legal counsel. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709382: mksh: broken Built-Using handling
Russ Allbery dixit: debian-legal isn't really the correct venue. It's just a discussion list Ah, okay. going to start with leader and see if Lucas has an opinion about where to start with making decisions here. One option available to leader is to ask for an opinion from external legal counsel. That sounds like a good idea. (Were legal reasons the driving force behind adding Built-Using in the first place?) bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in Notes on Programming in C -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709382: mksh: broken Built-Using handling
Thorsten Glaser t...@mirbsd.de writes: (Were legal reasons the driving force behind adding Built-Using in the first place?) Yes, although not this particular issue. There are a set of packages that we build that use other packages as source during the build process. The most common are cross-compilation tool chains, but there are also some externally-maintained GCC frontends that incorporate GCC code at build time, etc. We needed a way to represent that the specific version of, say, GCC incorporated into that build was part of the source and therefore had to be retained in the archive until the binaries built from that source were replaced. At the time, though, the assumption was that Built-Using would be a fairly rare thing that would only be used for those few score packages that were Build-Depending on *-source packages. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709382: mksh: broken Built-Using handling
Russ Allbery dixit: At the time, though, the assumption was that Built-Using would be a fairly rare thing that would only be used for those few score packages that were Build-Depending on *-source packages. And statically linked executables, since that made it into the Policy wording; or possibly, dynamically linked ones that incorporate static libraries from other packages… or Haskell… I think there may be a can of worms or two. I’ve read about the toolchain/-source issues, indeed, but I’m wondering a bit whether a hypothetical statically linked executable from only BSD-licenced sources would need Built-Using (as per current Policy: yes, even though the licences don’t mandate “complete” source availability like the GPL does). Anyway, this probably won’t help us, so I won’t go on with that direction of thought any more. Thanks, //mirabilos -- 08:05⎜XTaran:#grml mika: Does grml have an tool to read Apple ⎜System Log (asl) files? :) 08:08⎜ft:#grml yeah. /bin/rm. ;) 08:09⎜mrud:#grml hexdump -C 08:31⎜XTaran:#grml ft, mrud: *g* -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709382: mksh: broken Built-Using handling
Package: mksh Version: 46-1 Severity: serious Dear Maintainer, The handling of built-using is wrong. It is not meant to encode the compiler used, nor binutils or kernel headers should be recorded there It is specifically for building against -source packages and for hacks like ia32libs where binaries are copied into a source package. Not for 'everything'. What you effectively are doing is asking for a mksh rebuild on each upload of the kernel, of gcc and what else you have put there. Imagine if we all did that. Buildd power. or mirror size. or both. /Sune -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.8-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mksh depends on: ii libc62.17-3 ii libgcc1 1:4.8.0-7 mksh recommends no packages. Versions of packages mksh suggests: ii ed 1.8-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709382: mksh: broken Built-Using handling
Thorsten Glaser t...@mirbsd.de writes: In this specific case, there are one to two statically linked programs there. In some cases, they link statically against a GPL licenced library. So my current interpretation of the text from Policy above says that Built-Using is indeed required there. Per previous discussion on debian-devel, the Policy text is too aggressive and, read literally, encourages people to do things we definitely do not want them to do, such as add Build-Using for libgcc. We need to get the Policy text fixed. In the meantime, please don't add Built-Using for libgcc. The libgcc license does not require it, due to the runtime exception, and essentially every package in the archive would acquire a Built-Using if it were used for libgcc. I haven't looked at the situation for static linking with eglibc or the other libc implementations you reference. The general consensus on debian-devel (at least as I understood it) was to only use Built-Using when there's some licensing reason why we need to keep the referenced package. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
