Re: CDDL/GPL and Nexenta (with CDDL libc)
On Fri, Sep 3, 2010 at 4:15 AM, Don Armstrong <don@debian.org> 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
Reply to: