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.
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.
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
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." ---