GPLv3, Linux and GPLv2 Compatibility
The Linux kernel—the core piece of source code on which all distributions of Linux are based—is released under the GPLv2 license. Not the "GPL version 2, or any later version", but explicitly GPL version 2. This may seem like an insignificant detail, but it means that the Linux kernel source won't be available under the GPLv3 unless the kernel developers make an explicit change to allow it. And, it appears the kernel developers aren't planning to make that change. In the past, Linus has stated that the Linux kernel would not be updating to the new version of the license. Even in his recent comments on the new draft, which prompted headlines of "Linus likes it", what he actually said was "I still think that is totally mis-designed, but at least the damage is much narrower in scope now, so in that sense the last draft is a big improvement on the previous ones." My grandmother would have called that "Damning with faint praise."
On the other side, we have the GNU packages which provide a number of the tools and applications for Linux, ranging from the underappreciated tar, to the monolithic Emacs, to the indispensable GCC. Most of these are licensed under GPLv2 "or any later version". More importantly, many of them have assigned copyright to the Free Software Foundation, as a gesture of faith in the FSF, out of fear of the responsibility of owning the copyright as individuals, or just to follow the crowd. In theory, this gave the FSF a greater ability to enforce the GPL. Since the FSF owns copyright on these packages, they have the right to change the license on them from "GPL version 2, or any later version" to "GPL version 3, or any later version". They might not do so, but would have good reason to, if they believe that the GPLv3 is a significant improvement over the GPLv2.
If this sounds like a legal mess to you, you're absolutely right. So what's the likely outcome?
The simplest possibility is that the kernel remains as GPLv2 only, and the GNU packages remain as GPLv2 "or any later version". GPLv2 is clearly compatible with itself. Most Linux distributions will continue as GPLv2, with or without the addition of "or any later version". The inclusion of the GPLv2-only kernel will mean that the distribution as a whole will be treated as GPLv2 in perpetuity (since you can't distribute the code at its core as GPLv3). This anchor on the license version would be unfortunate, as the GPLv2 is an old license badly in need of some spring cleaning. It suffers from legal ambiguities and obscurities, less-than-ideal language choices, and references to less-than-modern technology. Many of us were excited when we first heard about the FSF's plans to revise the GPLv2, because we hoped it would clear up these problems.
The next possibility is that the kernel remains GPLv2 only, but the GNU packages update to GPLv3 "or any later version". This would be a significant problem for Linux distributors. They can't distribute the kernel as GPLv3, and they can't distribute new releases of the GNU packages as GPLv2, because the GPLv3 places additional restrictions on the distribution of code—such as the user products restriction and the patent deals restriction—and the GPLv2 explicitly doesn't allow "further restrictions". So what license do the Linux distributors use?
They could segment their distributions into two parts, and distribute one as GPLv2 and one as GPLv3, much like Debian currently segments "free" and "non-free". But they would have to be careful of the exact relationship between the installed kernel and GPLv3 packages to make sure they clearly qualify as "separate works". And unfortunately, the exact definition of "separate works" is one of the points where the GPLv2 is ambiguous.
Under this scenario, the Linux distributors would also have the option of forking the GNU packages at the last revision released under the GPLv2 and maintaining them as GPLv2. (No one can revoke or retroactively change the license on existing releases, they can only change the license on future releases.) But, maintaining and continuing development on the full suite of GNU packages is an enormous burden. It's unlikely that any Linux distributor has the resources (or desire) to take it on.
You might think the FSF would have to be insane to unleash this licensing hell. But, the truth of the matter is that the goals they're trying to achieve with the GPLv3 can only be achieved if companies who modify and distribute GPL software are obligated to perform that distribution under the GPLv3. If companies have the option of using the GPLv2 instead, then the added terms in the GPLv3 have no effect. This may be the greatest misfortune of the direction the FSF has taken with the GPLv3. If the license were purely a cleaned up version of the GPLv2, there would be no incompatibility, the FSF would have no agenda involved in getting projects to update to the new license, and at the same time there would be no reason for projects to object to updating. Smooth sailing.
A third possibility is that the LInux kernel developers will decide that it's not worth the hassle and just accept the GPLv3. I suspect that this is what the FSF is hoping will happen. Depending on the changes in the next two drafts of the GPLv3, it still might. But, it's not looking likely that the kernel developers will yield. Frankly, if I were in the kernel developers shoes, I wouldn't either. The GPLv3 serves to further the goals of the FSF, but the current draft actually hinders Linus' goals and the goals of Linux in general.
Another possibility, complete speculation on my part, is that the Linux Foundation becomes more than just a loose consortium of companies sponsoring Linux kernel development. It becomes the copyright holder for the Linux kernel, not taking copyright assignments from contributors like the FSF, but copyright licenses like Apache does, so the kernel developers still hold their copyright on the code. The Linux Foundation releases a license with basically the same terms as the GPLv2, but without the legal ambiguities, obscure language, and anachronisms. Like the GPL, this license is copyleft. Like the GPL, this license requires the release of modified versions under the same license. This license clearly defines the concepts of linking and modified works, making it easier for Linux distributors to be sure that their segmented distribution trees are in compliance. Over time, more and more projects currently released under the GPL adopt the Linux license, because it is more legally precise and more comprehensible to the average developer than either the GPLv2 or GPLv3. Eventually, Linux distributions switch over to the Linux license, leaving only a small branch of GPLv3 (or v4 or v5) code to be downloaded separately (if the user chooses to do so).
To quote a famous poet:
"There must be some way out of here," said the joker to the thief,
"There's too much confusion, I can't get no relief.
Businessmen, they drink my wine, plowmen dig my earth,
None of them along the line know what any of it is worth."
tags: open source
| comments: 39
| Sphere It
submit: 
0 TrackBacks
TrackBack URL for this entry: http://blogs.oreilly.com/cgi-bin/mt/mt-t.cgi/5418
Comments: 39
In fact, almost all Linux distributions already do include large amounts of software with licenses that are not GPL compatible --- Firefox, covered by the Mozilla license; Perl, covered by the artistic license; Apache, covered by the Apache license, etc., etc., etc. There's no problem here. And I likewise wouldn't expect there to be a problem using a GPLv3 version of gcc to build a GPLv2 Linux kernel, any more than there's a problem right now using a GPLv2 version of gcc (all of them, so far) to build Perl or Apache.
Problems only arise when GPLed code and code under one of these other licenses is combined in a single work. One of the advertised goals of GPLv3 was to try to eliminate that problem with code under at least some of the licenses I've described, but wrt the Apache license, at least, they appear to be backsliding at the moment...
Robert is correct. We've also had the opposite situation for a long time, too. The GNU userland utilities have long run on top of proprietary Unix kernels. That doesn't cause licensing problems. The GPL leaves the question of deciding what is a single work up to copyright law, and it seems pretty clear that programs running on top of a particular kernel are typically separate from that kernel.
As for Apache compatibility: we've heard the feedback on this loud and clear. We're working on it.
The GPL explicitly says that distributors can include other, non-GPL-compatible works in the same distribution as GPL-covered works:
GPLv2: "In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License."
GPLv3: "Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate."
I don't think licenses of individual components of a distribution, can affect the licensing of other, independent components, as long as we're talking about free software licenses.
If that were true, and the license of the components had no effect on the license of the operating system as a whole, then a proprietary distribution of Linux wouldn't be a license violation. I'm sure TiVo and Microsoft would love to hear that. ;)
Linux the operating system is more than just Linux the kernel, a fact that the FSF has long used to try to convince people to call it "GNU/Linux".
If it were just a collection of packages on an FTP server or CD, there's no question that it would qualify as a aggregate. But it's not, it's an installed system with many pieces working together. The relevant clause in the GPLv2 is:
But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Linux, as an operating system, easily falls into that definition.
GPLv3 muddies the waters even further, by restricting the definition of aggregate:
...called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit.
So, the license of the individual components have a direct impact on the license of the whole, even if that whole is considered an "aggregate".
If that were true, and the license of the components had no effect on the license of the operating system as a whole, then a proprietary distribution of Linux wouldn't be a license violation.
How do you figure? Can you ignore all of the licenses in a distribution because none of them affect each other?
Allison, I think you've misunderstood both quotes ectionsthere, but I can understand why.
The GPLv2 quote is not relevant to aggregates, only to "sections as part of a whole", in the context of a single project.
The GPLv3 quote doesn't mean the "union of licenses in the aggregate used to limit", but the "compilation and *its* resulting copyright used to limit" (my emphasis). You can aggregate individual works, but not if the license of your aggregate limits your rights beyond what they permit.
IANAL. :-)
Can you ignore all of the licenses in a distribution because none of them affect each other?Not at all. But if you only have to satisfy the license of individual components and not of the work as a whole, then a proprietary distribution of Linux could satisfy those requirements by shipping a CD that contains all the free software packages they used in alphabetical order. You couldn't build it as an operating system, you couldn't run it, but it would satisfy the terms of the individual components.
Either Linux (as an operating system) is a licensable whole, or it isn't. You can't have it both ways.
I'm not saying that every application you could ever install on Linux would be considered part of the operating system, but there are a core set of tools and utilities that make Linux an operating system rather than just a kernel. It's a fuzzy line which packages would necessarily be part of that core set, but it's a line we've never needed to clarify, because they were all available under the same license. If that changes, it will be a significant legal event.
Hi Allison,
I think you raise some interesting points around the question of what happens if you release the source code but make it really hard to actually build the binaries. This is certainly an intriguing corner case. Certainly there's no requirement that building the binaries be automagical. How hard do you have to make it before someone yells foul?
However, I'm still inclined to think you're incorrect that GNU and the Linux kernel may have to use the same license. Let me raise a specific counterexample: Nexenta--essentially Debian distro with OpenSolaris (under CDDL) substituted for the Linux kernel. There was a lot of hue and cry about this on the Debian-legal mailing list at one point, but AFAIK most everyone ended up accepting this as legit--and there certainly hasn't been any noise from the FSF over this.
"Linux" is an operating system. What Richard calls "GNU/Linux" [1] is an operating environment. Linux is separate from userland.
[1] I call it "the glibc definition" because it's more compelling and fundamental than Richard's issues.
The GPLv3 quote doesn't mean the "union of licenses in the aggregate used to limit", but the "compilation and *its* resulting copyright used to limit" (my emphasis). You can aggregate individual works, but not if the license of your aggregate limits your rights beyond what they permit.
An aggregate is a simple collection of software. It has no license and no copyright separate from the copyright of individual pieces. That's why the GPL makes an exception for it, to clearly mark that it isn't a derivative work. Once you add any functionality to a distributed "blob" of software it's no longer clear that it's an aggregate. A lot depends on how much functionality was added and the purpose of that functionality (and which particular set of lawyers and judges are examining the case). The distinction between licensable work and aggregate is open to interpretation in this context.
The FSF has been inconsistent in the past on whether they treat Linux as an aggregate or work of software. They call it an aggregate, but when they set out to enforce the license against Linksys, they didn't demand that Linksys release a collection of individual packages (in no particular order, with no particular connection between them). They demanded that Linksys release their entire distribution, including all the additional functionality necessary to build and install that distribution on the Linksys hardware. In that demand, they acted as if Linux the operating system is a work of software, not an aggregate.
Treating Linux as a work of software has been good for Linux and good for free software as a whole. If Linksys had only released a loose collection of packages, I wouldn't have a secure firewall running on my WRT54G right now. We wouldn't have DD-WRT, OpenWRT, and a host of other free software distributions for embedded devices that started with the Linksys release.
Here's one good argument on the side of licensable work: I've built a Linux box from scratch, compiling individual components and packages and bootstrapping the whole system. It's an enormous amount of work. I have friends who maintain distributions of Linux, and that is also an enormous amount of work, and removes an enormous amount of work from the end users. That work, that original work by the maintainers, is intellectual property in the finished product. Linux distributions are not simple aggregations.
There is room for interpretation, and in the past we didn't have to make a clear call on it. With the release of the GPLv3, we will have to make a clear call on it, for the reasons I mentioned in the post. This gives us an opportunity to choose between the two paths. We have treated Linux the operating system as a licensable work in the past, and my opinion is that we should continue to do so. I'll outline the second possible path in a separate comment.
A Linux distribution is an aggregation of independent works under their own licenses *and* a collective work deserving of its own overall copyright and license. If that collective work is distributed under GPLv3, then derivative works *of that aggregation* must be licensed under GPLv3 also.
Meanwhile, the individual works in that aggregation remain under the original licenses their authors placed them under.
If an aggregation is a mixture of GPLv2 and GPLv3 independent works, the aggregation itself could be distributed under GPLv3. Does FSF agree?
If so, Linux distributions can be a mixture of GPLv2 and GPLv3 modules, each independent works in their own right.
Indeed, a collection of GPLv2 and GPLv3 modules could be distributed under any license, even a proprietary one, as long as the components remain under the terms of the appropriate GPL license.
/Larry Rosen
We had a great Committee A meeting today, very productive. Again, I won't detail specifics, but I will outline the FSF's perspective (as communicated in the meeting).
The FSF takes the position that Linux the operating system is a pure aggregation (the second path). They acknowledge that in the past some actions they've taken may have given the impression that they were treating the operating system as a work of software, but their intention was only to enforce the copyright that they held in a small number of packages. It's a valid position, but taking this position does have several results:
The patent deals restriction in the GPLv3 has no effect unless it specifically mentions one of the small set of packages explicitly licensed under the GPLv3 (currently none). Mentioning Linux in the deal doesn't count, it would have to reference "the GNU Compiler Collection", for example, or "GNU Emacs". Patent deals tend to deal on a grand scale, which makes it highly unlikely that any patent deal will ever be touched by the GPLv3.
The user products restriction is also quite weak, because it only applies to specific packages within the Linux distribution. So, as long as TiVo allows you to install a modified version of GCC or Emacs (if they're even installed in the first place), they're in compliance. They don't have to allow you to compile and install a complete distribution of Linux.
This position means that there is no way for the FSF or anyone else to enforce any license on the Linux distribution as a whole, or on Linux as an operating system. Aggregates aren't subject to the GPL terms. Licenses can only be enforced on individual components separately, and lack of compliance on one component has no impact on other components. Linksys can distribute Linux in their hardware, only release the individual packages they included, and not release the whole distribution with tools, configuration files, etc. to install and run that distribution. The FSF accepts this (which seems odd, given the effort they've taken in the GPLv3 over ensuring that modified versions can be installed and run on hardware).
This position means that when the revised GPLv3 license is released, it will have no impact on the free software world. None. It might have an impact in 10 years, if enough packages change to say "GPL version 3, or any later version", but for now it's completely powerless. The FSF accepts this. (At least, the parts I talked to today did. I'm not sure how well that will sit across the whole organization.)
I really did not set out to make the FSF admit that they have no authority to back up the bold claims in the GPLv3. I'm okay with that as a result, though. I fear the admission comes at great cost to Linux (operating system, kernel, community, etc.), but that cost is nullified if the rest of the community and world outside the community continue to treat Linux (the operating system) as a work of software, and continue to take action to protect Linux (the operating system) as free software.
A Linux distribution is an aggregation of independent works under their own licenses *and* a collective work deserving of its own overall copyright and license. If that collective work is distributed under GPLv3, then derivative works *of that aggregation* must be licensed under GPLv3 also.
That's very much how I interpreted the situation. The problem is, this means the Linux kernel would be released under the GPLv3 license in the collective work, which is explicitly not allowed by the Linux kernel.
Meanwhile, the individual works in that aggregation remain under the original licenses their authors placed them under.
They continue to be available under the original license, yes, but they're also available under the license of the entire collective work.
Regarding proprietary operating system distributions containing GPL-licensed components, I should point out that Apple's proprietary OS X operating system comes with nice, little GPL-licensed goodies, like the GNU Compiler Collection or Samba. There is nothing shady going on there, afaik.
I would speculate that the motivation for the slight aggregation rewording in the v3 draft were the sort of weird EULAs Corel mistakenly applied to some early betas of their distro back when they were tapping into the GNU/Linux distributor business in 1999, and tried to use restrictive EULAs to limit the rights beta testers had on GPLd code on the CDs.
That, in turn, is not something an EULA could take away in any case, so I think the rewording just makes the implicit restriction on EULAs of aggregates in GPLv2 explicit.
"Linksys can distribute Linux in their hardware, only release the individual packages they included, and not release the whole distribution with tools, configuration files, etc. to install and run that distribution. The FSF accepts this (which seems odd, given the effort they've taken in the GPLv3 over ensuring that modified versions can be installed and run on hardware)."
They accept this because GPLv2 doesn't require it, so they've taken steps so that the entire build environment is required in GPLv3. I don't see what's odd about that, in fact I see it as entirely consistent.
Let's go back to what actually happened: http://lwn.net/Articles/50985/
After the first release of code, people found it didn't contain everything in the binary image:
"LinkSys (or the contractor which did its kernel work) has tried to slip in a kernel source tarball which does not include the code found in its binary image; that is a GPL violation, and the company has been caught."
If there are emails that say the issue with linksys was them not releasing the build tools, please post links to them.
My final comment for the moment, I promise. The other issue here is the licensing of an aggregate. The license of an aggregate affects what you can do with the aggregate as a whole, not what you can do with the parts in the aggregate. IANAL, but an aggregate is more than the sum of its parts - its this extra part that is what's covered by the license. And since only GPLv3 covers aggregation (just requiring the aggregate is as liberal as GPLv3), and GPLv2 says mere aggregation is not covered (although there's an implicit requirement to the same effect as GPLv3), the GPL doesn't "infect" [1] the license of the aggregate forcing the it to be GPL. In practice it looks like your aggregate license will have to be very liberal (BSD-like) if you have both GPLv2 and 3 works [2], but this doesn't stop you shipping v2 and v3 works together in an aggregate.
[1] Yes, the GPL isn't viral, but this is the best analogy I can come up with right now.
[2] And this is something the FSF should look into, possibly even with an eye to GPLv4, as to what aggregate license is recommended for an aggregate of GPLv3 and v2.
The patent deals restriction in the GPLv3 has no effect unless it specifically mentions one of the small set of packages explicitly licensed under the GPLv3 (currently none). Mentioning Linux in the deal doesn't count, it would have to reference "the GNU Compiler Collection", for example, or "GNU Emacs". Patent deals tend to deal on a grand scale, which makes it highly unlikely that any patent deal will ever be touched by the GPLv3.
I assume you're talking about the Microsoft/Novell-inspired paragraphs of section 11 (paragraphs 4 and 5). I'm not sure why you beleive that a patent deal triggering one or the other of these paragraphs would have to specifically identify a particular GPLv3-licensed package; no such requirement is in these paragraphs.
Under paragraph 4, the patent license must "provid[e] freedom to use, propagate, modify or convey a specific copy of the covered work to any of the parties receiving the covered work". The promise has to be applicable to specific copies, in the manner of the publicly-released parts of the Microsoft/Novell patent cooperation agreement (see:
http://www.microsoft.com/interop/msnovellcollab/patent_agreement.mspx
The same is true of the fifth paragraph of section 11, which is activated if the patent license is granted "(a) in connection with copies of the covered work conveyed by you, and/or copies made from those, or (b) primarily for and in connection with specific products or compilations that contain the covered work".
If instead you're saying that there is some legal reason why the *conditions* in those paragraphs, in referring to particular kinds of patent deals, have to mention the specific GPLv3-licensed work that those paragraphs grant permission to distribute, I don't understand why that would be so, or why it would follow from anything you've argued above.
The Linux kernel is not an aggregation. The RHEL5 media is.
RHEL5 has a license: It does not include terms that limit your rights beyond what the licenses of the works that make up the aggregate give you, and is thus acceptable under the terms of GPLv3.
The Linux kernel is not an aggregation. The RHEL5 media is.
Absolutely agreed. But there's another level between the source code of the kernel, and the source code of every application that could ever run on Linux the operating system.
RHEL5 has a license: It does not include terms that limit your rights beyond what the licenses of the works that make up the aggregate give you, and is thus acceptable under the terms of GPLv3.
If it has a license, it is not a pure aggregation, it's a copyrightable work.
Richard, I was referring to the fifth paragraph of section 11 "...the third party grants...a patent license (a) in connection with copies of the covered work conveyed by you..." i.e. the patent license has to be connected to a work licensed under the GPLv3. But you're right, the following wording "or...in connection with specific products or compilations that contain the covered work" does cover the case where a distribution of Linux has only a few pieces licensed under the GPLv3, provided that they're licensed explicitly under the GPLv3, and not just "version 2, or any later version". The termination of permission to distribute would also only apply to those few pieces. So, it's weakened, but not completely nullified.
Did you have any comments on the other problems I raised that result from taking the "pure aggregate" interpretation?
James, it's true that the start of the Linksys case was a violation in the kernel, but the FSF carried it farther than that. The article only says:
The FSF also points out that the kernel is only a part of the GPL-licensed software running on a WRT54G router. The FSF is trying to represent the copyright holders of all the affected software and resolve the whole problem. They will, they say, keep the community informed as things progress.
So, they were acting on behalf of a number of separate packages. But, what Linksys actually released was a full working distribution of Linux, not just individual packages. We could speculate that Linksys just decided to be nice. When the FSF demanded that they release the source for the individual packages, the Linksys lawyers said "Heck, why not just release the whole distribution and build tools too." Possible, but pretty unlikely.
If it has a license, it is not a pure aggregation, it's a copyrightable work.
I don't believe they're mutually exclusive, and it certainly wasn't my intent to suggest they were, but no matter: All the GPLv3 says is that the license and copyright of the aggregate must not limit the license of the individual components.
So, no problem.
The SCO litigation demonstrates how the GPL
license *does* have an effect, even though the
FSF isn't the one bringing the claim and
neither is Linus, the copyright holder on
the aggregate work. It's the author of the works infringed, the copyright holder on the pieces
inside the aggregated work, that is doing so, namely IBM.
GPLv3 won't be any different. And it will be
just as effective, hopefully more so.
By the way, if the Linux Foundation were to
follow the path you mention, not that it
plans to, it would be just as
difficult to make the switch as it will be
to switch to GPLv3, because all the authors
would have to agree, and some of them are
dead, disappeared, etc.
I wonder why so much energy goes into trying
to subvert GPLv3. There must be a piece I
don't see. The same thing happened with
GPLv2. It's a genuine puzzlement to me. It's
just a license, folks. And once it's out there,
it's not the FSF that controls how you use
it and in general it isn't the FSF that
enforces it. Enforcement is by means of
copyright law, which is powerful enough to
do the job. You don't have to be the
holder of the copyright on the aggregate
work to enforce your piece.
Did you have any comments on the other problems I raised that result from taking the "pure aggregate" interpretation?
I still don't see what the problem is. I do see one interesting difference with GPLv3 that I think relates to what you are talking about, in the provisions detailing the procedure for termination.
Draft 3 of GPLv3 introduces a cure provision in its termination provision. Since timely cure for a specific work, following notice, by a first-time violator results in automatic reinstatement of the license for that specific work, some of the leverage that the copyright holder had in enforcing GPLv2 is diminished under GPLv3. If there isn't timely cure, or the violator is not a first-time violator, then I think all the enforcement strategies that were available under GPLv2 will be available to the FSF, or any other relevant copyright holder, under GPLv3.
One consequence might be that a violator of both v2 and v3 works in a distribution shipped by that violator could get away with violating the v2 parts by complying with the v3 parts only, unless v2 copyright holders also enforce their copyrights. If GPLv3 encourages more v2 as well as v3 copyright holders to get active in policing violations of both licenses, that's probably a good thing.
I still don't see what the problem is.
Is that "Yes, these observations that the GPLv3 license terms can't apply beyond individual covered packages are true, and we're already aware of that fact, so there's no problem." or "No, these observations are inaccurate and the GPLv3 licensing terms can apply beyond the individual packages."?
(For those who don't know the background, Richard Fontana works for the SFLC, and is their primary representative on Committee A for the GPLv3 revision. I greatly admire him and credit much of the progress we've made since the first draft to his mild-mannered brand of sanity.)
pj, apologies, but I don't see how your comments are relevant to the discussion. Unless... ah, I see, you misinterpreted what I was saying.
The SCO litigation demonstrates how the GPL license *does* have an effect...
I wasn't saying that the license as a whole has no effect, just that updating the license would have no effect. At the point the GPLv3 is finalized, everything licensed under the GPL will be licensed under the GPLv2 (or maybe still v1). Some will add "or any later version", but those can still be used, modified, and redistributed under the GPLv2 license. It will be years, possibly decades, before enough packages explicitly specify a GPLv3 license to be a significant percentage in the marketplace. So, if there are companies concerned about the effect of launching the GPLv3, they can stop being concerned.
By the way, if the Linux Foundation were to follow the path you mention, not that it plans to, it would be just as difficult to make the switch as it will be to switch to GPLv3, because all the authors would have to agree, and some of them are dead, disappeared, etc.
It's not that difficult if they treat the kernel as a compilation of the contributors' work. And, what difficulty is involved would be far more likely to happen for a license they actually agree with than a license they disagree with.
I wonder why so much energy goes into trying to subvert GPLv3.
My goal is to make sure people have thought through the issues. When I hear "We understand the problems, we understand the options available and the consequences of those actions, and are prepared to accept the consequences of our choices." I consider my work to be done.
All the GPLv3 says is that the license and copyright of the aggregate must not limit the license of the individual components.
Hmmmm... let's see where this takes us. The crux of the matter is on whether a particular work is an aggregate under the terms of the GPL. If it's an aggregate, it escapes from the standard downstream licensing requirement "to be licensed as a whole at no charge to all third parties under the terms of this License". The GPLv3 phrases it "You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy... This License gives no permission to license the work in any other way...", but again, an aggregate is not subject to that requirement.
For the sake of exploration, let's say that "aggregate" is a term with a unique definition in the GPL and separate it from copyright law. Here's the relevant paragraph in the GPLv3:
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
It'd be tough to treat the definition of "aggregate" as completely separate from copyright law, since they're using the term "compilation" in the definition. Under ordinary copyright terms, a compilation would be subject to the downstream licensing requirements of its parts. But let's say the GPL's "aggregate" is a uniquely defined exception to an ordinary compilation. This makes a certain amount of sense, as the GPLv2 treats collective works (a variety of compilation) the same as derivative works: "...the intent is to exercise the right to control the distribution of derivative or collective works based on the Program."
That gives us the first part: an aggregate under the GPL can be a copyrighted work of software containing both other people's works and original work by the owner of the compilation copyright. So, how does a compilation qualify as an aggregate? Its components have to be "not by their nature extensions of the covered work". What would or wouldn't be an extension isn't very well defined, and extensions aren't mentioned anywhere else in the license.
Let's assume, again for the sake of exploration, that Linux the operating system is not an extension of either the kernel or GNU packages. As an aggregate it escapes the ordinary GPL licensing requirements. Are there any conditions on its distribution? Only that the compilation doesn't put any additional limits on the exercise of rights. There's no requirement that the compilation doesn't grant additional rights.
James suggested a BSD-style license for the compilation. But, the important point about a compilation is that the license it's released under applies to all portions of the compilation. If you released a BSD compilation of GPL software, each line of the GPL software could be legally used under the terms of the BSD license, completely invalidating the copyleft nature of the original GPL license. Under ordinary compilation copyright law, you couldn't legally to do that. You can't, for example, take a selection of chapters from various copyrighted books, bind them together in a book of your own, and release the book under a Creative Commons license. You would be violating the original authors' copyright in the text, since they didn't give you permission to release that text under a CC license. But, "aggregate" is an exception to ordinary compilation copyright law, so it might be possible. Still, the most likely interpretation is that when they say that the aggregate can't "limit the access...beyond what the individual works permit", you have to assume that all downstream users must have the same access, so the license of the aggregate must also be copyleft. (You might say it's a BSD license, but it would be a BSD license with a copyleft modification forced by the GPL code, so it would essentially be a copyleft license.)
This carries us the rest of the way: you can have a compilation work of software, containing works released under the GPLv3, and release that compilation under another license. The license has to be copyleft, but it could be the GPLv2. (It could also be the hypothetical "Linux License".)
The weak nature of the GPLv3 is still true in this scenario: the various terms and restrictions and termination clauses only apply to the few pieces within the compilation explicitly licensed under the GPLv3.
If we can get a clearer definition of "extensions" in the GPLv3, I'm comfortable with this approach. Is the FSF comfortable with having a Linux distribution (compilation) released under a GPLv2 license even if it contains GPLv3 packages?
[Note from Allison: for some reason this comment was flagged as spam.]
The Linux kernel is quite obviously not a mere aggregate, it's a single work.
Back to the actual point: 'The crux of the matter is on whether a particular work is an aggregate under the terms of the GPL. If it's an aggregate, it escapes from the standard downstream licensing requirement "to be licensed as a whole at no charge to all third parties under the terms of this License". The GPLv3 phrases it "You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy... This License gives no permission to license the work in any other way...", but again, an aggregate is not subject to that requirement.'
The aggregate's (or compilation, can we choose a term please) license doesn't affect the license of its component parts. The license for the compilation is just the license for distributing the entire thing as a whole, it doesn't elimiate or overwrite the licenses of the parts of the compilation or stop you from exercising those licenses independently, or excuse you from following the obligations of those licenses.
So I'm not suggesting the BSD license as a way of somehow relicensing by stealth, since aggregation isn't an exception to normal copyright law. Somewhat related is copyright on phone directories - the individual entries cannot be copyrighted, since they're just facts, but the compilation of them can, since effort has been put into the layout, indexing, business artwork or whatever [1]. This copyright doesn't stop you extracting all the data for your own use, but what it does stop you is making exact duplicates of the phone directory.
[1] Actually the case law on phone directories is quite complex, but IANAL and this is just an analogy.
The Linux kernel is quite obviously not a mere aggregate, it's a single work. [...] can we choose a term please
Well the GPL uses "aggregation" and the Berne convention and CC use "collective".
Can we also be clear about when we mean the kernel and when we mean a distro as well.
The Linux kernel is clearly a single work with multiple authors. The current kernel is clearly a derivative of at least some work done on previous kernels. It is not in any way, shape or form a collective work.
A GNU/Linux distro is clearly a collective work. I hadn't thought about collective copyright before but I can see how that might well be the case. How would that interact with the underlying copyrights of the collected works, since the collection is not of mere facts or out-of-copyright work?
Umm, where'd my comment go? For those playing along at home, the essence was that the copyright on a compilation does not override or erase the copyright on the component parts, nor does it stop you taking individual parts and distributing them according to their own license, nor does it exclude you from obeying the conditions of their licenses when you distribute the whole compilation. An aggregate is not an exception to normal copyright law.
You could not ship a GPLv2-only kernel linked to a GPLv3-or-above code. So if the FSF decide to change the license of e.g. glibc to GPLv3-or-above, then Linux distributions have a problem.
However, you can ship a GPLv2-only kernel with a GPLv2-or-above glibc, and then a bunch of GPLv3-or-above apps to run on top of it - e.g. tar, Emacs or gcc. Linux distributions would be fine with this arrangement.
So Allison's point about a possible licensing conflict is valid, but only if a particular small subset of FSF-owned software is relicensed - i.e. that which is linked into the kernel or other GPLv2-only code.
Allison said: It will be years, possibly decades, before enough packages explicitly specify a GPLv3 license to be a significant percentage in the marketplace.
Not if the FSF upgrade all their userland packages soon after the license is released. There's a lot of GNU software about. Other projects may also like the new terms and decide to upgrade their CVS HEAD to "v3 or later". Of course, people may choose to fork these packages - but I don't see the point, given that each one is a discrete unit. Of course, if the FSF upgrade things like glibc, then (as mentioned above) there is a much larger problem, and a fork would be required for the kernel to use unless it also chose to upgrade.
James is right on the money about aggregates.
Gerv: Running a GPLv3 only glibc on a GPLv2 Linux kernel is fine - see the kernel's COPYING file:
NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work".
I'd also point out that the 'system library/major component' exception includes the kernel, regardless of the license, so the glibc under LGPLv3 on top of a non-GPLv3 kernel sounds fine to me, from the perspective of LGPLv3.
There are LGPLv2+ licensed libc implementations that work on top of non-GPLv2 licensed kernels, afaik. BeOS apparently includes libroot, which is a fork of GNU libc, and the BeOS kernel certainly isn't GPLv2 :)
James: I wasn't referring to running glibc "on top of" the kernel, but linking them together. So the statement in the kernel's COPYING file is irrelevant. glibc is not a user program using kernel services by normal system calls; the relationship is the other way around (the kernel uses glibc).
Here's how I understand the situation. I'll set it out as bullets so you can tell me which one I'm wrong about :-)
- The kernel makes C library calls
- In Linux, glibc is the C library
- So, the kernel is linked together with glibc
- This is a different thing to a user program running on top of the kernel and making standard kernel interface calls
- glibc, under the LGPL, is fine with being linked with code of other licenses (including proprietary or GPLv2)
- The kernel, under GPLv2 only, must be linked only with code under licenses compatible with GPLv2 (e.g. GPLv2, LGPLv2, BSD, MIT)
- LGPLv3 is not a GPLv2-compatible license; it contains additional restrictions
- So, it's not possible to link a GPLv2-only kernel with an LGPLv3+ glibc, because the kernel's license prevents it.
Dalibor: the system library exception is not relevant because the kernel and glibc are being shipped together ("unless that component itself accompanies the executable", GPLv2 section 3, last sentence).
Gerv: Point 1. The kernel doesn't call functions in libc and isn't linked against it.
Post A Comment:
STAY CONNECTED
RECENT COMMENTS
- James on GPLv3, Linux and GPLv2 Compatibility: Gerv: Point 1. The kern...
- Gerv on GPLv3, Linux and GPLv2 Compatibility: James: I wasn't referri...
- Yuhong Bao on GPLv3, Linux and GPLv2 Compatibility: I'd say dual-license th...
- Dalibor Topic on GPLv3, Linux and GPLv2 Compatibility: I'd also point out that...
- James on GPLv3, Linux and GPLv2 Compatibility: Gerv: Running a GPLv3 o...
- Gerv on GPLv3, Linux and GPLv2 Compatibility: You could not ship a GP...
- James on GPLv3, Linux and GPLv2 Compatibility: Umm, where'd my comment...
- Rob Myers on GPLv3, Linux and GPLv2 Compatibility: The Linux kernel is qui...
- James on GPLv3, Linux and GPLv2 Compatibility: [Note from Allison: for...
- Allison Randal on GPLv3, Linux and GPLv2 Compatibility: All the GPLv3 says is t...
RADAR TOPICS
Dalibor Topic [04.13.07 06:27 AM]
I don't think licenses of individual components of a distribution, can affect the licensing of other, independent components, as long as we're talking about free software licenses.
There is no need to put everything on some FTP server under the GPLv2 only, just because there is a GPLv2-only-licensed piece of code mirrored on them.