Re: CDDL/GPL and Nexenta (with CDDL libc)
* Don Armstrong: You're conflating GPLv2 with v3. They are very different with regards to the System Library exception, as I explained in my original message. Please consider rereading it and pointing out precisely where I have misread the license along with supporting quotations from the licence itself if you feel that I am misrepresenting the ramifications of GPLv3'd works in regards to the System Library exception when linking to a CDDL'ed libc. Okay, let's review this paragraph: | 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. libc is part of the Debian base system, which is a Major Component. libc is normally included in the base system. It is a required part of the base system. So case (a) does not apply. I would agree that the language in draft 2 of GPL version 3 would have covered a CDDL libc. But that language was deemed unacceptable because it would have included OpenSSL, too. So it has to be changed. Whether the changes where done in such a way to exclude a CDDL libc, too, I don't know. The FSF FAQ does not shed light on this issue, either. There's another problem: the System Libraries clause only waives the need to provide source code. The requirement to license a modified work (including its source code), as a whole, under the GPL remains in effect. Now the CDDL requires that the license for the Executable form does not attempt to limit or alter the recipient’s rights in the Source Code form from the rights set forth in this License, and it is quite difficult to tell if a GPL/CDDL agglomerate isn't trying to do precisely that (due to the patent-related provisions in the GPL). -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87oc3mo24g@mid.deneb.enyo.de
Re: CDDL/GPL and Nexenta (with CDDL libc)
On Thu, 23 Sep 2010 23:42:07 +0200 Josselin Mouette wrote: [...] The constraints for a CDDL’ed OS are the same as for a proprietary one. This looks correct to me, since I am personally convinced that CDDL'ed works fail to comply with the DFSG and are therefore non-free... My detailed analysis is here: http://lists.debian.org/debian-legal/2005/09/msg00206.html -- http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html Need some pdebuild hook scripts? . Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgpsdZDFuHYAm.pgp Description: PGP signature
Re: CDDL/GPL and Nexenta (with CDDL libc)
This one time, at band camp, Florian Weimer said: * Don Armstrong: CDDL'ed libc (and other System Library) and GPLv3+ work: OK I think the FSF wants us not to be able to use the System Library exception. It is only intended for proprietary operating systems. Does no one else see a license exception that is easier for a proprietary OS than a free one as problematic? -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: CDDL/GPL and Nexenta (with CDDL libc)
Le jeudi 23 septembre 2010 à 20:42 +0100, Stephen Gran a écrit : This one time, at band camp, Florian Weimer said: * Don Armstrong: CDDL'ed libc (and other System Library) and GPLv3+ work: OK I think the FSF wants us not to be able to use the System Library exception. It is only intended for proprietary operating systems. Does no one else see a license exception that is easier for a proprietary OS than a free one as problematic? Well, it would be if that was the case. But if a proprietary software vendor wanted to distribute a GPL program built on proprietary libraries, he could not. The constraints for a CDDL’ed OS are the same as for a proprietary one. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: CDDL/GPL and Nexenta (with CDDL libc)
On Wed, 22 Sep 2010, Florian Weimer wrote: * Don Armstrong: CDDL'ed libc (and other System Library) and GPLv3+ work: OK I think the FSF wants us not to be able to use the System Library exception. It is only intended for proprietary operating systems. It's intended for cases where you're running a GPLed work on a system which is GPL-incompatible. The FSF also unconditionally labels the CDDL als GPL-incompatible (although it is not clear if the license overview was thoroughly updated for GPL version 3). They're referring to the common case where the System Library exception is not invoked. There used to be a GNU libc port to the SunOS kernel. Perhaps the Nexenta folks can revive that? My suggestion was to link GPLed binaries to such a libc which circumvents most of these problems. However, because of design considerations, the libc-kernel interface is not as stable in SunOS as it is in linux, which makes this a long-term labor intensive process. Don Armstrong -- Nearly all men can stand adversity, but if you really want to test his character, give him power. -- Abraham Lincoln http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100924001854.gk6...@teltox.donarmstrong.com
Re: CDDL/GPL and Nexenta (with CDDL libc)
* Don Armstrong: CDDL'ed libc (and other System Library) and GPLv3+ work: OK I think the FSF wants us not to be able to use the System Library exception. It is only intended for proprietary operating systems. The FSF also unconditionally labels the CDDL als GPL-incompatible (although it is not clear if the license overview was thoroughly updated for GPL version 3). There used to be a GNU libc port to the SunOS kernel. Perhaps the Nexenta folks can revive that? -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4mdhe2q@mid.deneb.enyo.de
Re: CDDL/GPL and Nexenta (with CDDL libc)
On Fri, Sep 3, 2010 at 9:21 AM, Anil Gulecha a...@nexenta.org wrote: * 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. Simply because accompanies is open to interpretation. Clearly a Win32 binary downloaded from ftp.gnome.org does not accompany Microsoft Windows. It isn't quite as clear that an ELF executable in the gimp binary package on a Debian CD does not accompany the ELF executables in the libc6 package. * 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. That sounds problematic to get right for every package in the archive (I'm thinking about the license compatibility nightmares caused by OpenSSL). BTW, whatever happened to Debian GNU/kOpenSolaris? http://csclub.uwaterloo.ca/~dtbartle/opensolaris/ Also, what would be the upstream of a possible Debian OpenSolaris based port? I read that Oracle is closing down OpenSolaris and moving development behind closed doors. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=1zykz2konnrdvjxfwm51fhlaux41bg9+l+...@mail.gmail.com
Re: CDDL/GPL and Nexenta (with CDDL libc)
Also, what would be the upstream of a possible Debian OpenSolaris based port? I read that Oracle is closing down OpenSolaris and moving development behind closed doors. Illumos will be the upstream. Illumos project started out as a branch of OpenSolaris code, but is now effectively a fork of OpenSolaris codebase. As an added positive, it is replacing all of the closed bits (previously distributed as binary blobs) with open code. A major portion of this is already done. Site: https://www.illumos.org Note: It is the current understanding that development will be within Oracle, but the code itself will be opened after binary releases.. so we'll mostly see a big drop of code after every solaris release. Regards Anil http://www.nexenta.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimkz=a2corftooxb-prdr7cypgp13x-bp+6j...@mail.gmail.com
Re: CDDL/GPL and Nexenta (with CDDL libc)
Anil Gulecha a...@nexenta.org writes: Illumos will be the upstream. Illumos project started out as a branch of OpenSolaris code, but is now effectively a fork of OpenSolaris codebase. I don't understand the distinction being made there. What is different between “a branch of the code” versus “a fork of the codebase”? As an added positive, it is replacing all of the closed bits (previously distributed as binary blobs) with open code. A major portion of this is already done. Great news, I'm glad people are enthusiastic enough to make a free software version of this code. -- \ “We must find our way to a time when faith, without evidence, | `\disgraces anyone who would claim it.” —Sam Harris, _The End of | _o__) Faith_, 2004 | Ben Finney -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87aanzfgyl@benfinney.id.au
Re: CDDL/GPL and Nexenta (with CDDL libc)
On Fri, Sep 3, 2010 at 12:31 PM, Ben Finney ben+deb...@benfinney.id.au wrote: Anil Gulecha a...@nexenta.org writes: Illumos will be the upstream. Illumos project started out as a branch of OpenSolaris code, but is now effectively a fork of OpenSolaris codebase. I don't understand the distinction being made there. What is different between “a branch of the code” versus “a fork of the codebase”? The idea initally was not to explicitly be a fork (go on a different development path). lllumos was to follow OpenSolaris closely, except replacing closed binaries and maintaining drivers upstream may drop. I guess you can technically call this a fork.. but the idea was to be close. Now, Illumos has no real upstream, and is maintaining the last code drop, and will merge changes from future code drops. Regards, Anil http://www.gulecha.org -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin4zialo42xm8i7rpx+yng-n7sxtonj=-w_9...@mail.gmail.com
Re: CDDL/GPL and Nexenta (with CDDL libc)
On Fri Sep 03 14:04, Paul Wise wrote: BTW, whatever happened to Debian GNU/kOpenSolaris? http://csclub.uwaterloo.ca/~dtbartle/opensolaris/ How would the licence interactions work here, with a CDDL kernel and a GPL libc/userland? Does the fact that it's specifically the kernel satisfy the exceptions in the GPL? Matt signature.asc Description: Digital signature
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 -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100902224530.gm22...@rzlab.ucr.edu
Re: CDDL/GPL and Nexenta (with CDDL libc)
On Fri, Sep 3, 2010 at 4:15 AM, Don Armstrong d...@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 -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=vypnmbd5dcqi+ehdiamexoe_eldhxwqfio...@mail.gmail.com
