On Fri, Sep 3, 2010 at 4:15 AM, Don Armstrong <[email protected]> wrote: > In the course of Debconf10, I was asked a few questions about CDDL'ed > libc, Nexenta, GPLed works and what would be necessary to have GPLed > works which linked to a CDDLed libc so Nexenta could possibly become a > Debian port. To make sure I haven't lept off the edge; I just wanted > to run this by everyone. > > The quick ruberic is the following: > > CDDL'ed libc (and other System Library) and GPLv3+ work: OK > CDDL'ed libc (and other System Library) and GPLv2 work: Probably Not OK > * and GPLv2+ work + CDDL work (non-System Library): Not OK > > More lengthly explanation: > > The real question for GPLed works which link to solaris libc is > whether or not solaris libc fits in with the system library exception. > > It's my understanding that for GPLv2 and v3, if you're not shipping > the system library yourself, you don't need to concern yourself with > license compatibility, and can just ship it anyway. This isn't the > case for Debian or Nextenta, though, so we don't even need to > contemplate it. > > For GPLv2 (not GPLv2+), the situtation when you are shipping both is > more difficult; the key question here is what the precise meaning is > of > > 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. > > My understanding is that for GPLv2, that means that we must also have > the source, and we must ship it in compliance with the GPL, which we > cannot do with CDDL works. [The critical aspect here is what precisely > is meant by "accompanies the executable", we've long assumed[1] that > Debian's distribution of libraries means that they are "accompanying" > the executable.] > > For GPLv3 (and GPLv2+, where we can choose GPLv3), the critical > question is whether libc is a System Library. > > The "System Libraries" of an executable work include anything, > other than the work as a whole, that (a) is included in the normal > form of packaging a Major Component, but which is not part of that > Major Component, and (b) serves only to enable use of the work > with that Major Component, or to implement a Standard Interface > for which an implementation is available to the public in source > code form. A "Major Component", in this context, means a major > essential component (kernel, window system, and so on) of the > specific operating system (if any) on which the executable work > runs, or a compiler used to produce the work, or an object code > interpreter used to run it. > > So, starting from the bottom, it's clear that libc is a majorq > essential component of the OS. It implements a "Standard Interface" > for which we have source code. > > The remaining question is what precisely is meant by subpart (a); I > believe that libc is included with the C compiler or kernel "Major > Component", but isn't itself the kernel or compiler. > > So I believe that in the case of a libc licensed under the CDDL, > things that are GPLv3 or GPLv2+ can be distributed and link against > it. > > In the case of GPLv2 only (or cases of GPLv2+ where we have to choose > GPLv2), we cannot link to a CDDLed libc, and must instead link with a > libc which is compatible with the GPL. [There is eglibc running on the > solaris kernel, but the Solaris kernel doesn't maintain as tight of an > API as the linux kernel; it instead relies on libc to present that > API.] > >
Hi All, I'll be posting on behalf of the Nexenta project. Thanks to Don and Zack for their time and patience, and providing insight into this matter. A few clarifications/observations: * Nexenta referred to here is the Nexenta Core Platform, the project hosted at nexenta.org. * I would like to understand further the rational behind using the "distribution of libraries" boundary at Debian project level, rather than at a package/binary level, which seems a more natural fit for delineation. * If we do choose the entire project as the boundary, then in the specific case of packages that are GPLv2 only (linking with libc), we have been considering building these with a statically linked, license compatible libc (one of the small implementations). I would also like to hear your thoughts on this as a technical/legal solution. (Don, did you mean to add a reference to [1] in your mail?) Regards, Anil http://www.gulecha.org -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
