On Friday 11 November 2005 06:48, Anthony Towns wrote: > On Thu, Nov 10, 2005 at 06:07:33PM +0100, David Schmitt wrote: > > > [0] Presuming the FSF's claims about dynamic linking hold up in this > > > case, anyway. > > > > I consider a Debian-derived distribution a derived work of the contained > > Debian tools in more ways than "mere" dynamic linking. > > That doesn't much matter -- Debian doesn't claim any copyright on its > efforts in collecting work, so deriving from Debian doesn't involve any > copyrights but that of the aggregate parts you use. > > The relevant parts are the licenses of individual packages that get > linked against OpenSolaris' libc, and whether libc counts as a "module > [the program] contains" and is thus covered as part of the "complete > source code" as part of paragraph 3(a) of the GPL. > > > To be more specific: I don't believe that the fact that software A is > > being packaged with Debians tools is a derived work of said tools, > > That's not actually the question -- the only "derivative" issue is > that Nexenta's dpkg (eg) is a derivative of Debian's dpkg (or gcc is a > derivative of upstream gcc) and thus covered by the GPL.
"For those playing along at home," this little exchange contains much of my misunderstanding of GPL-matters. After talking this over with Anthony on IRC, I now understand the whole thing better and will try to explain this in more detail: To decide how far the GPL requirements reach, first I have to disassemble the "volume of a storage or distribution medium", since this has no relevance to our question (c.f. "mere aggregation"). I now have a pool of components (typically files). Those compiled from or consisting of GPL'ed source can obviously be tagged as GPL-requiring. If everyone follows the recommendation of embedding the standard GPL disclaimer in the binary, this is trivial by examining the resultant files. For every component now I have to decide whether it "can be reasonably considered independent and separate work" in itself. Obvious examples where this is the case include shell scripts being independent from /bin/sh or documentation being independent from everything else. Source archives by far and large[ex] are independent and separate of each other too. In the case of a source-only distribution, my analysis stops here because all components are now identified as independent and separate works which are "merely aggregated" and the GPL specifically does not apply to this situation. In the case of a binary distribution though, there are components left in the pool which are still to be considered. The interesting case is obviously, when one of those components is tagged as GPL-requiring. Let's consider this dpkg binary from the GNU/Solaris LiveCD, which I have loop mounted: [EMAIL PROTECTED]:/gnusolaris/livecd-mnt/usr/bin$ ./dpkg bash: ./dpkg: No such file or directory [EMAIL PROTECTED]:/gnusolaris/livecd-mnt/usr/bin$ Since the GNU libc I'm running locally is not binary compatible to the Sun libc against which the dpkg binary is linked. This is now the point: the binary is not independent any more and therefore "the same sections [are distributed] as part of a whole [(i.e. /usr/bin/dpkg + /lib/libc.so)] which is a work based on the Program, the distribution of the whole must be on the terms of this License". This means that I need a GPL-compatible component in my pool to satisfy (transitively) all NEEDED[od] linkages to satisfy the GPL-requiring components library to the point of distributability. > > I'd like to add (d) distributing as source only. Compiling the whole > > thing on the users system > > Note that compiling Nexenta involves using gcc, so you'd need to > cross-compile from a glibc system, or you'd have the same problem in > that you'd be distributing libc and gcc (which is GPLed and links to > libc) together. If gcc can bootstrap itself on OpenSolaris from their native compiler, this is only a matter of computing power and/or endurance. > > On other news, private communication by the gnusolaris.org people lead me > > to the conviction that they are internally working on resolving their > > problems with the legalese and we should give them a break. I will keep > > you informed about their progress. > > Ugh; giving people a break's a good thing, but doing things in private > and behind closed doors isn't. Participating in Debian in public can be > (unreasonably) rough, but closing yourself up from the community and > having communication bottle necks isn't a win either. It was only a small notice, that they are soliciting legal help. I just wanted to demonstrate that they _are_ working on it in - what I believe - good faith and that therefore they should be given more time (you know lawyers) to resolve these problems. On the other hand I also do not want to forget this issue and will followup on it, if I receive no further messages. Everyone else is free to act as dictated by his or her conscience. I hear copyright holders have better leverage then users like me. Thanks for listening, David [ex] Source packages including other libraries directly (e.g. using zlib) or requiring large parts of "foreign source" (IIRC synaptics driver needed access to private X headers) are border cases here. [od] objectdump -x $BINARY | grep NEEDED -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
