Submitted by David Wheeler does a cross-examination of the GPL and BSD and why the GPL and Linux specifically have managed to attract a larger number of corporate contributors. “If your goal is to get an idea or approach widely used to the largest possible extent, a permissive license like the BSD (or MIT) license has much to offer. If your goal is to have a useful program that stays useful long-term, then a protective license like the LGPL or GPL licenses has much to offer. Protective licenses force the cooperation that is good for everyone in the long term, if a long-term useful project is the goal.”
There are many good points in this article, but I’d say the most important one is Linus’ personality and not the license.
I can give a counter-example: GNU Classpath and Apache Harmony. The first one has existed for a long time and has produced great code – it is mostly compatible with Java 1.4 with most features of 1.5 also in place. But it has taken them a really long time to get there and there is very little support from companies (with the exception of RedHat, which is mainly interested in GCJ). Also the VMs that can be used with Classpath are far from the performance of the commercial VMs.
OTOH there is Apache Harmony, which has been around for only about 1.5 years. During this time they managed to attract a few heavyweights – most notably IBM and Intel – to contribute code to Harmony. They already have a large part of their class library complete (including a Swing implementation donated by Intel) and a very promising virtual machine (called DRLVM – also donated by Intel). They also have access to a production quality VM from IBM (which AFAIK is not redistributable, but can be used for development).
All in all after less than 2 years they have almost caught up with Classpath, and don’t seem to be slowing down.
What seems to be the key here is Apache’s ability to attract companies to cooperate. The very permissive license doesn’t seem to be any issue for them.
I would argue that in the case of Apache-related projecs, their success has more to do with their track-record and reputation than the choice of license.
The fact that the Apache foundation has been around a long time also helps its credibility.
Nonetheless, Wheeler’s more panoramic view of corporate contributions to operating systems is, in my opinion, historically accurate.
Intel has been secretly developing Harmony for over 5 years; it only looks like fast progress because they opened it all at once.
You’ve got your history messed up.
DLRVM is the new name for ORP, a GNU Classpath VM from intel. See http://orp.sf.net for its history. See the GNU Classpath change logs for the stream of contributions from Intel and IBM to it over the past years.
Been there, done that.
He makes a lot of good points, and especially puts the BSD vs GPL differences succinctly. Especially interesting stats on corporate contributorship vs private in the Linux kernel. And he’s spot on on the ability to dual-boot; some BSDs are still in the stone-age on this it seems (e.g. can’t boot from non-primary partition) However, some caveats:
systems based on the Linux kernel (“Linux”) absolutely stomp the *BSDs […] in market share.
What are the numbers anyway? I thought Netcraft still shows the overwelming majority of long-running servers still being on some form of BSD.
And the Linux kernel came AFTER the *BSDs – the BSDs had a head start, and a lot of really smart people. Yet the Linux kernel, and operating systems based on it, jumped quickly past all of them.
o rly?
To be honest, the most recent benchmarks I’ve seen are practically ancient (someone really needs to do a comparison like http://bulk.fefe.de/scalability/ again; most google results link to that one anyway), but last I heard, FreeBSD held it’s own pretty well. A lot of really major servers are BSD because apparently it seems to be able to better handle the load (something about being a lot better at handling throughput). But again: no recent benchmarks that I can find.
Anyway, it seems an interesting question how FreeBSD/NetBSD would have fared if LGPL was available at the time, and gotten adopted for the BSDs.
Edited 2006-09-20 22:31
What are the numbers anyway? I thought Netcraft still shows the overwelming majority of long-running servers still being on some form of BSD.
There isn’t only servers out there…
A lot of really major servers are BSD because apparently it seems to be able to better handle the load (something about being a lot better at handling throughput). But again: no recent benchmarks that I can find.
It was very true at the time of Linux 2.4. *BSD really used to be much better at the job than Linux. But the improvments of 2.6 and the fact that both OS are open source leads me to belive that the performance of the two systems in this domain are converging. May be that’s why you can’t find benchmarks.
“May be that’s why you can’t find benchmarks.”
http://uptime.netcraft.com/up/today/top.avg.html
Please read the FAQ.
http://uptime.netcraft.com/up/accuracy.html#hz1000
It’s long ago known that these charts have no meaning since Linux 2.6 can’t report being up more than 49.7 days (and the same FreeBSD 6.x)
It’s long ago known that these charts have no meaning since Linux 2.6 can’t report being up more than 49.7 days (and the same FreeBSD 6.x)
That’s not true at all.
The truth is thus : the method used by Netcraft to report uptime is unreliable on Linux systems, because they can have many different clocks beyond 100 Hz, so the heuristic used by Netcraft is unreliable on Linux systems.
Linux CAN report being up for more than 49.7 days though. But the counter they use in IPv4 is only 32 bits (but not the counter on Linux, only the one in the IP packet), and wraps around after 49.7 days with a 1000 Hz internal clock.
It would have been more honest to disclose why Linux isn’t among those systems being monitored reliably for uptime anymore, because its internal clock rate has changed.
Netcraft itself would have told you that but don’t let facts get in the way of a good story.
http://uptime.netcraft.com/up/accuracy.html
Seems to report some of the values wrong, as if you lookj at the 1st, 2nd and 3rd entries:
They are listed as BSDs for the OS, and IIS 5 or 6 for the webserver software, so for me anyway, that list is useless
Haemm you did not found it strange not to see any Linux in the link you provide?
I did and so I read the FAQ:
“Why do you not report uptimes for Linux 2.6 or FreeBSD 6 ?
[…]
he Linux kernel switched to a higher internal timer rate at kernel version 2.5.26. Linux 2.4 used a rate of 100Hz. Linux 2.6 uses a timer at 1000Hz (although some architectures were using 1000Hz before this). (An explanation of the HZ setting in Linux.)
FreeBSD versions 4 and 5 used a 100Hz timer, but FreeBSD 6 has moved to a customisable timer with a default setting of 1000Hz.
So unfortunately this means that we cannot give reliable uptime figures for recent Linux and FreeBSD servers.”
Besides if you look at the “most requested” page you clearly have a domination of Linux systems. Not really a conviencing argument against the assertion:
“A lot of really major servers are BSD because apparently it seems to be able to better handle the load…”
He’s right when he says that companies don’t reciprocate when they are not forced to do so.
However, at least in the case of OpenBSD, market share isn’t even among the project goals:
http://www.openbsd.org/goals.html
Regardings OpenBSD’s goals, the project is very successful. The only problem is FUNDING, because companies don’t give anything (i.e., money) back. However, besides the reciprocation problem, the OpenBSD license (which is modelled after the ISC license) also has a lot of advantages.
David Wheeler’s equation goes like this: successful = market share
For OpenBSD, it should be: successful = free, open, secure
what he missed: quantity != quality
You’re right in that market share does not always equate to a quality product, and many inferior products have won out in the past (Win3 over MacOS, VHS over Beta).
However, software products with market share eventually become at least equal in quality to products without marketshare.
Marketshare attracts interest in the product, and therefore more development (i.e. apps, drivers, support). Also, having a large installed base is better from a bug-finding point of view.
BSD might turn out to be a special case though, as the platform is so similar to Linux that most advances to Linux can be ported to BSD pretty easily.
No, stuff in Linux cannot be ported to BSD – if it could, it wouldn’t be BSD anymore, it would be Linux.
The licences don’t go both ways, while anything internesting done by a BSD can and often enough does get put into Linux the reverse is not true. Putting Linux code into a BSD kernel would comprimise the kernel and put it under the GPL.
Anything done in the Linux kernel can be reverse engineered and be used as partial, if confusing, documentation for the reengineering effort.
Sorry I wasn’t clear there. I meant more for things like applications, rather than actual kernel improvements etc.
Edited 2006-09-21 01:10
Putting Linux code into a BSD kernel would comprimise the kernel and put it under the GPL.
The article seems to suggest that this might not be such a bad idea (putting it under the GPL). I wonder what would happen if some BSD project decided to distribute their product under GPLv3 some time in the future. Would this attract pro-GPL developers from Linux which only uses GPLv2?
Likely it would alienate many BSD users and developers from the project because at that point it is not longer BSD in spirit, it may as well change do being something like MirOS, where they are fine with GPL and other licences and so dropped the BSD of the name. What that would mean to GPL supporters I do not know, but at that point one may as well just fork the Linux kernel to a GPL 3 base.
No, stuff in Linux cannot be ported to BSD – if it could, it wouldn’t be BSD anymore, it would be Linux
BS, several stuff have been ported to the BSD already. Ported, not copied. Like some CPU schedulers algorithms.
The licences don’t go both ways, while anything internesting done by a BSD can and often enough does get put into Linux the reverse is not true
You’re just clueless.
Putting Linux code into a BSD kernel would comprimise the kernel and put it under the GPL
Are you a stupid MS troll ? Even if you put GPL code directly in the BSD kernel, it would NOT make the BSD kernel GPL.
It would just mean your code there is illegal, and has to be removed, as the GPL license would be incompatible with the rest of the code.
Stop spreading such stupid FUD please.
The BSD kernel would become GPL only if all the copyright owners agreed to change the license of the BSD kernel just to accept one submission of GPL code.
Yes, it would be stupid, just like what you say is stupid.
Anything done in the Linux kernel can be reverse engineered and be used as partial, if confusing, documentation for the reengineering effort
BS again, there is nothing to reverse engineer, as the code is there. Someone just has to make a documentation for the feature if one is not available, and then, the BSD kernel devs implement the feature based on this documentation.
No, you are the one who is, as you put it, clueless.
Ported is taking something from one place and putting it somewhere else, a la, “changing ports,” in the nautical sense. Ported would be taking the code and making it fit into the other codebase, that doesn’t happen from GPL into BSD but only BSD into GPL, this is because GPL overrides other licences. An algorithm is not covered by licences, it implementation to use it is, the code must be rewritten or relincesed to make use of it in a non-GPL codebase.
If one put GPL code into BSD code, the result is GPL code, perhaps you’re unable to read the licences, that’s how they work, the GPL takes over. The GPL is not incompatible with the BSD, you can put BSD code into as much GPL stuff as you want and it’s fine, in fact it’s encouraged by the BSD licence, the same thing happens if you put GPL code into the BSD code, it’s just you’re not applying the larger GPL on all the formerly BSD code.
Noone has to make an agreement to add GPL code to a BSD lincesed codebase, it works, but the codebase is from then on nolonger BSD, it’s GPL. The BSD lincence makes it so you can do whatever you want, without asking permission, so you can make something that was BSD into something GPL just by having a copy of the code and redistributing it under the GPL, you don’t even need to make a change to the code – infact, several tools used on GNU/Linux system out there are based on BSD code, noone asked for authorization, they just did, as the lincence permits.
You’re thinking of the GPL, where everyone must agree if the lincece is to be changed.
There is everything to reverse engineer, if the code goes from the GPL to the BSD, the code becomes GPL, it’s simple. Reverse engineering is the only way the code can be used, as a reference. You cannot use that code directly, a la, porting, or you would be changing the licence of the BSD code into GPL.
Have I explained enough for you?
Edited 2006-09-21 14:30
short but sweet!
This isn’t a knock on the GPL, but the reason that Linux amassed a larger marketshare than the BSDs has more to do with the AT&T lawsuit. There was some question as to the legality of BSD, and this allowed Linux to gain traction with developers interested in a free OS. By the time the lawsuit went away, Linux was already catching on.
This isn’t a knock on the GPL, but the reason that Linux amassed a larger marketshare than the BSDs has more to do with the AT&T lawsuit
No, it hasn’t more to do with that. It is addressed in the article, but you’d have to read it for knowing that.
There was some question as to the legality of BSD, and this allowed Linux to gain traction with developers interested in a free OS. By the time the lawsuit went away, Linux was already catching on
The problem about the legality of BSD appeared specifically because of the BSD license, allowing a company with money to take the code, and then to claim it their own.
This couldn’t happen with the GPL.
No, it hasn’t more to do with that. It is addressed in the article, but you’d have to read it for knowing that.
I did, and he expresses a pretty weak opinion, with nothing to back it up:
Some people worried about the legal threats that the BSDs were under early on, though I don’t think it had that strong an effect.
Being a FreeBSD user at the time, it was a Really Big Deal. It meant that the entire code base had to be pruned of all AT&T code, and rewritten to 4.4 BSD Lite, and worst of all, it meant there was no binary compatibility path (It turns out there was, but it was up in the air for awhile).
The problem about the legality of BSD appeared specifically because of the BSD license, allowing a company with money to take the code, and then to claim it their own.
This couldn’t happen with the GPL.
Bzzt! Sorry, wrong answer. It happened because a company (AT&T) got greedy, and felt they should be making money from an operating system that was based on their original work. Had Unix been on a BSD license from the start, the lawsuit would have been groundless.
The problem was that the BSD version of Unix contained AT&T proprietary code. Not “might contain”, but “did contain”. Unravelling who owned what, however, turned out to be such a nightmare that both sides eventually gave up. The BSD answer was 4.4 BSD Lite, which contained zip, zero, nada AT&T code.
At the moment, Linux is undergoing a “similar” challenge from SCO, in that SCO claims that … uhh… “something” … that they own is in Linux. And no, they’re not going to tell you what. The GPL hasn’t prevented it, and while the trial itself has turned into a farce, when it was first announced, the industry took it very seriously.
Fortunately for linux, that didn’t last long.
No, he was right, there was a lot of questions about the legality of the BSD codebase in the early 90s. Read this little page from FreeBSDs own website:
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/bsdl-gpl/unix-l…
That gives a little bit of the history of the code
Why would I want to use the GPL?
Browser: Mozilla/4.0 (PSP (PlayStation Portable); 2.00)
> Why would I want to use the GPL?
Actually, if you were a company willing to open up your code, it would pretty logical to use the GPL instead of a BSD-style license.
Using a BSD-style license, another company could grab your code and close it up, while using GPL, the changes would have to be public (and in public, you as a company, get to see it too).
“Using a BSD-style license, another company could grab your code and close it up”
I just love how people keep spreading this nonsense.
BSD-licensed code cant be “closed” since, unsurprisingly, there’s to way to remove everyone else’s copy. Person A can’t close code that person B has released under a BSD-license since person B, and presumably many others, already have a copy of the code and no, person A releasing their copy of it under a different license does not affect person B’s code.
The main difference is simply that the GPL forces person A to make available *their own changes and derived work* publicly while the BSD license allows person A to keep their changes secret.
It has nothing *WHATSOEVER* to do with “closing” any already existing code.
This is not rocket science to understand.
The main difference is simply that the GPL forces person A to make available *their own changes and derived work* publicly while the BSD license allows person A to keep their changes secret.
That’s not completely accurate. The GPL forces you to make the changes available only if you distribute your version, and even then only to those you distribute the changed version to. You can keep your changes completely private if you like, as long as you don’t distribute the resultant code.
What the BSD license allows is for a competitor to take your code, enhance it with their own changes then compete with your version without you having access to those changes. That’s why the talk of the original code not being taken away is a bit of a red herring.
“That’s not completely accurate”
I know, I simplified it for the sake of argument.
“That’s why the talk of the original code not being taken away is a bit of a red herring.”
Eh, no. The original code isn’t taken away or closed. Period.
Now, sure, some company can take the code, “enhance” (which usually mean screw up) it and keep their “enhancements” secret but that’s an entirely different matter.
For companies who care about this, there’s the GPL. For those that don’t, there’s the BSD license.
Ah, the joy of choice.
“That’s why the talk of the original code not being taken away is a bit of a red herring.”
Eh, no. The original code isn’t taken away or closed. Period.
You’re wrong, period !
You don’t know what can happen to the original code, it can disappear (crash, malign attack, …).
That’s why there are some clauses against this in the GPL license.
If you can’t believe it, just remember financial problems some BSD had lately. Without funds to run the servers, all this original code could disappear pretty fast.
Now, sure, some company can take the code, “enhance” (which usually mean screw up) it and keep their “enhancements” secret but that’s an entirely different matter
No it’s not. These companies can also then take away lead developers, which is what is discussed in the article. Have you even read it ?
You see one small piece of the problem, not all the consequences (parable of the broken window).
For companies who care about this, there’s the GPL. For those that don’t, there’s the BSD license.
Ah, the joy of choice.
It seems they all care about this then.
They wouldn’t even resolve the financial problems of one of the BSD (don’t remember which one).
“You don’t know what can happen to the original code, it can disappear (crash, malign attack, …).
That’s why there are some clauses against this in the GPL license.”
Good thing the GPL magically prevents disk crashes and malicious attacks. No wait….
“No it’s not. These companies can also then take away lead developers, which is what is discussed in the article. Have you even read it ? ”
So, uh, how does “taking away” the lead developer affect already existing code?
If you answered “it doesnt” you win a toaster.
You fail to understand what these licenses actually do. The same could happen with a GPL project since the original copyright owner can change the license anytime they want. No matter the license, this does NOT affect already released and available code.
Btw, how does a company “take away” lead developers anyway? Kidnapping?
It’s also painfully obvious to anyone with half a brain that the BSD style licence does not hamper adoption, just look at the many successfull OSS projects that doesn’t use the GPL some of which have more widespread usage than Linux.
I’m sure there are interesting reasons why Linux has become so big but GPL vs BSD license isn’t one of them.
The article writer simply doesn’t know what he’s talking about. His article is just another tired rant on why Linux “is better” and how awesome and brilliant the GPL is. Linus is a great leader, others aren’t. Blah blah blah. The same tired FUD we’ve read 5 million times before.
depends on how you read it really. They have takent he code and closed it up. The original is still available from a open source but it also exists in a closed product and any improvements are locked up right along with it.
non-GPL licenses sure didn’t work out for Apache, X, X.org, Python, PHP or Perl…..
Edited 2006-09-21 03:03
“non-GPL licenses sure didn’t work out for Apache, X, X.org, Python, PHP or Perl…”
Exactly!
They worked out a treat, without the GPL restrictions
And I wouldn’t have it any other way
non-GPL licenses sure didn’t work out for Apache, X, X.org, Python, PHP or Perl…..
Not reading the article sure doesn’t work out well for you.
Had you read it, you’d have learned that Apache, X, Perl are GPL compatible, while the others got out of their way to have GPL-compatible license.
The article specifically says that it’s very important to have a GPL compatible license, and the huge drawbacks of not being GPL-compatible.
The article don’t tell you to make everything GPL at all.
On an article linked, there’s the big example of XFree86, who tried to go the other way around (GPL-compatible to GPL-incompatible) and how quick its demise was after this change.
Not reading the article sure doesn’t work out well for you.
Had you read it, you’d have learned that Apache, X, Perl are GPL compatible, while the others got out of their way to have GPL-compatible license.
Wow. Must be nice to be a legal expert.
Here’s what the FSF legal experts have to say under their list of GPL Incompatible licenses:
Apache License version 1.0, 1.1, and 2.0
Mozilla Public License (With an exception)
PHP License version 3.0 (Used for only php4 apparently)
The problem with the article, is it attempts to simplify 20+ years of computing history into an idealogical issue.
GPL is more popular because it’s been evangalized more, it has visible faces (Stallman, ESR, Linus), and because people keep spreading completely bogus information about it, and the BSD license.
At least the *BSD teams could distribute a hardware accelerated NVidia driver if they want.
“Not reading the article sure doesn’t work out well for you.
Had you read it, you’d have learned that Apache, X, Perl are GPL compatible, while the others got out of their way to have GPL-compatible license.”
And amazingly so is the BSD license. In case you didnt know, X.org *USE* a BSD style license.
Btw, the Apache license isn’t GPL compatible.
“The article specifically says that it’s very important to have a GPL compatible license, and the huge drawbacks of not being GPL-compatible.”
I guess he just totally missed that the BSD license *IS* GPL compatible, eh?
I want to develop and distribute an application with following goals:
1. Base application is Open sourced
2. I retain the copyright
3. Free for people to download and use
4. If you changed the code, must publish the changes
5. Extensible by way of Open source third-party plugins/drivers
6. Extensible by way of Closed source Commercial third-party plugins/drivers
Philosophy of the goals are its free for people to download and use but no intention to kill the software industry. I want people (that include me too) to make money by extending the functionality of the software to satisfy the professional users by way of commercial plugins/drivers.
What should be my distribution license?
You could use GPL.
It’s perfectly legal to write close-sources plugins for GPL’ed applications as long as the plugin or driver do not contain GPL’ed sourcecode or links to such code.
The license for the application do not apply to the plugins, unless the plugins use code from the application. This does not have to be the case.
You can use GPL with linking exception. See http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInter…
I think the Common Public License (CPL) or the Mozilla Public License (MPL) may be what you’re looking for.
Both are copyleft licenses, but in contrast to the GPL, they don’t apply to the whole application. MPL has a per file copyleft clause, I’m not so sure about CPL.
It may also be interesting to have a look at other MPL-derived licenses (e.g. Sun’s CDDL).
You can find all licenses I mentioned on the OSI website (http://opensource.org).
The original application can be GPLed / LGPLed, so changes must be published.
For libraries used by plugins, it depends. If you also want changes to these libraries to be published, they should be LGPLed (since closed-source plugins should be possible). Otherwise, the BSDL or MITL are also possible.
If you want to go the easy way, put it all under LGPL.