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.
--
Because it doesn't need to, and no one wants to fork it. Is there a worthwhile feature that anyone has developed, debugged, and perfected that the Linux guys have said no to?
1. Replace Tux the Penguin with Jennfer the Hewitt
2. Implement a Dr. Eliza Sex Thearpy thing in the kernel
3. man sex
4. intergrate streaming porn connections in ther kernel
I think reviewing this old slashdot feature ("TurboLinux Releases "Potentially Dangerous" Clustering Software?") in the light of this newer article is particularly interesting - folks were worried that turbolinux might have a clustering solution. A clustering kernel is pretty specialized, and would have pretty much the same qualities that the article recognized as being required for a code fork.
Question: If the code does fork, do they still call it Linux, or is that just going to create confusion?
-Denor
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
Anyone can fork, but establishing a name and a presence takes time.
This article is quite well done. The scope is not that large, so he doesn't get bogged down in all the usual license bickering. He does make a reasonably good case for why the GPL dissuades certain types of forks, and why OS in general dissuades forking over all. I find the comments on the BSDish license promoting (a) fork interesting but underdeveloped.
The idea that a lot of non OS people are having difficulty getting is that for a fork of an OS project to be effective, there must be some sort of 'collective' agreement that is a good idea by (a significant part of) the community using that project. In many cases this is simply not going to happen. But it does allow the fork to occur when sufficient people believe it is neccessary (ie gcc->egcs->gcc).
I think the examples he gives are useful for neophytes and others who wonder what a fork is all about. I'm glad he resisted the urge to go into the muddled history of some of them in great depth --- that can be found elsewhere on the net/usenet if you really need to read about how obnoxious some people behave in the name of protecting there favorite project...
S.
Seeing as little of this article will be news to most delving into this thread, here's a link on the flagship Queen Elizabeth 2 to help you appreciate that analogy while increasing cultural literacy.
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.
There is a lot of misunderstanding in the Windows World about the different Distros.
In my Place of employment people think Software has to be re-writen for each distro, or at the least re-compiled. They get this idea from industry magazines that mindlessly push the M$ FUD.
I try to point out that it's no worse than software differences between NT and 95 etc, but that at least I can re-compile if I need to...
Tokyo Joe
Forking is only a problem when the fork tries to create a new standard or refuses to obey the old standards and interfaces. That's why open standards are so important. So long as people are writing code that obeys a well defined interface/protocol there is no problem with forks, because people can still use pieces of the new and the old as they see fit.
Can your IM do this?
Show your ignorance, dude.
The Macintosh has a multi-forked filesystem.
Windows NT itself has a multi-forked filesystem.
So if you're gonna dis anything that uses 'fork' as a term, better stop using comptuers altogether. Or put CPM/86 back on that machine.
********
********
Windows has detected several mouse-clicks, restart for the changes to take effect.
The argument in the article is 100% right on mark. However, I was just thinking... all this only works if the GPL is actually enforced. A large company could easily come along, take GPL code, add stuff to it, and make a proprietary product out of it (ignoring the GPL). If nobody takes legal action against this, it would just result in the "bad" forking scenario among the Unices. Does FSF enforce the GPL this way (not just for their own software)? Would we have enough funding (and manpower?) to enforce the GPL should the need arise?
(Note: I'm not being critical of FSF or GPL or whatever, this is just my consideration.)
mikre he sophia he tou Mikrosophou.
Look at egcs vs gcc. If the folks behind the scenes hadn't come to an arrangement, then we'd have two GPL'd compilers out there.
Also, look at xemacs vs emacs. Both of them are derived from emacs and that represents an even longer running fork.
People have the screwiest notions of what a license can do for you.
Now that you guys are going public all the ppl at /. should be able to afford this:
2 X/o/qid=942953894/sr=8-1/002-9418028-77682 60
http://www.amazon.com/exec/obidos/ASIN/02053090
Please buy it! Cripe, gimme your addresses and I'll buy it for you ppl!
Sun OS was the BSD product.
Solaris is the result of Sun paying a one time licence to AT&T and then making changes/bringing in BSD compatibility.
(hence all the hate and discontent of some Sun users when Sun OS 4.x was dumped for Solaris)
If it was said on slashdot, it MUST be true!
Any company that supports OSS has a Vested Interest in seeing the GPL protected.
All those "Linux IPOs" we've been hearing about lately have brought a Large Pile of Cash to linux. I can easily see RedHat (fer instance) throughing Vast Sums into the defence of the GPL if they saw it threatened.
--Mark
in the article, the example is given of a hypothetical Linux fork called "fooware os" and the additional hypothetical that the perpetrator of fooware is a crack ninja programmer with an army of software ninjas straight out of a bruce lee film.
one alternative not explored was suppose the fooware ninjas come up with a cool thing and Linus says, "no way, that's not going into the kernel." in this case, the coolness of the cool thing increases pressure on the system to either accept the patches into Linux, or switchover form Linux to Fooware.
what's lovely is how OpenSource routes around intransigence. we're all human, nobody's perfect, and the character traits that make us great software developers also cause us to get in our own way. when that happens, the fooware os fork becomes a Good Thing.
Also, hidden in the fork between gnu/emacs and xemacs was the different programming styles. the procedural versus oo indicates that team based projects will probably stick with OO or easily modularized projects, and gnarlie "keep it all inside one head" projects will be one-great-man projects. the risk of the gnarlies is the death or disinterest of the one-great-man. note how OO and componentized strategies favor open source teaming.
sorry, i'm stating the obvious.
I always here Linux zealots say how horrible BSD forking is, or some such things. And in the article Moen says certain forking is good. So, I'm wondering whether most people here agree, or disagree.
The problem with forking is that it can hurt development by spliting developers up, but there's a lot to be gained by it. Obviously you could point to the free BSD operating systems, because they try to optimize for each catagory (server, platform, security, imbedded). NetBSD's goal is to bring UNIX on a wide range of platforms, but it couldn't work on being the most secure OS. NetBSD works on security, but OpenBSD is king because security is first, porting is secondary.
So if the GPL keeps forking from happening, wouldn't that also keep innovation down? The forking of UNIX brought numerous new ideas, and while confusion, the good ideas were weeded from the bad. I don't see how the dream of Linux being the best for every senario is plausable. Linux can't be the best desktop OS, the best server OS, the most ported OS, the most secure OS, the best imbedded OS, etc without cutting the fat here and there. So... is stpping forking better than allowing forks on set goals? Its all open source, so good code can go back and forth.
I love Linux and I hate it. You know why I love it. Now listen: the Windows UI paradigm provides some Good Stuff. Shift-selection. Standard cut-n-paste hotkeys. Control-tab for MDI window cycling. Etc. There are a bunch of Desktops for Linux, and they're mostly damned good. Unfortuntely, they all use different paradigms. Therefore, Linux lacks the App/Desktop standardization that gives me "moderate proficiency" in any new Windows app that I happen to pick out of the trash bin. The "design fork" in the Linux Desktop Paradigm (if I may use the p-word without sounding like a PBH) makes it seem unlikely that I will see this kind of stuff as Standard Feature stuff in Linux apps anytime soon. None of this keeps me from running Debian on 2 of my 3 machines, but the third one is the one that I do all my work on. Flame away. I hope to learn that I'm wrong.
In German, that would be 'The RMS The!'
If you don't believe me, ask Sidekick Bob.
woops, I meant "Sideshow Bob" of course...
I know, I know... throw me outta Springfield.
I wasn't much good at clubbing snakes anyway.
well if you've ever submitted an article then you'd know that the user types out the headlines. i can't say rather hemos edited this at all, but i think flaming someone for that is senseless.
i was going to moderate you down a point but i decided just to reply.
maybe if you think slashdot is so bland you should start submitting interesting articles?
tyler
I'd suggest a read of Jakob Nielsen's column on writing microcontent. Some useful snippets:
Also, the impact of good headlines can be seen in this article on the cost of poor information on intranets, but is relevant to anything that has a large number of readers -- though the economics aren't as direct.
If Hemos spends 5 extra minutes writing a clear, concise headline, and that saves 10,000 slashdot readers 5 seconds of scanning and thinking each, then that's a gain of 49,700 seconds for the /. community.
pooptruck
Not all forking is bad. Where two groups intend to take a project in mutually incompatible directions, there should be a fork. For example, if one group wants to make the Linux kernel work well in multi-processor scenarios, and another wants to make the Linux kernal into an RTOS, there might be changes that each would need to make that would be incompatible with the other. In a case like this, there should be two different versions of the kernel, because they are justified by the very different goals of the two groups (before I get flamed, this is just a hypothetical scenario -- as far as I know an RTOS multiprocessor kernel is perfectly feasible -- but there must be some situations where incompatible goals spawn incompatible code).
What open source development discourages is bad forking. For instance, if I went into the Linux kernel and made a bunch of trivial changes to suit my tastes, without any real benefit to others, my forked kernel would sit there gathering dust -- no one else would work on it. That would be a bad fork. A good fork is one which is justified for a good reason, and for that reason it is supported by a community of developers willing to work on it.
Just my random thoughts on the matter.
-Steve
Democracy is a poor substitute for liberty.
I see little similiarity at all between Linux and the Bassoon. Even in Italian.
So please cease accusing Linux of being an Italio-Bassoon operating system.
I might just be missing the point, but it seems that if the kernel or any other opensource project forks, it will be up to the users to decide which ones keep being developed. If no one uses the new fork when it becomes stable, the developers of that fork will most likely stop the development on it.
As well, while reading over that article, it seems that alot of things used by Linux users is a fork, so forking might not be the worst thing in the world.
Patryn
The original post (and all those succeeding) are offtopic. It'd be nice to have a "meta" flag that could be turned on for posts to talk about the post itself, rather than the contents. That way, things could be filtered out by that. Also, a forum for the discussion of the mechanics of /. might be nice. So people can be on-topic when flaming Hemos for his English skills. =)
pooptruck
Gosh, you're a quick one, aren't you? Saw the headline, read Hemos's blurb, and pulled not one but TWO examples of forking right off the top of your head! Very, very good! Now what those of us who actually READ the article know is that those are only two of SEVERAL examples which the author, an excellent writer, used to demonstrate his point about code forks. Now that you've proven that you understand his plot devices, why don't you stop by LinuxCare and read the guy's conclusion too? It's very good, I promise.
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
The article put BSD down in many ways.
*BSD split in FreeBSD, NetBSD and OpenBSD because of AT&T lawsuit? Whatever..
Maybe idiots should do some research before they write a "great" article about something they don't even understand.
The author can't seem to pick a single standpoint between
"Open source will never fork", and giving examples
of open source,that forked, and stayed forked.
But given the examples, obviously,the
"Open source will never fork" is categorically wrong.
SGI is writing modules to provide ACLs in Linux file systems (likely, concentrating on their XFS for Linux implementation) as part of their effort to provide Goverment-standard B1 and C2 "Orange Book" security to Linux.
You can see a presentation (recorded in Washington DC at "Linux University") at http://www.sgilinux.org/
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
Think of the ability to fork as a fire hose. You generally don't want to use a fire hose, because the huge volume of water will cause significant damage. But if you have a bad fire in a building, the fire damage is a bigger problem then the water damage would be. So you turn on the water. The analogy isn't perfect, but it works. The GPL allows the code to be forked if things need it badly enough. However, the overhead of having an entirely seperate project often is not worth it. Thus, people generally approach forking with caution.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
Not unless Linus licenses the name to them.. Linus owns the 'Linux' name...
-joev
Forking may seem like come off as bad thing when it happens, but in the long term, as long as everyone adheres to to a set of respectable practices (follows licenses, doesn't resort to FUD or other Microsofty tactics, etc.) it is good for the long term. It is like genetic variation in evolution -- it creates a split whereby the most fit fork will eventually survive. Sucky in the short term (especially if you aren't the most fit), but works out in the end.
I'm glad the author covered the topic of forking for purposes of specialization or customization. When the Linux community starts looking toward real application frameworks (of the complexity of MFC or greater) they'll soon understand why everything doesn't have to be GPL'ed, and why the freedom to do anything you want with the code (i.e. a BSD license) can translate into the advance of open source.
You want to talk about a forked OS...
The article says that Solaris is under the SCSL. Is this even true? I can't find any indication of that on Sun's website, and I would think that I'd have heard something about this in various places. Slashdot would have had a story, and bugtraq would have a flurry of Solaris security holes posted once the source is being looked over for holes by a few thousand people wanting to make them public, rather than a few hundred people wanting to keep them secret.
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.
I'm more worried about project spooning myself.
This is a great article! I think in fact it's a must-read for anyone who's
interested in doing some serious Open Source hacking (OTOH must serious Open
Source hackers probably know almost everything in this article already) or
just generally interested in the miracles of Open Source and the advantages of
its development process.
Recently I have talked about Open Source with lots of people, mostly
non-programmers who wanted to know about that new thing called Linux everyone
is talking about.
Their first reaction to my explanations of the meaning of the word free
(speech, not just beer!) in this context was: "Oh, but you'll get a lot of
code forking then..." (well, they didn't state it this way but what they meant
was exactly that), so I carried on to explain to them (1) why this is happening
so seldomly and (2) how, at the same time, the POSSIBILITY of code forking
was a good thing.
Basically what I told them was just a subset of this article. I was really
amazed at finding *EVERY* bit I told them in this article and the article
having the same structure as those monologues I gave to my friends (first some
examples, then the "analysis" with the 2 main conclusions I mentioned above).
Only that the article is much more complete and convincing than everything I
ever came up with.
Thank you Rick!
After reading it I am more-than-ever convinced that we do not have to fear
code forking! It can happen, it will happen, but the new branch will
survive if AND ONLY IF the advantages outweigh the disadvantages.
"We won't use guns, we won't use bombs, we'll use the one thing we've got more of and that's our minds" - Pulp
Somewhere out there is a company collecting the best part of the GNU/Linux work, adding their own code with intent to repackage. This is what the open source movement should be afraid of.
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.
Through the GPL, the author of a program is unilaterally granting permission for the recipient to copy the program -- under certain circumstances. If the recipient doesn't want to abide by the terms of the GPL, that's fine -- but then the recipient, under copyright law, then has no right (except for the usual fair-use conditions) to copy the GPL'ed program.
By contrast, shrink-wrap or click-wrap licenses try to give a software vendor more power than mere copyright law grants. That's why they have these "if you click this button you are agreeing to these ten pages of fine print" messages. They (might) create a contract between the vendor and the consumer: in exchange for the privilege of using the vendor's software, the consumer agrees not to reverse-engineer it, not to benchmark it, not to install it on more than one computer, etc., etc. Under copyright law, the courts would laugh at restrictions like this, but if clicking on the appropriate button does create a contract, then the vendor can enforce the license through contract law.
(As contracts, click-wrap licenses are iffy, because by the time you see the license, you've already coughed up your money and taken the disk home, and the click-wrap license is now trying to renegotiate the terms of a sale that's already taken place. But that's an argument for another thread.)
Disclaimer: IANAL.
send all spam to theotherwhitemeat@ropine.com
There, I've said it. :-)
I don't disagree with you philosophically, but take Red Hat (please!): RPMs, directories in different places, etc. etc. Granted, not "kernel" mods, but "different" -- and significantly different (IMHO) than any other Linux distro. Yet, nobody but nobody has adopted their modifications. I'm not a kernel geek, but I'd be willing to bet that there are kernel differences too. Hey, maybe I'm wrong.
Anyway, I am not saying that what Red Hat is doing is a Bad Thing (tm), but at the same time clearly they (RH) has no intention of letting their mods die, and no one else has any intention of adopting them. What we end up with is a distro of Linux that you must know in order to administer; e.g. you can't be a Debian admin and just walk off the street and admin a Red Hat box. To me, that represents the Bad Thing (tm) in forking.
-- "In order to have power, I must be taken seriously." -Mojo Jojo
Until now, Linux has been developed and maintained almost exclusively by individuals and companies that had a strong interest, either financial or emotional, to prevent forking. This situation is coming to and end, thanks to things like IPO's and other companies getting involved in Linux. Saying Linux won't fork because it hasn't (as many people claim) is premature. The truth is we don't know what will happen over the next 6 to 12 months when economic incentives tempt companies to act very differently than the Linux community has in the past.
If someone released a bunch of songs under a GPL like license would that be protecting their rights? No because they couldn't make money on the cd sales or the live performances of the songs! Please don't try to bullshit us about it protecting freedom. I am all for OSS, but I think the GPL is too extreme. Of course the SCSL is terrible but frankly the BSD license is the best popular license right now. Allowing the GPL fanatics to define OSS is as logical as allowing Puritans or Jehova's Witnesses to define christianity.
I think that if Stallman were here, he would say that songs are different from computer software and so that the same thinking doesn't apply.
Songs are not source code that is translated into machine code. We generally do not have access to the ``source'' for the music, only to the performance, which is captured by recording the sound waves.
The GPL is special in its requirements related to the relationship between the source code and compiled code; in other respects it is a license that permits free distribution of something.
If it is the free distribution that you object to, then it's meaningless to have a debate about the relative merits of various freeware licenses, all of which permit free redistribution of the source.
Anyway, the GPL protects primarily the freedom of _users_, not the freedoms of those who want to profit by making software proprietary. Stallman has argued that this is not really freedom, but the exercise of power. (As in power == control over things that affect others, freedom == control over things that affect yourself).
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.I've found thousands of forks, but has anyone seen my spoon?
Well, if by X desktop you mean the non-open CDE (which may be an open standard that you can buy, but is not open source), yes, there may be an original X desktop.
But X users have not been able to agree on a window manager: Motif, OpenLook, fvwm, tvwm, WindowMaker, dtwm (CDE's) and so on. Most well-behaved X programs will be usable under any window manager, so people pick the one they like best.
Sun has a desktop envrionment of their own and offers CDE; IBM used to have their own but forced everyone to switch to CDE or just use plain Motif; I think HP did something similar; NeXT had a desktop which predated CDE (and which a number of the Linux desktops and window managers mimic).
The point is, there was no one X desktop environment to fork. Had the X server itself forked on Linux, that could become a serious problem. (X is already forked; every vendor's X is proprietary and closed source. XFree86, XFree68, and so on are the only open source X servers I know of... that can actually render on a display.)
The X base code is free, but derivative works do not have to be free. Since the base code does not support any display hardware, we have vendor forks for every UNIX, plus the XFree* forks.
Fortunately, people only mess with the device driver side, and so X programs continue to work across many window managers, and display properly on different remote systems.
Somewhere out there is a company collecting the best part of the GNU/Linux work, adding their own code with intent to repackage. This is what the open source movement should be afraid of.
In today's anti-piracy climate, woe to whoever is caught! The horribly bad publicity alone arising out of discovery wouldn't be worth it.
Let's look at this closely: suppose that someone does take GNU code and incorporates it into a proprietary product. Does a truly cutting edge company need to steal code? You are playing catch-up if you need to steal.
Secondly, what if someone does that? At best, they will buy themselves reduced development time on some isolated project. The real benefits of the code, namely openness, will be lost. People using the main development stream will get the latest features and bugfixes, and the pirates will be locked into playing catch-up. They can't openly advertize that they have stolen code, so if the code really has a great reputation, they can't boast of it. They can't actively participate in the development process.
Thirdly, no serious company is going to risk it. I know that in my company, nobody would even want to hear of such as thing as GPL'ed code being incorporated into our products. If we use free software, we evaluate the licenses carefully. It would be foolhardy to do otherwise.
There is plenty of useful code out there which has licenses that are more permissive than the GPL. Particularly things that provide some generic, low-level functionality such as, say, compression.
Fork puns can be fun! For example, an application that wishes to detach from it's tty can...fork off and die.
Of course, forking causes children.
If those steps could happen, then perhaps progress can be made.
Absolutely. It is important to recognize the inherent tension between vendors trying to differentiate themselves and vendors avoiding scaring off application developers due to the difficulty of targeting (in effect) multiple platforms. This conflict creates a tough problem.
I don't think that they will be, however, because too many people have too much ego wrapped up in the myth.
I don't follow you here. Which academics "repeat their myth about linux=o/s=kernel" and why do they do it? I'm not disagreeing with you - I just have not heard many people making this claim.
John Regehr
There is no doubt to the growing size of human civilization when there will be comfortably 60-70 billion people on the planet. At a time when we have such diverse culture imagine what it would be like then. Anyway, I have no doubt to seeing future kernel forks. No doubt.
Most any of the more serious linux users have reconfigured their kernel to better fit their computer using style, and sooner or later people with similar using habits will form groups. For the future Linux users, they will have much greater variety in system software they can use.
I guess Linux, in a way, could provide a cultural 'norm.' Everyone will use it, just different varieties. I could see it.
Liked the article a lot, found it very clear
and well-written. However...
I don't think the facts are quite straight
regarding FSF Emacs vs XEmacs. Questions
of history aside, the main thing preventing
a merge right now is that the XEmacs folks
don't have legal papers for all their contributions. The FSF requires these for code
it releases; hence, no merge into FSF Emacs, at
least not in such a way that the FSF will serve
the result from their servers.
The statements about the current maintainability
of XEmacs vs FSF Emacs are also suspect. I don't
think FSF Emacs is so complex as to require a
"genius level" maintainer -- and, as far as I know, Stallman is not in fact its primary
maintainer right now, although he is involved.
(The fact that multiple people are involved in
FSF Emacs's maintenance is a testament to its
maintainability... as is its 20 year age!)
Also, with regards to GCC->EGCS->GCC, I don't
believe Stallman ever did anything to delay the
arrival of Pentium optimizations. Rather, the
GCC maintainer (who was not Stallman) did not fold
in patches he received for these optimizations
Out of impatience, the EGCS team forked and made their own version of GCC. Eventually the FSF (i.e., Stallman) decided to make EGCS the official
FSF "GCC". Far from being a resister who tried
to keep the optimizations out of GCC, Stallman
was responsible for a major step in the
EGCS->GCC transition.
Well-written article, just don't want to see
Stallman get blamed for stuff he's not responsible
for.
-Karl
http://www.red-bean.com/kfogel
X itself has thrived because the API has been standard from day 1. Writing software that directly uses Xlib is portable and low-maintenance. I doubt anybody would even dream of introducing a new windowing system for UNIX.
So why do people continually insist on making new window managers? Because the original "standard" window manager (twm) sucked, and it never got updated. So every programmer with an itch for some hot new feature took twm and used it as a basis for a new window manager. This has led to some great ideas, but it hasn't made Joe end-user's life any easier.
As for CDE and the other supposedly common desktop environments, they all came about too late, and they weren't all that advanced when they were introduced.
Why do people insist that they need to be able to choose different window managers, when all they really want is to be able to customize it to look and act like whatever they are really used to using? This sort of immaturity gives fuel to the Open Source detractors. Hopefully, one of the new themed window managers will settle down all the competition.
ska wrote:
I find the comments on the BSDish license promoting (a) fork interesting but underdeveloped.
The article doesn't say the BSD license is more prone to forking than the GPL, but it does comment on the fork from 386BSD to FreeBSD/OpenBSD/NetBSD/BSDi. It says that fork is stable because of the different focuses of the different forks. GPL programs are just as likely or unlikely to have forks which persist due to such differences in focus.
Note BSDi in the above list, however. It points out one reason to fork that BSD permits but the GPL doesn't, license change. If someone wants to fork a project because they want to distribute their modifications with more license restrictions than the original, BSD allows it and GPL doesn't.
[Disclaimer: I am not saying that either BSD or GPL are better because of this difference, only that this is a notable difference]
----
----
Open mind, insert foot.
EGCS compatibility is somewhat different; it represents some examples of cases where Linux was not conforming to the official standards of how C is supposed to work. (Largely regarding treatment of pointer aliasing, I believe...) Linux has arguably been made buggy in doing things that C isn't supposed to support, but which GCC used to.
Conformance to standards isn't a "feature" in the way many kernel facilities are...
Consider that I didn't mention GGI as an example; it is an example of something that was initially rejected, and quite legitimately so, as the proposed implementation was not, three years ago, developed, debugged, and perfected. Interestingly, the recent framebuffer support is now the GGI support; they don't need to integrate big gobs of stuff as they have the crucial interface that they do need, with the benefit that it has made supporting some of the more obscure systems ( e.g. - Atari ST and such) easier.
If you're not part of the solution, you're part of the precipitate.
That capacity to reduce diversity to a single monoculture is the _main_ reason Windows viruses are so nasty. It's the reason most Windows people are using one particular interface that is jack of all trades, master of none. It is not a good thing at all.
The only reason people think it's a good thing is because until recently there has been no evidence to suggest you could survive doing anything else. Hence, the emotional reaction is 'we must all do this or die!'. First of all, Linux is still around without doing that (and indeed growing, and indeed there are still other options neither Windows nor Linux), and secondly, this assumption was formed from observing a monopoly at the top of its form and making every effort to kill off everything resembling 'diversity'.
If even this has not made the 'monoculture', everybody-runs-Windows approach safe and beneficial to all, what good would it be to try and make Linux a monoculture, with all the disadvantages it brings, but with none of the ability to exert corporate power and influence and throw around huge sums of money?
Seriously. That'd be a _phenomenally_ bad tactical move.
Access to the source of songs? What about sheet music? Most good ears can pick up on the notes right away.
The creation of software is just like music. It is a creative process that GPL commies latch on to, and try do define all software by their narrow little focus.
I found it funny when RedHat went public, that little whiner who complained that they were getting rich on his code. Tsk Tsk, you gave up ownership to that code. The GPL took it from you and gave it to the "community" Welcome to the GNU age baby.
It's not possible to develop any closed source commercial software for KDE without reimplementing everything. Therefore all the closed source applications will be Gnome.
Will this make a difference? I think so; many of us especially in commercial environments have to use at least one binary-only tool (even if we wish we could get rid of it)
Get the word right.
>>Sun OS was the BSD product.
:-)
>SunOS is and always has been the name of Sun's Unix operating system. That's why uname says what it does.
>SunOS 4.x was BSD.
>SunOS 5.x is SYSV.
Ok... I mispoke. I'll include the 4.x next time. mea culpa. (I could try a defense based on sales lit calling the BSD version Sun OS and SYS V Solaris, but the uname result shows how dangerous trying to get computer history RIGHT is.)
Now YOUR turn to be wrong.
>Solaris is the name of a particular bundle of software from Sun: it is the environment which includes SunOS,
Sorry. If Sun OS is included in Solaris, why doesn't software that worked with Sun OS 4.x need to have system calles changed to work with Solaris?
You should have specified version numbers.
(Wait till this fun starts happening with Mac OS. The unix/nonunix version. Or how Windows is what? 3.1, NT, WinCE, Embedded NT, etc la)
If it was said on slashdot, it MUST be true!
What point was the author trying to make by saying (remember him?) everytime RMS was mentioned?
It was a big story here on Slashdot, a link from Salon. Paraphrasing, he said "They are getting rich on my code,. How dare they?" It was in relation to not getting the stock offer as part of the "community."
Seeing as how he wrote a driver or something like that, there is little chance of him selling a closed version. What would anyone need one for anyway? The other source is out there?
That's a bunch of bullshit!
You know damn well that the GPL allows the code to be reviewed by everybody,
and if everybody thinks that the author is smoking crack while writing code,
then they can improve upon it or at the very least drop the author some suggestions.
A good number of aspiring developers gain knowledge on programming techniques
by looking at other people's source code, much like a musician develops their style
by listening to musicians that they like.
By the way, are you one of those sneaky Micro$oft FUDsters?
"Fortune, Fame, Mirror Vain, Gone Insane..... But The Memory Remains...
This anarchy can be attributed to human greed and the weak license under which Berkeley Spice was released. Had Spice been released under the GPL, none of this would have happened. We would all speak a common dialect and science and engineering would be so much better off. Never underestimate the greed and stupidity of humans. It is the GPL which protects the scientist and end user. There is not a working engineer that has not been caught by the anarchy of the Spice model jungle. It could have different.
Why do people insist on being able to choose windows managers? Un-bundling is most certainly a good thing. Why should the window-manager be an integral part of the server? They are two completely separate programs, and should be so. That way i can run enlightenment on Xfree86 OR on accelX, or MetroX, or even whatever it is that comes with solaris, not to mention the hp-ux machines in that lab over there. if the window manager was part of the server it would kill a lot of X's goodliness.
Hamsters are at least as feathery as penguins. HamLix
have you ever tried to use RPMS under Debian? the C libraries arent binary compatible in many cases.
Fork! Fork! Fork!
MrCreosote Meow!Thump!Meow!Thump!Meow!Thump! "You're right! There isn't enough room to swing a cat in here!"
But that's the problem. I've downloaded and compiled and tried to use the RPM source from rpm.org with Slackware 4.0, and I also tried the precompiled one with Slackware 7.0.
/bin/sh" /bin/bash) /usr/bin/perl"
.tgz
.. I hate them.
"Failed -- dependancy
Which DOES exist (symlink to
"Failed -- dependancy
It's another DOES EXIST dependancy.
So I tried installing with --nodeps.
Then I decide I want to remove it.
"This package has never been installed"
AGH!!!!!!!!!!!
rpm2tgz
installpkg
removepg
Yay! It's gone! Wooohooo!
RPMs
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Troll??? Of topic maybe.
Think swedish chef from The Muppets
Sheesh!
MrCreosote Meow!Thump!Meow!Thump!Meow!Thump! "You're right! There isn't enough room to swing a cat in here!"
This OS is all about what you want!
/src/usr/kernel (haha!). Lots of sed time must be spent to fix a dir name like that, and we have many more dir names that also violate the LSB, as well as general common sense (much like our IPO plans).
More communist programmers, more indignant code, and less code tyops!
We have forked the code, and are in the process of patching in more rude comments! Yeah!
On top of that, we have an exclusive (but GPLed) program for finding and fixing common tyops in the code. This is already hard at work on our copy of the kernel for ICO.
On top of that, to make sure no-one can steal our One True OS, we are making it completely incompatible! HAhah! Red Hat, your pathetic efforts to make your distro un-de-forkable are NOTHING compared to our pissing on Linux(r) standards! Want the source to the kernel? No problem, go look in
Not to mention our amazing new package format -- but we won't even tell you about it, as you'll never be able to use it (and you thought RPM's false dependency messages were evil).
As a sign of our affection for our users, we have posted this to Slashdot. We wait for you to abandon Linux(r) for ICO!
Btw, we are IPOing in a few months. As we have the assorted quota of buzzwords (slashdot, GPL, Linux(r), fork, Red Hat, kernel), we expect to have a strong opening price (around 100$ a share).
IPO keyword highlighting via Silly_Linux_IPO_Bot v1.3
---
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
GPL forking is not a problem as rewriting is.
Rewriting is the easiest way to earn credits. You see a working implementation, detect some minor issues (which every software has), rewrite it (ie make it that the original source is no longer visible inside your tree), and of course "forget" to mention this was derived from someone else's work.
So you can claim you have done a good thing (eliminating the "minor issues"), but that wouldn't have been possible without the first implementation you had access to...
You shouldn't have left out SGI's desktop... I can't recall the name, but it's pretty cool, and should deserve to be included here.
Exactly. You don't need to re-train people to use apps, just let them learn their way around the new window manager/desktop, and all is good.
-Matthead
Why not just pull Webster's unabridged from Project Gutenberg? :)
Just because you're paranoid doesn't mean they aren't out to get you
I don't even know where to start complaining about errors in this
article.
The most important thing is probably that the GPL doesn't have to do
anything with splitting. Obviously not in the emacs/xeamcs case, which
are GPLed. The three free BSD variants exist because the people
couldn't get together, period. It's also not clear that it is
desireable, sine the teams has more than more subteam working on a VM
subsystem, and one given BSD variant can have only one VM system. The
thing is also about research. The different BSD teams try out
different solutions for tasks, in a varity that wouldn't be possible
in one shared source tree.
The directions of the free BSD systems as described in the article are
inprecise. First of all, FreeBSD isn't x86 anymore. In general, I (as
a FreeBSD developer) would say the primary difference between FreeBSD
and NetBSD is that FreeBSD is a lot more pragmatic about code changes,
while NetBSD aims for the more elegant constructions, with the
possible cost of being a bit behind FreeBSD in some areas (not all).
Then, why do xemacs and emacs don't do together? The object-oriented
code argument named the article is a joke. These guys don't get
together in part because xemacs incorporates a lot more third-party
code where the authors don't want to transfer copyright to the FSF.
Stallmann requires this for emacs. Also, the packages in xemacs tend
to be too new, unstable (you guessed it, I use emacs). xmeacs is also
a lot more agressive when it comes to new features, and in my opinion
did too much of it in xemacs-20, it is a loss less stable than the
other variants.
The worst thing about the article is that its title wants to imply
that the GPL might help preventing splits, whereas the actual article
doesn't name anything to support this. Typical GPL advocate style, if
you ask me: FUD.
2.recognize that the vendors like Redhat, Corel, SuSE, and all the rest of them will always try to differentiate themselves from one another
.deb I just need to make sure it's compiled for the right libs, (I often just compile the deb from source myself.) For the RedHat box I maintain however, I need to find an RPM that's not only the right library version, but also make sure it's actually a redhat package and not an SUSE, Mandrake, or other package as they're not always compatible.
I dont think it's a matter of trying to be different for difference sake, it's a genuine disagreement about how to go about things. Take package formats for instance. Stampede and Debian feel RPM does not do certain things that they require. Moreover "standardization" on RPM is yet another double edged sword. I maintain a number of different boxes and where as with a
I do believe it's distributions which are the real issue here, rather than kernel forking. The article, which does a good job making the point that it does, whatever factual errors aside, seems to consider kernel forking as the main issue and equivalent to the "Unix Wars" which I believe is a mistake. From a ISV point of view the distro differences are closer to the issues of the Unix wars than any kernel variations between distros. While I believe the distro differences, mainly where files are and the format of initialization routines is an obstacle that can be overcome by a smart install program, someone does have to do a lot of work first to write that smart install program.
Maybe his conclusions are correct, but in that case they definitely aren't based on his understanding of history, which is non-existent.
1. Unix.
Basically ok, as a kids version of history.
2. BSD
MachTen, NeXTStep, SunOS belong to the "Unix" camp above. OpenBSD split from NetBSD, and can thus not be characterized as a splinterproject from 386bsd.
3. Emacs
Totally crap. GNU Emacs was always under a "remain free" license. The non-free Emacsen were all written from scratch. Lucid Emacs was not only free, but the code ownership was assigned to the FSF for merging back. However, later Sun contributed code which was still GPL, but *not* assigned to the FSF.
The real story is that RMS wanted to keep total control over Emacs development, and refused to release Emacs 19 when it suited Lucid commercial interests. Today a merge is prevented partly because of the control issue, and partly because of the unassigned Sun code the FSF don't want to use.
4. httpd
I never followed that one.
5. gcc
Crap. *intel* made a pentium optimized port of gcc, and released it as GPL. They did *not* assign the code to the FSF. The version released by Intel did *not* work on any other platforms. So there were never any possibility of a remerge. Intel has later payed Cygnus for developing a new Pentium II optimized backend, which *will* be in gcc 3.0.
Egcs was created because gcc 2.8 never seemed to materialize, and in particular the C++ frontend of gcc 2.7.2 was embarrassingly old and buggy compared compared to what the Cygnus engineers had developed. Also, the Cygnus engineers found it very hard to attract outside developers with the closed developing model of gcc. Egcs was created as an experiment, with RMS blessing, to demonstrate the efficiency of a more open development model. It was a success.
6. glibc
Ok, except that the split then probably wasn't a mistake. Linux needed a working libc *then*, they couldn't wait until glibc was finished.
The three BSDs have different goals, so a merge is not a solution, but the three projects actively follow the others changes, and merge wat interrest them in their own tree.
Subscribe to source-changes for any of these projects, you'll see countless commit message with (from NetBSD/FreeBSD/OpenBSD)
The only reason this article was moderated down was because of Hemos's status. He is presumed to be above criticism. the censored comment is not flamebait but a legitimate critique. Demanding clarity of English should be the first requisite to posting an article. Hemos's English skills are barely above the Ebonics level. Is Hope College near Detroit?
Isn't it? What about a script something like?
./configure
make
make install
Would this not do the same thing for Linux as installshield does for Windows? This is just a very simplistic script, software companies could write much more complex ones if they wished. Because *nix scripting is much superior to that on Windows (though you can run a decent, eg bash, shell in Windows if you want) the functionality of Installshield can be done with scripting.
The BSD license has nothing to do with it.
All these versions of Spice are commercial. They are different because their producers wanted them to be different, to set them apart from each other. If the code was GPLed, it would not change a single yota in the fact that these people *wanted* to be incompatible, so they could lock their customers.
Now, what GPL might have done is stop anyone from producing a commercial version of Spice. We would still be using the free version of Spice (which is still available, y'know), without any single penny of commercial development put into it.
If you like that, why don't you just stay with the free version?
(8-DCS)
Linux gets world domination. Microsoft and IBM decide to release their own Linux. Being competitors, they make their house changes intentionally incompatible.
What do you do:
1) Adopt the crappy code from Microsoft, resulting in two forks.
2) Adopt the crappy code from IBM, resulting in two forks.
3) Implement a third variant which can be set up by the user to be compatible with either the Microsoft or the IBM code, resulting in three forks.
4) Forget about the crappy code, since it is crappy, resulting in three forks.
See? It's a fallacy the non-fork argument.
(8-DCS)
There are some serious problems with the line of thought presented in the article.
First, right there in the beginning it states that commercial vendors of Unix differenciated their products to gain an edge over their competitors. Right. And what would happen if the code was GPLed? They would have differenciated their products to gain an edge over their competitors. GPL does nothing to prevent that.
Second, the ninja programmers... It implies that because the code is made available, it's more difficult to fork. Not so. Here are some cases:
1) Two different groups implement the same feature in different ways. The only way of "unifying" is discarding one of the implementations. Neither group wants that, so they stay the way they are. (See IPv6 implementations story, though they did finally agree to unify after a few years -- they were not commercial vendors, though.)
2) The differenciation is made in a way that makes Linus unhappy. The code is not merged. See devfs for Linux.
3) Two teams make changes that are mutually incompatible. For instance, new bus vs new config in FreeBSD. Each one thinks their way is the best way, and there is simply no way to have it both ways.
4) I fork, introduce innovations. Linus put them in Linux. Then he puts more stuff in Linux. I do not put that stuff, and continue my own development. The source eventually becomes too different for my code to be backported to Linux. The fork stays.
A fork happens because PEOPLE WANT IT TO HAPPEN. Not the users, sure enough, the developers. They either want to *be* different so they can lock their customers, or they do not agree with the way something is being done, or they do not want to give up on code that turns out to have also been done by someone else in a different way, or they have personality clashes with other developers. GPL does nothing to solve any of the above.
On a side note, FreeBSD and NetBSD originated from 386BSD, OpenBSD did not. They had different aims from the very start. OpenBSD is a splint from NetBSD. One can sure view it as originated by different goals, but the main reason was personality clash. (And none of them above would have been in any way different if the code was GPLed, obviously.)
(8-DCS)
Sheet music is not to a performance what source code is to binary code.
:)
The relationship between sheet music and a musical performance is more like the relationship between program text and the performance of a program, but even that is a bit of a strech.
The performance of sheet music has as its ingredients the information in the sheet music itself, plus the artist's interpretation which endow the performance with meaningful nuances.
The performance of a program, likewise, is derived from the program's code and whatever input goes into it, which may include static data, real-time inputs, etc.
Not all musical performance comes from notation; just like not all data is the output of a program.
The relationship between source and binary code is more like the relationship between a musical score and some lower-level representation of the musical score, like a piano roll. A piano roll is just like machine language: it has binary words consisting of punched holes. These trigger a ``control unit'' which drives the hammers that strike strings. Admittedly, it's a very horizontal encoding.
It would be reasonable to distribute piano rolls under a GPL-like license requiring that the sheet music be available to the pianist. But a key motivation for this isn't there: namely the need to modify. Neither form allows for easy modification, and few players are interested in rewriting a piece. There is a pragmatic need to be able to modify programs to suit changing requirements which is doesn't apply to expressive works.
Yes configure generated from autoconf is great, but only for someone compiling the program! I'm talking about commercial binary apps here. If some smart company decides to implement InstallMaster for Linux they could make some serious bucks! But they'll probably never be able to fully support all the different distros.