How GPLv3 tackles license proliferation (LinuxDevices.com)
The most obvious way to limit license proliferation is to write new licenses as rarely as possible. So while updating the GPL, it's good to be thorough so that it doesn't have to be done too often. What any one license can do to lessen the problem is less obvious, and this is an area where GPLv3 is breaking new ground. In case the more controversial provisions of GPLv3 have overshadowed the provisions that tackle license proliferation, I've put together this summary as a discussion primer."
Posted Nov 10, 2006 21:27 UTC (Fri)
by error27 (subscriber, #8346)
[Link] (18 responses)
That's not a very thourough explanation, and I still don't get it...
You can add restrictions, but you can't remove them right? So imagine someone takes my code and adds a restriction. I obviously don't want that restriction or I would have added it myself. As a result, I can't take use code from their fork... It's like when Linux guys use BSD code, the BSD guys can't take it back.
Obviously the FSF has gone to a lot of work to make the GPLv3 compatible with the Apache license, but the problem is that now it's not compatible with the GPLv2 without the "or later" clause. That seems like a step backward.
There is a lot of GPLv2 only code already. For example, I hear that there is enough GPLv2 only code in HURD that it won't be relicensed under GPLv3. Now each project has to decide whether to go GPLv2, GPLv2 with the "or later" clause, or GPLv3.
What am I missing here?
Posted Nov 10, 2006 22:02 UTC (Fri)
by khim (subscriber, #9252)
[Link] (4 responses)
You can add restrictions, but you can't remove them right? So imagine someone takes my code and adds a restriction. I obviously don't want that restriction or I would have added it myself. As a result, I can't take use code from their fork... It's like when Linux guys use BSD code, the BSD guys can't take it back. True but it's rarely the case in practice. LGPL projcts don't suddenly get forked to GPL projects. And even BSD projects don't suddenly fork to GPLed projects (even if it's legal to do). On practice the only license-based forks are proprietary ones - and GPLv3 forbids this kind of forking. There is a lot of GPLv2 only code already. For example, I hear that there is enough GPLv2 only code in HURD that it won't be relicensed under GPLv3. Now each project has to decide whether to go GPLv2, GPLv2 with the "or later" clause, or GPLv3. Fair enough. What am I missing here?
Big picture. As usual. Most of the "GPLv2 only" code comes from Linux and linux-related projects (Linux kernel itself, HURD and it's drivers, Busybox and it's udev replacement, etc). And most of it is unusable for non-kernel projects (it's mostly drivers, drivers, drivers - good stuff for any OS kernel like HURD, but hardly usefull elsewhere). On the other hand amount of Apache-licensed code, EPL-licensed code and so on are is... huge. And there are a lot of interest in using this code for GNU projects (see here, for example). Obviously the FSF has gone to a lot of work to make the GPLv3 compatible with the Apache license, but the problem is that now it's not compatible with the GPLv2 without the "or later" clause. That seems like a step backward. Not really. The only way to keep the stuff compatible with the GPLv2 without the "or later" clause is to never update the GPL. And that's just plain stupid: how can we be sure this license will be any good 100 years from now ? After all changes in the law and technology ? GPLv2 was designed to be updateable for a reason (read the section 9 of GPLv2). And the ability to remove the "or later" clause was kind of "fail-safe" mechanism (if FSF will ever produce bad license it's easy to drop "or later" clause for any projects with moderate level of activity but it's very hard to add such a clause for a project with a lot of contributors). Linus made it a problem, not FSF.
Posted Nov 10, 2006 22:51 UTC (Fri)
by AJWM (guest, #15888)
[Link] (3 responses)
That turns out not to be the case.
For example, the Qt library is GPLv2 only (plus some other licenses that are completely GPL incompatible). I think MySQL is GPLv2 only although it has their "FOSS exception" which may make it combinable with GPLv3.
Indeed, most commercial GPL-licensed (dual licensed) code is GPLv2 only, for the simple reason that the "or any later" is way too open ended.
Posted Nov 11, 2006 0:33 UTC (Sat)
by drag (guest, #31333)
[Link]
Not right away, no point in rushing it. But realy the ability for the GPLv3 to eliminate the need for a whole catagory of licensing should be attractive enough for most developers.
The 'catagory' I am talking about is 'GPL compatable, but with less copyleft'.
So if you want to make something that is open source and you want to make it so your able to have stuff link against propriatory software or link in specific ways or be compatable with old versions of the GPL or whatever that you want then there realy isn't any point anymore to not use GPLv3 + permissions.
That sort of thing will make life much easier for everybody.
Posted Nov 11, 2006 1:50 UTC (Sat)
by thebluesgnr (guest, #37963)
[Link]
The "or later" clause is useful for projects where several people hold the copyrights.
Posted Nov 13, 2006 0:14 UTC (Mon)
by k8to (guest, #15413)
[Link]
Not that this invalidates what you said, but it perhaps puts it in a different light?
Posted Nov 10, 2006 22:14 UTC (Fri)
by hathawsh (guest, #11289)
[Link] (5 responses)
As the original author, you are well within your rights to edit the license and say that no additional restrictions may be added downstream, however, people might then have trouble combining your code with others'.
Posted Nov 10, 2006 22:43 UTC (Fri)
by proski (subscriber, #104)
[Link] (3 responses)
Posted Nov 11, 2006 0:30 UTC (Sat)
by hathawsh (guest, #11289)
[Link] (2 responses)
Posted Nov 11, 2006 2:57 UTC (Sat)
by JoeBuck (subscriber, #2330)
[Link] (1 responses)
Posted Nov 11, 2006 10:02 UTC (Sat)
by drag (guest, #31333)
[Link]
but people started to think they were smart and started to add extra restrictions. Stuff like "This is GPL, but if your military you can't use it" type thing.. which doesn't make sense because your making your GPL-ed code non-GPL compatable.
The GPLv3 + permissions model and making it more compatable is wonderfull because no matter what sort of confusing mish-mash of permissions and whatnot you end up with you always know what freedoms and obligations your under when running anything labled 'GPLv3'.
Posted Nov 14, 2006 3:47 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link]
You can't add restrictions to GPLv3(draft), only allow more freedoms. And the combination will have only the intersection of the extra rights (probably none).
Posted Nov 11, 2006 19:36 UTC (Sat)
by stevenj (guest, #421)
[Link] (3 responses)
What the GPLv3 deals with is the legal incompatibility of several common licensing variations: it makes it legally possible to combine such code, in the same way that BSD and GPL or GPL and LGPL code can be combined.
It does nothing about social incompatibility — it cannot prevent you from choosing not to re-incorporate modified code with additional restrictions.
In practice, people modifying code and expecting to get it incorporated back into the upstream project will need to use the same license variant. The same as with LGPL and BSD projects today, and doesn't seem to be a major problem. On the other hand, reducing legal incompatibility is a great benefit for people creating new programs that want to use useful snippets from other programs.
Posted Nov 11, 2006 21:02 UTC (Sat)
by error27 (subscriber, #8346)
[Link] (2 responses)
Gnash is one recent example of stolen code. Who has the social problem the gnash guys or the gameswf guys? Probably the GNU guys.
I use the GPL for two reasons 1) I'm a bastard and 2) everyone else is a bastard. I'm not asking people to give their code back, I'm taking it back.
Posted Nov 12, 2006 0:01 UTC (Sun)
by drag (guest, #31333)
[Link] (1 responses)
I only say this for a couple reasons.
Plus I thought it was the point of the BSD license to be non-copyleft so peopel can use the code and impose additional license requirements on it. So isn't the gnash people doing exactly what the BSD license people want them to do?
Soo.. that seems about as anti-social as somebody baking their neighbor a nice cake.
Posted Nov 12, 2006 18:19 UTC (Sun)
by b3timmons (guest, #40286)
[Link]
License
All the source code for this project has been placed in the public
Posted Nov 12, 2006 16:57 UTC (Sun)
by coriordan (guest, #7544)
[Link] (2 responses)
The next sentence in that paragraph was meant to be the explanation for why the answer is "no": The extent to which GPLv3 increases compatibility is the same as the extent to which it is more compatible. So extras can be added to GPLv3, and GPLv3 can accomadate those same extras - both in itself and in other licences.
Posted Nov 13, 2006 1:19 UTC (Mon)
by error27 (subscriber, #8346)
[Link] (1 responses)
To be honest, I know that the GPLv2 is not compatible with the Apache license, but I've never looked into why. My understanding is that the base GPLv3 can incorporate code using the Apache license but there are extra restrictions that you may not be able to add. Is that the case or all the extra restrictions compatible with the Apache license?
Posted Nov 13, 2006 11:01 UTC (Mon)
by coriordan (guest, #7544)
[Link]
The list of extra requirements that can be added is in section 7 of the current discussion draft: http://gplv3.fsf.org/comments/gplv3-draft-2.html. When you combine two software packages, GPLv2 says that the combination cannot contain any additional requirements. It does this to prevent additional requirements which would limit the freedoms the GPL is written to give people. Sometimes this is too strict. There are some additional requirements that are so trivial that they are inconsequential (such as additional warranties), and there are some requirements which are not in GPL but which do not conflict with the goals of the GPL (such as certain patent retaliation plans). So with GPLv2, you could not combine GPL with Apache because there would be no way to distribute the combination - it wasn't possible to simultaneously comply with both licences. GPL said "no additional requirements can be added", and Apache contained additional requirements regarding patent retaliation. With GPLv3, the GPL says that certain types of additional patent retaliation provisions are ok, and the Apache patent retaliation provisions meets the definition of an ok additional provisions. So it will be possible to simultaneously comply with GPLv3 and Apache - so they will be compatible.
"I've seen the question asked in a few places, whether these options could be used in configurations that would make two GPLv3 projects incompatible, and the answer is no."
How GPLv3 tackles license proliferation (LinuxDevices.com)
How GPLv3 tackles license proliferation (LinuxDevices.com)
> Most of the "GPLv2 only" code comes from Linux and linux-related projects [...]. And most of it is unusable for non-kernel projects ...How GPLv3 tackles license proliferation (LinuxDevices.com)
Probably most will want to change to GPLv3 eventually.How GPLv3 tackles license proliferation (LinuxDevices.com)
Trolltech is the copyright holder for all the Qt code, so they can license it under the GPLv3 easily when necessary. Same for MySQL I guess.How GPLv3 tackles license proliferation (LinuxDevices.com)
The "GPLv2 only" or "our comercial license" crowd will have the option to add GPLv3 in some fashion later. It's the folks who allow multiple copyright ownership (default) into their project who get bound by "GPLv2 only" for better or for worse.How GPLv3 tackles license proliferation (LinuxDevices.com)
I think the intent is to allow the combination of projects that use different restrictions. If your project chooses restriction A, and another project chooses restriction B, then a project that combines the two will necessarily have both restrictions.How GPLv3 tackles license proliferation (LinuxDevices.com)
I don't think GPL can be edited and redistributed. See the beginning of the GPLv3 draft:
How GPLv3 tackles license proliferation (LinuxDevices.com)
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
Indeed you are correct. Thanks.How GPLv3 tackles license proliferation (LinuxDevices.com)
The fact that the basic document can't be changed doesn't prevent people from modifying the terms. What's typically done is to include the GPL, and then say, in the source code, that the license terms are the GPL plus some extra permissions. That's what's done for gcc's runtime libraries, for example.
in practice this does not matter
ya that is not uncommon...in practice this does not matter
How GPLv3 tackles license proliferation (LinuxDevices.com)
How GPLv3 tackles license proliferation (LinuxDevices.com)
You can add restrictions, but you can't remove them right? So imagine someone takes my code and adds a restriction. I obviously don't want that restriction or I would have added it myself. As a result, I can't take use code from their fork... It's like when Linux guys use BSD code, the BSD guys can't take it back.
It's getting to be less and less of a problem because BSD is dying but people still steal BSD code and relicense it under the GPL.How GPLv3 tackles license proliferation (LinuxDevices.com)
I don't suppose you can come up with a better example then 'Gnash' vs 'gameswf' as people being 'antisocial'?How GPLv3 tackles license proliferation (LinuxDevices.com)
1. Gameswf development is dead, and has been dead for a while now.
2. The Gnash folks said that they'd be happy to release any code back to Gameswf that they could find usefull.
Agreed that GPL is not antisocial. BTW, gameswf is not under BSD. From the gameswf web page:How GPLv3 tackles license proliferation (LinuxDevices.com)
domain. Do whatever you want with it; no copyright, no restrictions
whatsoever. The code comes with ABSOLUTELY NO WARRANTY.
How GPLv3 tackles license proliferation (LinuxDevices.com)
Is there a list of the extras yet?How GPLv3 tackles license proliferation (LinuxDevices.com)
How GPLv3 tackles license proliferation (LinuxDevices.com)