Re: Request: Source for parts of GNU/Solaris
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:
david@zion:/gnusolaris/livecd-mnt/usr/bin$ ./dpkg
bash: ./dpkg: No such file or directory
david@zion:/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
Reply to: