CDDL/GPL and Nexenta (with CDDL libc)
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.]
Don Armstrong
--
Who is thinking this?
I am.
-- Greg Egan _Diaspora_ p38
http://www.donarmstrong.com http://rzlab.ucr.edu
Reply to: