Slashdot Mirror
GPL and Project Forking
Norm writes "Linuxcare is running an informative article about project forking and how the GPL serves to prevent forking in many cases; a good expose on a timely subject, given recent fears about kernel forks, etc.. " Being at Comdex, I've heard a lot of people wondering about why Linux stays together, questions about what the GPL means and how it works. There seems to be a lot of confusion about what different distributions actually mean.
Forking is not the big issue people think it is. Usually the fork is necessary to, say, test out a new idea (egcs for example), or because the current development has gotten stale (gimp). In both cases there was negligible impact on the users. egcs has superceded gcc, and has done so without incident. There are major differences between the internals of gcc and egcs. Gimp development has been "revived" (some question if it was ever dead!), and everything is happy in linux land.
--
I seem to recall, say about a year ago, the answer to everything regarding the benefits of open source was essentially: just fork it!
You have the source code, you have your bright ideas (so you think), and you want make some software better. So open source, being open source, would promote better software by allowing anyone to fork the code to increase the quality of the software. I think even Netscape was used as an example. If you don't like the browser, build your own from the pieces of Netscape that do work (can you do this with the Netscape license?).
But lately, with folks talking about forking the actual Linux kernel, forking seems to be the bad answer.
I think instead of arguing over forking, the argument should be over freedom of choice. Whether you fork or not, it's GPL. If someone likes your forked code better, isn't that success? If someone doesn't likes your code and stays with the original, isn't that success?
Who gives a hoot to forking? I have the Linux that I have. I have all the source code I need. If I ever learned programming, I could do more about it. Since I don't, I can hire somebody to do make changes for me. If there is a better feature, I'll just add it. But, I figure, if it's really that cool of a feature, someone else will add it to the current Linux kernel or other open source software as well.
The short answer or question is: Who's going to take the software (or OS) away?
Still, I'd like to count how many times forking was discussed as a benefit to open source before it seemed to become a dirty word lately.
~afniv
"Man könnte froh sein, wenn die Luft so rein wäre wie das Bier"
~afniv
"Man könnte froh sein, wenn die Luft so rein wäre wie das Bier"
Richard von Weizs
Why is it that every person i have ever heard proclaiming the usefullness and flexability of Linux has claimed that forking the code is a possability, and a great idea. But whenever it makes Slashdot news people rise like religious zealots to knock it down? "Don't mess with our source!" They say. Well, its my source too, its all of ours, and we can change to fit our needs, and we should. If we change it for the better, it may cease to be a fork, if we change it for the worse, it'll probobly just die off. Code forking is at the heart of the gpl, and almost crucial to its effectiveness.
--Nuintari
slashdot : where an opinion can be wrong.
We still have the situation that GCC v2.95 Or Higher Still Out Of Favor For 2.2.3pre11
(That has changed recently, but Linus was refusing "EGCS compatibility" patches for rather a while there...)
Recently discussed.
If you're not part of the solution, you're part of the precipitate.
See, for example, the "Pragmatic Idealism" essay on the FSF's Web site. NeXT made an Objective-C front end to the GNU C compiler, and wanted to make this front end proprietary. The FSF's lawyer told them this would violate the GPL, and NeXT gave in.
send all spam to theotherwhitemeat@ropine.com
For example, the article states that "Lucid Emacs" was proprietary, and implies that it predates the GPL. Both are false: Lucid Emacs was based on GNU Emacs 18. Lucid Emacs and Xemacs have always been released under the GPL. And the aricle left out one major reason why a merge would be very difficult: The Xemacs people do not require copyright assignments for donated code, and Stallman does require such paperwork.
The history of the gcc/egcs/pgcc is also very misleading.
Finally, Stallman did not write glibc. The original author/maintainer was Roland McGrath; the current author/maintainer is Ulrich Drepper.
The mention of non-free BSD-based commercial Unixes implies that these implementation came after the release of the free BSDs and the AT&T lawsuit; they long pre-date both.
The article was very well written and insiteful but didn't convince me that forking isn't really a threat. It also minimized the impact on productivity that forking has caused.
Today, the different Linux distros can cause a headache for people dealing with product installation issues, usually with scripts. This isn't so bad because most UNIX people are already used to that. But it does scare off software companies. Think about it, for Windows, you just buy InstallShield or Wise and most of the problems of OS differences are taken care of. Not true for Linux today.
It gets worse at the API level. If the Linux kernel forks and the APIs contain minor annoying incompatibilities, it will be just as bad as the UNIX days of old.
I'm a strong advocate of Linux mainly because it is Open Source. I feel the advantage of this is huge, but mainly for developers. Developers need to be able to trust that the APIs they are using a) work as advertised, b) can be fixed quickly when they don't and c) aren't subject to the whims of a particular profit driven organization. Open Source, and in particular GPL'ed code guarantees those things. Nothing else does.
These benefits aren't immediately visible to the consumers (ie. the non-programmers who just use a computer to get something done). But the benefits do trickle down, when the code they use can be made more reliable and can safely incorporate innovations. The time spent reinventing the wheel for minor variations of operating systems could be spent doing useful innovations.
Realistically, freeware will never replace commercial applications, and I don't want it to. What I want to see is new products with genuinely new features, and I'm willing to pay for them, with or without source. Those new products will come a lot faster if there is a common API to work with. There will always be competing versions of products, but at some point there will be features we come to expect of all of them, and the advantages to the different versions of the products become trivial. At that point, it makes more sense to standardize on a freeware version, and forget all the others. I believe at this point in time, there are not enough technical advantages to the competing operating systems to warrant their existence. It is a detriment to everyone's productivity. Therefore, it's time for an Open Source OS to move to the forefront, and Linux is the closest of any to doing that.
Right now there is one major fork in the Linux world, and that's GNOME vs. KDE. This is particularly nasty, because there really is no way to develop software that supports both. (I mean totally supports both, not just using some common subset of features) This is a long-term threat to the viability of the OS for commercial development. Let's get real, they both are trying to accomplish mostly the same goals: a common look and feel for graphical applications. As long as they both fight for mindshare, that won't happen! I really hope at some point in time, one or the other surrenders, and concentrates their efforts on taking the useful innovations they have and putting them into the other, so we can all get on with things.
If you really want Linux to replace Windows, stop arguing over petty differences and work together to build an OS that truly offers all the advantages that Windows currently offers.
And yes, it makes this stuff hard, because it becomes a combinatoric nightmare. If people would
- stop repeating this nonsense of there being One True Linux
- recognize that the vendors like Redhat, Corel, SuSE, and all the rest of them will always try to differentiate themselves from one another
- admit that for all the intents and purposes of people who are making and installing these applications, it is for them a different OS
If those steps could happen, then perhaps progress can be made. I don't think that they will be, however, because too many people have too much ego wrapped up in the myth. Which is a crying shame, because defining a problem out of Platonic existence rather than admitting its reality and repercussions helps nothing but the propaganda machine. It interferes with real people trying to get real work done. And it's so obviously a half-truth as to make plenty of folks look a lot more closely at other assertions held as Gospel.