I just realized that a part of my brief conversation with Mike Milinkovic following my FOSDEM talk triggers HBR.
While not a substantive point, I noted to Mike my interest in submitting some version of copyleft-next for OSI approval. (Mike, who heads the Eclipse Foundation, is on the OSI board of directors.)
The substantive point, though, was this: we were talking about how the EPL (like the MPL and its relatives) allows proprietary licensing of binary versions. I told him that I had recently thought about whether this was in conflict or not with the basic notion of strong copyleft, and whether copyleft-next could or should be revised to allow more restrictive licensing of binaries (more restrictive than copyleft-next/GPL/AGPL, that is). That might sound heretical, but it is not meant to be. It relates to a historical puzzle I have thought about.
I noted that the GNU GPL was originally intended for software that would be compiled by proprietary compilers and run on proprietary operating systems. The earliest binary versions of GNU Emacs must have contained proprietary code. This of course was what led RMS to add what came to be known as the system library exception to the definition of 'complete source code'. But the system library exception does not tell us what the license of a statically-linked binary formed out of GPL-licensed code and 'system library' code is supposed to be.
I am not sure whether RMS thought about this issue. It is possible that the licensing terms governing the various operating systems and compilers in use among the early users/porters of GPL-licensed programs like GNU Emacs were such that the question was thought to be uninteresting.
- RF
Hello,
On 02/07/2013 03:34 AM, Richard Fontana wrote:
I noted that the GNU GPL was originally intended for software that would be compiled by proprietary compilers and run on proprietary operating systems. The earliest binary versions of GNU Emacs must have contained proprietary code. This of course was what led RMS to add what came to be known as the system library exception to the definition of 'complete source code'. But the system library exception does not tell us what the license of a statically-linked binary formed out of GPL-licensed code and 'system library' code is supposed to be.
Doesn't that simply mean that the parts of the binary which consist of the transformed GPL'ed work are still GPL licensed, and the remaining parts are under whatever license binaries of the system library code would have if it would be distributed separately?
The system library exception seems to merely limit the scope of the copyleft nature of the license, so the scenario is similar to statically linking code under a weaker copyleft (e.g. the Mozilla Public License) with a system library.
When distributing such a binary you would have to comply with the terms of both licenses.
But isn't this true of a GPL covered work statically linked with a library under a GPL-compatible license as well? My understanding is that someone distributing such a binary would still have to comply with both licenses, but if you comply with the terms of the GPL you are usually also complying with terms of any other licenses, because GPL compatible licenses cannot demand anything substantial beyond what the GPL is already demanding.
-- Kuno. (not a lawyer, so please correct me if any of this reasoning is off :)
On Thu, Feb 07, 2013 at 11:17:15AM +0100, Kuno Woudt wrote:
Hello,
On 02/07/2013 03:34 AM, Richard Fontana wrote:
I noted that the GNU GPL was originally intended for software that would be compiled by proprietary compilers and run on proprietary operating systems. The earliest binary versions of GNU Emacs must have contained proprietary code. This of course was what led RMS to add what came to be known as the system library exception to the definition of 'complete source code'. But the system library exception does not tell us what the license of a statically-linked binary formed out of GPL-licensed code and 'system library' code is supposed to be.
Doesn't that simply mean that the parts of the binary which consist of the transformed GPL'ed work are still GPL licensed, and the remaining parts are under whatever license binaries of the system library code would have if it would be distributed separately?
That's sometimes how I've looked at it, yes.
The system library exception seems to merely limit the scope of the copyleft nature of the license, so the scenario is similar to statically linking code under a weaker copyleft (e.g. the Mozilla Public License) with a system library.
When distributing such a binary you would have to comply with the terms of both licenses.
Yes. I'm just not sure whether RMS contemplated the possibility that the proprietary license might be significantly more restrictive than the GPL without actually making it impossible to satisfy the terms of the GPL.
Essentially, there's something strange about the system library exception. It's focused on clarifying that you don't have to provide source code to something you probably won't have distributable (or GPL-compatible) source code to anyway, but it doesn't say how the inclusion of the system library in the generated binary affects the requirement to license the binary under the GPL.
The larger issue I was getting at is this: If you distribute a binary, and you provide everything needed to generate a functionally equivalent binary, why does the license of the original binary even matter? The answer might be that the GPL is designed to ensure that binaries are easily redistributable under GPL-like terms (royalty-free copying and distribution), without expecting the user to have to rebuild from source code in order to have a freely-redistributable binary.
But isn't this true of a GPL covered work statically linked with a library under a GPL-compatible license as well? My understanding is that someone distributing such a binary would still have to comply with both licenses, but if you comply with the terms of the GPL you are usually also complying with terms of any other licenses, because GPL compatible licenses cannot demand anything substantial beyond what the GPL is already demanding.
In that case I've tended to think of the whole thing as being under the GPL (this is how the GPL itself speaks of it, and this is how I believe developers typically conceptualize it).
- RF
On Thu, Feb 07, 2013 at 11:58:06PM -0500, Richard Fontana wrote:
Essentially, there's something strange about the system library exception. It's focused on clarifying that you don't have to provide source code to something you probably won't have distributable (or GPL-compatible) source code to anyway, but it doesn't say how the inclusion of the system library in the generated binary affects the requirement to license the binary under the GPL.
The larger issue I was getting at is this: If you distribute a binary, and you provide everything needed to generate a functionally equivalent binary, why does the license of the original binary even matter? The answer might be that the GPL is designed to ensure that binaries are easily redistributable under GPL-like terms (royalty-free copying and distribution), without expecting the user to have to rebuild from source code in order to have a freely-redistributable binary.
Consider if you will the case of Cygnus Support distributing gcc binaries for Solaris. Sun stopped shipping a compiler with their OS, so you couldn't build gcc from source unless you paid them $$$ for suncc, or if you obtained a bootstrap gcc binary from somewhere. But if the gcc binary was linked against the Solaris C library, which was most definitively _not_ licensed under a GPLv2 compatible license, the GPL would need to have some provision where it would be legal to distribute said gcc binary to the Solaris user.
- Ted
On 2013-02-10 00:39, Theodore Ts'o wrote:
On Thu, Feb 07, 2013 at 11:58:06PM -0500, Richard Fontana wrote:
The larger issue I was getting at is this: If you distribute a binary, and you provide everything needed to generate a functionally equivalent binary, why does the license of the original binary even matter? The answer might be that the GPL is designed to ensure that binaries are easily redistributable under GPL-like terms (royalty-free copying and distribution), without expecting the user to have to rebuild from source code in order to have a freely-redistributable binary.
Consider if you will the case of Cygnus Support distributing gcc binaries for Solaris. Sun stopped shipping a compiler with their OS, so you couldn't build gcc from source unless you paid them $$$ for suncc, or if you obtained a bootstrap gcc binary from somewhere. But if the gcc binary was linked against the Solaris C library, which was most definitively _not_ licensed under a GPLv2 compatible license, the GPL would need to have some provision where it would be legal to distribute said gcc binary to the Solaris user.
Fair point, but in this particular case, GCC could have been bootstrapped to the point of being self-hosted with glibc, and at that point there would be no confusion. Right?
On Sun, Feb 10, 2013 at 10:20:04AM +0800, "Claes Wallin (韋嘉誠)" wrote:
Consider if you will the case of Cygnus Support distributing gcc binaries for Solaris. Sun stopped shipping a compiler with their OS, so you couldn't build gcc from source unless you paid them $$$ for suncc, or if you obtained a bootstrap gcc binary from somewhere. But if the gcc binary was linked against the Solaris C library, which was most definitively _not_ licensed under a GPLv2 compatible license, the GPL would need to have some provision where it would be legal to distribute said gcc binary to the Solaris user.
Fair point, but in this particular case, GCC could have been bootstrapped to the point of being self-hosted with glibc, and at that point there would be no confusion. Right?
That's assuming that glibc actually worked on Solaris....
From what I can tell, glibc suffers from the same bug that systemd,
GNOME, etc. all suufer from. They use vast amounts of autoconf and libtool to obfuscate and slow down the build process, but then are so stuffed full of Linux dependencies that it's hard or impossible to make them work on anything other than Linux.
Clearly we need an update from Henry Spencer's Ten Commandments for C programmers:
10. Thou shalt foreswear, renounce, and abjure the vile heresy which claimeth that ``All the world's a VAX'', and have no commerce with the benighted heathens who cling to this barbarous belief, that the days of thy program may be long even though the days of thy current machine be short.
But anyway, this points out pretty clearly why the system library exemption was needed.
- Ted
On 2013-02-10 11:43, Theodore Ts'o wrote:
On Sun, Feb 10, 2013 at 10:20:04AM +0800, "Claes Wallin (韋嘉誠)" wrote:
Consider if you will the case of Cygnus Support distributing gcc binaries for Solaris. Sun stopped shipping a compiler with their OS, so you couldn't build gcc from source unless you paid them $$$ for suncc, or if you obtained a bootstrap gcc binary from somewhere. But if the gcc binary was linked against the Solaris C library, which was most definitively _not_ licensed under a GPLv2 compatible license, the GPL would need to have some provision where it would be legal to distribute said gcc binary to the Solaris user.
Fair point, but in this particular case, GCC could have been bootstrapped to the point of being self-hosted with glibc, and at that point there would be no confusion. Right?
That's assuming that glibc actually worked on Solaris....
From what I can tell, glibc suffers from the same bug that systemd, GNOME, etc. all suufer from. They use vast amounts of autoconf and libtool to obfuscate and slow down the build process, but then are so stuffed full of Linux dependencies that it's hard or impossible to make them work on anything other than Linux.
I only know that before glibc 2.0 it didn't work unpatched on a Linux kernel. Today it may well be entrenched in Linux specifics, but that's not where it came from. I assumed System V would have been the original platform.
Clearly we need an update from Henry Spencer's Ten Commandments for C programmers:
10. Thou shalt foreswear, renounce, and abjure the vile heresy which claimeth that ``All the world's a VAX'', and have no commerce with the benighted heathens who cling to this barbarous belief, that the days of thy program may be long even though the days of thy current machine be short.
But anyway, this points out pretty clearly why the system library exemption was needed.
It does, I'm just off on a tangent here.
On Sun, Feb 10, 2013 at 12:53:24PM +0800, "Claes Wallin (韋嘉誠)" wrote:
I only know that before glibc 2.0 it didn't work unpatched on a Linux kernel. Today it may well be entrenched in Linux specifics, but that's not where it came from. I assumed System V would have been the original platform.
Nope, it was originally worked mostly used on embedded systems (think Cygnus Support's customers). Today it works unpatched on Hurd and Linux systems. There are some heavily patched glibc's that can be used for *BSD (although the *BSD systems have their own libc). As far as I know, glibc never worked on Solaris... or AIX, HPUX, Tru64, Sequent's dynix, etc.
- Ted
On 2013-02-10 13:26, Theodore Ts'o wrote:
On Sun, Feb 10, 2013 at 12:53:24PM +0800, "Claes Wallin (韋嘉誠)" wrote:
I only know that before glibc 2.0 it didn't work unpatched on a Linux kernel. Today it may well be entrenched in Linux specifics, but that's not where it came from. I assumed System V would have been the original platform.
Nope, it was originally worked mostly used on embedded systems (think Cygnus Support's customers). Today it works unpatched on Hurd and Linux systems. There are some heavily patched glibc's that can be used for *BSD (although the *BSD systems have their own libc). As far as I know, glibc never worked on Solaris... or AIX, HPUX, Tru64, Sequent's dynix, etc.
Right. I keep forgetting that glibc did not really originate from GNU.
copyleft-next@lists.fedorahosted.org