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)."
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.
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.
Some of the contributors are dead, too, in the non-figurative sense.
Try to get them to relicense the part they hold the copyright on.
Linux is the biggest GPLed project, with many thousands of separate copyright holders. The mere code audit would take years, not to mention trying to actually contact them. They are often unreachable, their mail address may be no longer valid, they may use the name Anonymous Chinese Dissident #75483, they may be in a persistent vegetative state, etc etc.
And the Berne convention forbids you to ignore even a single copyright holder.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Story of a Software Project Aplha:
.fork1 get incorporated into .forkb.. because ALL GPL VERSIONS ARE AUTOMATICLY COMPATABLE WITH NEWER VERSIONS.
.fork1 collectively go 'DOH!' and decide to stop being buttsticks and use GPLv3 like everybody else is. The forks combine.
Step 1:
Project Alpha released under GPL2
Step 2:
Developers work on 'Alpha' for many years. Peace and contentment rules the land.
Step 3:
GPLv3 is released, includes software patent language.
Developers revolt! Some want GPLv2 Some want GPLv3..
Step 4:
Alpha.fork1 is GPLv2, and Alpha.forkb is GPLv3.
developers work on their respective forks, mutual resentment burning.
Step 5:
All the improvements from
Step 6:
Developers in
Step 7:
Developers work on 'Alpha' for many years. Peace and contentment rules the land.
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.
Exactly. It is highly unlikely that the Linux kernel will ever fully be licensed under the GPL v3. At least, not until all the old code under v2 is replaced by newer code.
;)
The majority of the article, however, is talking about the forking of individual software projects. Some developers might prefer the new license and submit code that is only GPL v3. Some might prefer the old license and continue to use GPL v2. This is where the forking could occur.
The funny thing is that the reason to switch exclusively to the newer license would be to limit freedom. You can continue to license your code under "version 2 or later" of the GPL and that way people can choose whether or not they like the new changes. By using "version 3 or later" instead, you would be forcing people to accept the licensing changes.
I don't want to start a flame war, but this kinda makes the BSD-style license a bit more attractive, eh?
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
Every compyright holder must agree to a change in licence, no matter how compatable the licences.
Do you want the job of goiong back through a the history of a major open source project and identifying everyone who made a non trivial contribution to the code, then finding them (all you have is an email address from 10 years ago), confirming it is the right person, getting in touch, getting them to sign a bit of paper, chasing them when they have better things to do, dealing with the heirs of the ones who have died... and doing that under many different legal systems.
Yes, there will come a point where the remainig small contributions can be deleted and reimplemented, but they you have to do all the testing required to reassure everyone that the new function is at least as stable and secure as the previous one.
No fun at all.
_O_
.|< The named which can be named is not the true named
Does anyone know why Linus made this, at first glance, boneheaded decision?
What rights did he think the FSF were likely to give away in later versions of the GPL that he had to hold on to? It's hardly likely that RMS would have a deathbed convertion and make v20 of the GPL a BSD style licence.
_O_
.|< The named which can be named is not the true named
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.
This is the main danger with instituting a newer version. The more it does over the current version the less obviously it will be in the "spirit" of the current version.
Probably because he didn't want to give a carte blanch *in case* a later version would be weak or bad in some way. (At least that was the reason I had once to not include the "or later version" option.)
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.
He didn't want any risk at all. He thought v2 was good enough and wanted to make it completely impossible that linux could ever become propriety. That's also why he doesn't have contributors assign copyright - makes changing the license much harder.
I am trolling
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." ---
Yes, but isn't GPL the most free copyleft license one can possibly write? In other words, if you remove a single restriction from it, would it still be copyleft?
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.
And who says that v3 has to be backward compatible?
Backward compatibility is very useful for API's, but not desireable for a FOSS license that has a loophole that needs to be closed (ie: the application server loophole)
"Linus et al won't get every contributor to the table to agree to a license change."
He does not have to. The GPL technically does not really require forks to license under the GPL, just to provide compatible terms. That means Linus can download the code from kernel.org under the GPL and then relicense under the compatible GPL v.3 plus mods.