Slashdot Mirror
GPL 3 Forking Risks Discussed
sebFlyte writes ""I fear a lot of unpleasant forking action when the GPLv3 comes out." The words of Debian maintainer Matthew Palmer. ZDNet has an interesting look at the possibility of forking when GPLv3 emerges, with lots of reassurance from Eben Moglen (the FSF's chief lawyer)."
At least they aren't GPL spooning.
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
Or is this not the best time for the Open Source community to divide itself (admittedly, there may never be a *good* time for such an action...)? Is the GPL much of a problem in its current incarnation? Like they say, if it ain't broke...
If your theory is different from practice, then your theory is wrong.
Oh yeah, this is slashdot.
Has anyone ever encountered any pleasant forking action? This google image search is leading nowhere... perhaps safesearch needs to be off?
Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated.
I doubt we will see any unplesant forking ,The license must evolve just as the software does . . .
If we didnt patch the linux kernel and left security holes in it we would have alot of massive problems , the license is like any other code(all be it legal code) bugs will arise and it will need to grow to support new platforms and new inovations
Thus the clause in the license that the parent states gives the backwards and forwards compatibility if you want it
unplesant forking will rarely occur
The only things certain in war are Propaganda and Death. You can never be sure which is which though
Since the majority of GPL-ed code (with Linux kernel being the most notable exception) is licensed under "GPL v2.0 or (at your option) any later version", wouldn't it be theoretically possible for FSF to publish, for example, GPL v10 saying "You can use and modify this software without any restriction whatsoever, but only if you are Microsoft (Sun, Google, whatever)"? In other words, they can effectively sell the rights to close the sources off all GPL-ed Free Software. Of course, Richard M. Stallman wouldn't do this, but, sadly, he will not live forever, and anyway, whole system shouldn't base its existence and safety on one man.
He has a particular purpose in mind, which is forcing everyone to release source to their software. Personally, I have a different goal - releasing my pet projects for free while making sure any commercial users will talk to me and negotiate attribution, compensation and so on. GPL V2 seams Ok for that, but I will never put an "... or later" clause. Maybe eventually FSF will prevent me from using my own code in commercial products or something. I am not sure intellectual property laws are beneficial (at all or beyond say 5 year duration), but even if people are allowed to copy binaries, I sure shouldn't be forced to give up my source.
Given that Linus/many Linux developers seem to have somewhat different goals than RMS as well, it would indeed make sense for Linux developers to fork the license. It's time for something that follows pragmatic wishes of most free software developers rather than one person's political agenda.
All this talk about forking is well and good. But what inquiring minds want to know, is will the GPL3 be written in a workmanlike writing style.
Presumably this is to allow more protection from/for patents and copyrights.
Most distributions include demo versions of commercial software, software in the public domain and software under other licences.
Apache is included in most distributions and apache is under the Apache License and apache aren't entirely convinced their licence is compatible with the GPL...
If Apache can be included, where's the problem?
Just some early morning thoughts...
Remember that the version 2 of the GPL dates from June 1991. It is an incredible document, and I agree with Moglen's assertion that it's the basis of a multi-billion dollar industry. Stallman will go down in history as a visionary.
But after 14 years, GPL/2 is starting to age. Yes, it addresses current problems, but remember that software written and licensed today must still be protected and viable in 15 years' time.
There is absolutely no point in postponing the introduction of GPL/3. There must be a migration, and there will be a period of overlap.
But change is not something to fear in itself. It's something to plan and to manage, and in this case, it's essential.
Last thing: if you followed the FSF's recommendations as to how to use the license, your code would contain this text:
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation; either version 2 of
# the License, or (at your option) any later version.
Which all my company's GPL software contains.
Thanks to Moglen, and the FSF for their fantastic work.
Sig for sale or rent. One previous user. Inquire within.
- As the copyright holder, you can always decide to release your code under another license.
- The "or later" clause is at your option, "you" being the licensee. This means that that clause can only grant new rights, not remove rights, since anybody can always decide to chose to see the software as licensed under GPL v2. This is similar to dual licensing.
Both points mean that your fears are not founded.Watch great movie opening scenes!
Making GPL2 and GPL3 incompatible with each other is the kind of thing I'd expect Microsoft to do.
Free Software: Like love, it grows best when given away.
if you don't trust RMS then why the fuck are you using his license?
People change. They can turn greedy and resentful. They may grow old and senile. And inevitably, they will die, and the organizations they lead will be repopulated with other people whose ideas are non-identical.
Someone's past actions are infinitely more trustable than his future.
If you trust RMS today, then use the GPL. If you trust RMS and all his succssors in the future forever, certain they can never be bought, bribed, or bludgeoned, then use GPL plus "at your option, any later version"
If GPL3 mentions anything that is not in GPL2 (ie it places restrictions relating to patent litigation etc) then it cannot be compatible with GPL2.
The only thing the GPL3 can do and still be compatible with GPL2 is to have fewer restrictions. In which case, what's the point, we already have BSD.
That would be pretty stupid.
Imagine a embedded device running linux. You can use it but the distibuter gives you no updated "firmware" and thus no binaries. The only way to find out it runs linux is to "hack" it.
This might a way builders of embedded hardware try to circomvent the GPL since they give you no access to the binaries. (This is the way the embeded hardware builder would explain it, this is open to discussion. )
Now comes the strange part: give out firmware updates would violate the GPL. now lets talk about stupid.
This clause was added in the 2.4.18 version of the file It did not exist prior to that. This seems that this would create a problem. If I submitted my work into the Linux kernel prior to 2.4.18 I would have submitted my work under the generic GPL and applied the license allowing for future versions of the GPL to be used. For Linus to make a blanket change to the licensing would violate the copyright holders intention and would be essentialy a violation of the GPL. Linus may have avoided this by securing certain rights from the copyright holder when the code was submitted. I doubt that happened. Also, any derivitive works that changed the licensing of the code to be more restrictive would seem to violate the copyright holders license.
The problem gets worse, I think, because if I submitted code after the 2.4.18 release I would have submitted my code under a license that restricted my code to be license under GPL v2 only. Which would mean there is code in the kernel that is licensed under two different sets of restrictions.
There are two reasons I only use GPL v2.0 and not any later version:
1) I don't want to license my software under terms I have never seen or read and over which I do not have any control.
2) I strongly suspect that the "or any later version" part is not legally enforcable towards the copyright holder because the copyright holder (in this case that's me) had no opportunity to review the terms of a later version when he put that line in and does not have any control over such later version. The clause would be void in most jurisdictions IMHO. (but IANAL)
Well...the parent poster is being ironic, but at least partially right.
;-) code from other projects and incorporate it in theirs, then just to join an already existing one.
I mean, no one can deny, when even having a superficial look at the different projects that are on sourceforge, that an enormous amount of them are just plain dead, or whithering away. Exept for the really big projects - which have like, a treshold of minimum 3 developers (or people that at least keep busy themselves a bit with the code) and half a dozen 'helpers' - almost all the smaller projects really just sizzle out.
And then, some day, a new lonely coder gets up with the same idea, and he begins from scratch again, even though there are already myriads of dead projects that do the same. So, indeed, small projects keep being replicated, and, contrary to what one might exept, rarely is it working on top of an already existing (dead) project. Mostly they invent the wheel all over again, then they whizzle out (if they can't muster enough critical interest), and the whole process repeats itself.
The result is what you see on sourceforge: some big thriving projects, a lot of smaller almost-one-man projects that usually go completely dead real soon (you always have exeptions, ofcourse), and already massive amounts of complete stone-cold-graves of forgotten small projects. Which anyone hardly seem to notice even when they decide to do similar things.
It is rather mysterious how this is possible, seen the fact that FOSS projects are open to all. Why does there have to be 8 little projects that do in essence the same (but starve to death), instead that they all pull together and make one viable project? why do people reinvent the wheel, when there are so many basic (yet dead) projects they could use to build upon? Something is missing here...
I think, the answer has partly to do with ego's: ppl want it to be "their" project, and even if others are welcome to contribute, those that started with the project (especially if it are one-man-projects) like to feel it is and remains 'theirs'. So, *even* if they know there are other, similar projects, they will rather steal (well, in case of OSS it's just allowed use
But that doesn't explain it all, because not all coders are like that, and even those don't seem to be able to make efficient use of other works. The plain fact is, some do not really bother, or think it's to dificult to get to learn an already existing codebase (and simply prefer to start with one, so they know it well), and - more importantly - sourceforge sucks in finding projects that are similar to others, based on their internal code. Yes, sure you can search for generic terms on the application-level, but it's real hard to actually know what code could be useful or similar to some project you envisage.
In any case, it's very clear which curve the projects on sourceforge follow: a very large part of dead or near-dead small projects at one end, a certain amount of medium projects that never seem to amass the critical level but still keep hanging on, and then a few big projects that have 3 or more active developers, a buch of 'helpers' and a large userbase, which will thrive.
I'm not sure if all this is good or bad or 'normal', but I do think a system should be found to pull together all the working forces and/or code of (similar) small projects, so the chance of survival rises, there is less redundancy and reinventing the wheel and a critical mass can be more easily abtained. For that to happen, I fear sourceforge (and the likes) will have to become more efficient and just plain capable of letting people more easily recognise and bundle together similar projects in the first place.
--- "To pee or not to pee, that is the question." ---
Then the GPL would no longer be an Open Source license, or even a Free Software license.
See items 5 and 6 of the Open Source Definition ("No Discrimination Against Persons or Groups", "No Discrimination Against Fields of Endeavor"), or the Free Software Definition ("you should be free to redistribute copies, either with or without modifications, either gratis or charging a fee for distribution, to anyone anywhere .")
If they'd stop talking about what it "will be" and "wont be", and put out a draft, they'd have *constructive* discussions instead of guessing!
Look, seriously, yes, there are grave concerns, and its a hideously important document. However, there is no reason why they cant put v2 into a wiki, add some proposed changes, and start working with the community on modifications.
This is at least the 10th story that has discussed A DISCUSSION OF WHAT WILL BE IN THE NEW VERSION!
Its not even 5 pages long. They've already mentioned the high points of areas they want to improve/change (patents, webservices), and everyone is well informed!
So just get on with it, and stop playing the vaporware game.
In the meantime, the only GPL-like license that actually closes the web services loophole (the Affero GPL), which is mentioned as a template for the GPLv3, ISNT GPL compatible!
It would be nice to have a GPLv2 compatible license that closes that loophole, so I'm waiting anxiously for a look at a license that will do it.
Enough talk - WRITE!
GPL'd web-based tradewars themed space game
It would be wonderful (especially in the Java camp) if the new GPL was compatible with the CPL and the Apache 2.0 licenses. Apparently the FSF even agrees somewhat to the additional restrictions that these licenses make (see http://www.gnu.org/licenses/license-list.html ), so it would be nice to address the problem.
Being able to use Apache code and Eclipse with GPL projects would give a great boost to GPL Java projects.