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.
site's responsive
...
6 comments
oh no its the rapture
hello
can anybody hear me?
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.
So what is in GPL3 thats causing all the commotion? All I hear is people saying they'll do this and that and them saying no we wont, and when its out you wont worry. Does anyone even know what differences will be in GPL3?
The only change I'd like to see is " this code cannot be used by Microsoft or SCO or its subsidiaries, or employees in any fasion ". Or better "this code cannot be used by GW Bush to kill innocent people in any country under any circumstances whatsoever" or something to that effect.
Theyre using WindowsNT to drive the battleships anyway.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
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.
LOL but...
posted in the wrong topic
Le français vous intéresse?
Forking seems like less of a problem than the simple that Linux simply cannot practically be released under a license other than the GPL v2. Linus established Linux as being licensed specifically under version 2 of the GPL. All contributors to Linux hold the original copyright to the code the contributed. The contributions -- as modifications to code explicitly licensed under only version 2 of the GPL -- are themselves explicitly licensed under only version 2 of the GPL. Even if there were compelling reasons to migrate Linux to GPL v3 (patent provisions, etc.), the only way to do so legally would be to contact every single contributor to Linux ever and get them to explicitly agree to re-license their contributed code under the new version of the GPL.
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.
Bill could actually revoke Linus' right to distribute the linux kernel!
......However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
It might not be possible to distibute it under gplv3, but that part was licences under gpl v2. and ssince you licenced it under gplv2 it may still be distibuted under point 4:
4.
That makes the gpl inrrevokeable.
Nice thought expriment, but i would liked to have seen the part of the licence that would be violated.
but Bill could probably sue the shit out of them all anyways.
As always this is true. He could be "not right" but still sue, as the sco tries. MS could sue many many small competitors to death.
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)
He's a smart shit. People don't like change - fear it rather. There are some valid concerns about license "portability" but I can't think of anyone else I would rather have sorting it all out.
Join the Slashcott! Feb 10 thru Feb 17!
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." ---
one of two possible scenarios exists here:
a) this new version of the gpl is going to cause a real problem, and there will be all sorts of forking and license incompatibility issues; or
b) this is a non-issue, but nevertheless the community now has to deal with clearing up a bunch of misconceptions, muddy water, and FUD.
either way, it's a problem. why does there even have to *be* a new version of the gpl? didn't they write it properly the first two times? personally, i admire the ethical intent of the gpl, but it's this kind of aggravation that makes the BSD license the only way to go.
if i'm a grammar nazi, you're an illiteracy nazi.
I don't see that big of a risk that projects fork. The only thing that would require forking is if some devs wanted to go with GPL 3 and some wanted to stick with GPL 2. However I don't think the differences between them will be big enough that anyone would go to such drastic measures as forking.
What I am worried about though is how will large projects like the linux kernel transition to the new version? You'd have to hunt down all developers and request permission from each and every one of them. This seems like a next to impossible task for a project that's comming up on its 14th year birthday.
This isn't a problem for projects that either put "or later" in the license, or that transfer the copyright of all contributions to a central body. But neither seem to be the case with the kernel, or did I miss something?
Failing to learn from history dooms you to repeat it.
"Do you have the executable if you use a washing machine running linux?"
By definition, YES! Let me give you a hint...YOU CAN'T RUN A PROGRAM FROM SOURCE! Besides, you are using it not distributing it (see below)...
"do you have the executable if you access a device of the LAn,"
You are using the program not distributing it (see below)...
"do you have a executable if you run an application on a gpl webserver?"
You are using it not distributing it (see below)...
Using a program is not covered by the GPL and shouldn't be covered by it. Distributing is however. If you distribute binaries then according to the GPL you also have to distribute source. It is that simple. So unless you were the manufacturer of the washing machine, LAN device, and web application then the GPL only applies to you if you modify and DISTRIBUTE.
Hope that clears it up for you..
B.
This is a sig. This is only a sig. Had this been an actual sig you would have been informed where to tune for more sigs.
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
Anyway, that would let open source developers use code contributed by IBM and other big IP holders free of worry about being sued some day. Even if IBM (for example) contributed code using patents it doesn't own (such as SCO), developers would have an extremely good defense. "IBM and its horde of patent lawyers told me I could use it." Continuing with my hypothetical situation, it would also apply to people who use the software, so long as they have agreed to the GPL, and so it would protect Linux users and not just developers.
That's my thinking. But neither I nor anyone else who has posted to this story has any clue what will really be in GPLv3, so... you know, don't be surprised if I turn out to be totally wrong.
What I'm wondering is: How much closer is this going to get us to a common installer? Oh, and one that's easy to use.
That's not important though.
And you wonder why OSS hasn't taken off more.
Instead, try to realize the truth -- there is no fork.
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.
You can submit your code under GPLv2 or any later version... the project maintainer chooses to use GPLv2 and *only* GPLv2. That doesn't change the status of your code, only of the project that it is a part of.
If as seems likely GPLv3 is incompatible with GPLv2 (thereby forcing projects that use it to use it exclusively) the only issue would be submitting GPLv3 code to a GPLv2 only project, which would not be allowed.