Foss code licensed under GPL and variants thereof is more common than every other license combined: http://license-info.appspot.com/ . The plural of anecdote is not data -- N examples of individuals/companies who choose not to go the GPL route cannot refute the fact that it has spearheaded free software.
His example of Apple's use of LLVM as evidence that "you don't necessarily get good results from forcing people to do things" is purely confirmation bias. If he really went looking, he'd realize that Apple also used WebKit/KHTML despite being 'forced' to release their contributions to that library. It is also telling that they stop contributing back the moment the LGPL allows them to.
What about his point that the GPL causes harm:
"A few people in different companies have recently told me something that leads me to believe that the GPL actually does cause harm.. [they use bsd due to compliance worries]"
Oh noes!!! A few people in different companies told him they use BSD instead of GPL! This is the real smoking gun against the GPL, folks! How will it ever survive now?
Like nearly all corporations (who are the primary sponsors of a vast majority of major project's open source development), Apple's use of GPL/LGPL software is a pragmatic one based on the value of the software, not the license. If the license becomes too onerous (which it now has, with the FSF's push for GPLv3 and desire for broad adoption of virally licensed GPL software), Apple has -- and will continue to -- move away from GPL software.
In other words, the GPL is something that is tolerated insofar as it doesn't conflict with business goals.
In other words, the GPL is something that is tolerated insofar as it doesn't conflict with existing business goals.
Which, for the vast majority of businesses, it really doesn't. The number of companies that distribute software, whether compiled or as source, is really quite tiny when compared to the number of companies that use software. Not to say that the GPL isn't a problem for some companies, and it's hardly surprising that said companies would pull out this metaphorical splinter if that is viable for them, but it seems implausible to me that (e.g.) Nike is horrified at the thought that their website is completely dependent upon GPL'd code.
I don't think there are many sane people who expect corporations to stick their necks out for the GPL as a matter of principle; that said, I don't think many people really care. Hell, even the FSF will usually leave companies alone if they just follow the bloody license attached to the software they're using.
Yes, but this doesn't mean that the GPL is a success -- rather, the software has succeeded on its own merit in spite of the downsides of the GPL. In contrast, there are numerous examples where potential software success has been restricted by the limitations of the GPL.
I don't really disagree...except that fulfilling "potential software success" isn't the point of the GPL. The point of the GPL is to propagate Stallman's "Four Freedoms", and anything/everything else really is tangential to the issue. Whether or not the license has held back companies, or individual developers, or the evolution of software development as a whole isn't really the primary concern of those who use or support the use of the GPL.
From that perspective, what you refer to as "the downsides of the GPL" really aren't downsides, any more than an apple being green instead of red is a "downside". The point of the apple is to be eaten; colour is more or less irrelevant. The point of the GPL is to make certain a specific ethical belief is followed and transmitted; whether that ideology is convenient or not for others is secondary at best. Calling the license a "failure" from a viewpoint completely different than the one it was created by is trivial and meaningless, in the same way that it is both trivial and meaningless for me to call someone's apple tree a failure for not growing the colour of apples that I happen to like.
The point is that the minute the "four freedoms" conflicts with "business priorities", we drop the GPL software like a hot potato. That is to say, the GPL hasn't really succeeded at protecting the "four freedoms", it's merely done so as a side effect of the success of GPL'd software.
GCC sat on the top of the hill for a long time due to the fact that the GPL's restrictions were an acceptable cost. However, when it came time for a library-linkable compiler, look at what Apple did -- they didn't GPL their software to allow linking against GCC -- instead, they decided to sponsor development of a new compiler.
GCC does have a bit of a reputation as a nightmare codebase though- a new project using new techniques and tools (er.. LLVM) doesn't seem so unreasonable.
Well I thought the point about it being a distribution of software licence (not a usage licence) meaning companies like google can use it without sharing changes was interesting (but I am sure that point has been covered in lots of other places).
Bleh. This is like those people who call Yahoo a failure.
The GPL radically changed the IT landscape in the last decade. Whether or not it achieved all of its initial goals (as interpreted by the author of this post) doesn't mean that it hasn't been a massive, disruptive force in the IT world.
Has it really been such a massive disruptive force, or merely an entirely secondary factor in the open source software world?
I honestly don't mean to troll, but Apple, for example, has built an entire business on open source (but primarily not GPL) software components. They used GCC insofar as it met their needs, and then switched to something else when the GPL became an obstacle. Likewise, most companies use Linux because it's a pragmatic choice, not because of the license.
I think it's overreaching to claim that the GPL has changed the landscape. Liberal open source existed before the GPL, and will continue to exist if the GPL where to somehow disappear.
That open source has been disruptive I consider indisputable. The question then becomes, "Were the BSDs poised to lead the way to the current world of commoditized software infrastructure?" But that's a different question.
Whether by dogma or community forces, something about the FSF and the GPL transformed open source from a licensing scheme to a movement that produced the mass of software that we have today. Whether or not the BSDs could have done that is a separate question -- they in fact did not, and the massive disruption that we've seen has been an outgrowth of GPLed projects.
That open source has been disruptive I consider indisputable. The question then becomes, "Were the BSDs poised to lead the way to the current world of commoditized software infrastructure?" But that's a different question.
Speaking only in terms of operating systems, the AT&T lawsuit caused the BSD derivatives to stumble just as they started, and at the same time Linux was beginning to enter its stride. The GPL/FSF didn't (through dogma or community forces) drive this, but rather, circumstances and a general hobbiest interest in open source operating system development.
Whether by dogma or community forces, something about the FSF and the GPL transformed open source from a licensing scheme to a movement that produced the mass of software that we have today. Whether or not the BSDs could have done that is a separate question -- they in fact did not, and the massive disruption that we've seen has been an outgrowth of GPLed projects.
That's vastly overstating the reach of the GPL projects. Everything from Apache HTTPD to PHP to Perl was (and is) liberally licensed.
but had the GPL not existed when it did - would the foundations still have existed that make open source of any licence as mainstream and commercially acceptable (in some cases preferable) as they are today?
There is a very long history of commercially acceptable non-GPL open source software. Here's some widely corporate-used software that played an integral role in both commercial products and early internet/network services:
* BSD-derivative Operating Systems (code available with first releases since in 1977)
* Sendmail (1983)
* Apache HTTPD (1995)
* Qmail (1997)
* MIT Kerberos (late 1980s)
* UMich LDAP (now OpenLDAP) (1995)
Modern examples are considerably more numerous, ranging from Apache Project's Java projects, to LLVM.
The places where the FSF and GPL have really succeeded are where there was usually a strong network effect (compilers and operating systems are large individual undertakings, for instance) and limited downside to the use of the GPL.
[Edit] I realize that some fringe downvoting GPL proponents take offense at the idea that the GPL isn't single-handedly responsible for mass adoption of open source, but come on guys, there's a long and rich history of commercial open source adoption outside of the GPL.
I've seen an effect that is quite the opposite of what the author claimed.
Netatalk (primarily an Apple File Protocol server for Mac clients) didn't get much love from developers because it was BSD-licensed and companies selling storage boxes would use it and fix many of its problems, but without contributing changes back. This was sufficiently demotivating that many good developers said to me, in so many words, that they didn't want to contribute if companies were benefiting from the project but not giving back. The license was changed to the GPL (with the advertising clause retained) and community participation took off like a shot and its been a healthy project ever since.
Netatalk was primarily authored, maintained, and ultimately abandoned by the University of Michigan -- all under a BSD license. During this process, how many improvements were contributed by corporations/individuals who would not have done so had it not been BSD licensed, or who simply didn't care what the license was?
The resurgence in interest coincided with the interest and engagement with new, GPL-proponent developers. It's hardly a non-biased piece of anecdote.
Of course not, because a core of developers who wanted the project to move forward recognized that multibillion dollar companies were benefiting but not contributing, and a change to the GPL motivated their involvement and brought the project back to life.
Did companies contribute under the BSD license? Of course, some did. But not enough to keep the project from entering a coma. And nobody wanted to fork it if no one was going to contribute.
It's not a trivial anecdote when you can say that the GPL brought a project back to life, because that's what it did.
It's not a trivial anecdote when you can say that the GPL brought a project back to life, because that's what it did.
New, active, non-umich developers -- who also happened to favor the GPL for personal/political reasons -- brought the project back to life. Not the GPL.
The project stagnated because AppleTalk ceased to be used, and AFP over TCP was generally replaced in most corporate installations by Windows Fileshares or WebDAV, and UMich didn't need it anymore -- not because corporate interests were stealing contributor's labor.
It's presumptuous to take a product that was entirely and successfully developed for years under the BSD license and then claim it as a GPL success story because the new maintainers had a moral imperative to relicense.
You wouldn't claim it a success story for their coding style if they also decided to switch to 4 character tabs and newlines before braces.
"It's presumptuous to take a product that was entirely and successfully developed for years under the BSD license and then claim it as a GPL success story because the new maintainers had a moral imperative to relicense."
Something to remember is that the key pain point at this stage of Netatalk's development was that its CNID scheme -- the method by which the server gives a unique identifier to each file/directory and refers to it when communicating with the client -- was broken and frequently led to silent data loss when the server would mistakenly reuse IDs.
This problem was well-known and well-understood. And nobody -- certainly not the big companies who'd fixed the problem in their private forks -- would step up to fix it.
In this context, it's very hard to truthfully characterize Netatalk as "successfully developed for years under the BSD license."
A file server in widespread production use with a well-known data integrity problem? That no one will fix? Call it what you like, but that ain't a healthy project.
You can trump this up however you want to, but how do you weigh your anecdote of a small, abandoned project that now has three active contributors, compared with another University Michigan open source project that underwent a similar transformation -- UMich-LDAP.
UMich LDAP was developed under a BSD-like license. The project stagnated with serious issues that were not fixed. Maintainership was then acquired, the project became OpenLDAP, and it remains highly successful to this day under a liberal BSD-like license, and is even incorporated into commercial products like Apple's Open Directory?
Same original maintainer (umich), same open source maintenance abandonment, better outcome (incredibly widespread use and active development), different license (liberal).
Not trolling. The point here is that given two projects in the exact same circumstance (abandoned), with the exact same absentee maintainers (umich), and equivalent levels of contributions and code quality (low), both went with two different licenses -- BSD and GPL.
The BSD project saw significantly higher contributions. However, that doesn't imply to me that the BSD license usage was a "success story" any more than the GPL usage was. It merely implies that the specific individuals interested in maintaing the projects had entirely different licensing predilections, and there were different levels of community interest in the projects.
Happenstance in the case of OpenLDAP I could accept, though again I'm totally unfamiliar with the project. For all I know they were big Waldo fans and were promised signed first editions of the latest book.
It definitely wasn't happenstance with Netatalk though. Why? Because the community (not just devs) felt some of Netatalk's corporate users had taken advantage of them, and avoiding a repeat wasn't considered a wishlist feature, but a must-have. In that light, simply sticking with the BSD license wasn't an option for them. Switching to the GPL broke the logjam.
You can't just decouple the developer's contributions from the community's determination to address the behavior of the storage vendors. A fork and a license change was a foregone conclusion at that point, the only question was whether it would have bothered the BSD-ites enough for them to keep the UMich tree alive. And the answer was a resounding "no."
The fact is that the developers had to write the code themselves anyway. The switch to the GPL didn't cause vendors to contribute CNID fixes, it merely let those specific developers feel better by sophomorically raising the proverbial middle finger to "thieving" commercial interests while they did free work anyway.
Clearly the developers were interested enough to write the code themselves, in which case the fact that they preferred to fork under the GPL license is just as much happenstance as the interested OpenLDAP developers being happy with the existing BSD license.
It's not as if Netatalk changed the license to the GPL and then attracted a large following of GPL-only developers.
"it merely let those specific developers feel better by sophomorically raising the proverbial middle finger to 'thieving' commercial interests"
Oh man. Fine, you don't like the GPL. We get that. But to say the license change should have been irrelevant is to say that developers should be code-crapping robots with nary an expectation of a social contract. Some devs dig BSD. That's great. But some of us actually like Stallman's four freedoms and in certain situations need to see them guaranteed. Deal with it.
It's not a GPL "success story". You preferred the GPL, you were going to write the code anyway, and you did. At no point in this process was the GPL somehow conveying an advantage beyond satiating your desire to lock out external users/contributors who were potential 'thieves'.
The analogy I gave earlier still fits -- you could have just as easily called new code style conventions a "success story", despite the fact that they aren't the primary driver behind getting something done.
The most audacious aspect of the story is that by locking up future work via the GPL, you've done what you accuse external entities of doing: locking out previous BSD-licensed contributors from your future improvements to the project.
Haha! "Thieves." "Locking out." You're just an anti-GPL zealot. If using the GPL makes me audacious, then call me audacious. Now go troll somewhere else.
"New, active, non-umich developers brought the project back to life. Not the GPL." While we're being pedantic, I'll note, completely unnecessarily for our thinking readers, that the GPL was necessary but not sufficient.
"The project stagnated because AppleTalk ceased to be used, and AFP over TCP was generally replaced in most corporate installations by Windows Fileshares or WebDAV."
That's an interesting assertion. No one could plausibly argue that the situation today is any different. And yet the project is alive and kicking.
You can try to explain why in a way which obviates the license, but the reality is that for the players who showed up to the game, the BSD license was a deal breaker. "It's not the GPL!", you say. "It's that the developers preferred it!" Fine. But if your license drives off all your developers, justifiably or not, whether it's morally superior or not, your license has killed the project. Period.
Me? I'd rather choose a license that the developers like. So they, you know: develop.
You can try to explain why in a way which obviates the license, but the reality is that for the players who showed up to the game, the BSD license was a deal breaker. "It's not the GPL!", you say. "It's that the developers preferred it!" Fine. But if your license drives off all your developers, justifiably or not, whether it's morally superior or not, your license has killed the project. Period.
The fact that your missing is that the once-successful project was already dead because the primary authors no longer required it and the technology landscape had changed, not because the BSD licensed was used.
Given that, I agree that the "correct" license was whatever license anyone actually willing to contribute wanted. The fact that the few new developers interested in contributing were GPL proponents is entirely happenstance and not a success story -- the project reached full maturity with years of development under the BSD license!
"The fact that your missing is that the once-successful project was already dead because the primary authors no longer required it and the technology landscape had changed, not because the BSD licensed was used." "The project reached full maturity with years of development under the BSD license!"
Wrong, wrong, wrong. Absolutely wrong. You said that Netatalk in its UMich days was "once successful" and "fully mature," and that its previous users didn't need to maintain it anymore. Neither of those assertions are true.
Fully mature? Reference my earlier post on CNIDs (http://news.ycombinator.com/item?id=799429), but there were grave data-loss and severe locking bugs in Netatalk which persisted from as far back in its BSD heyday as I can recall. In addition, the build scripts were all kinds of broken, and enabling a basic security feature like DHX was sometimes the subject of long web HOWTOs, due to how fraught the software was. Before the project came back to life, I recommended other options to my clients not because Netatalk's function wasn't necessary, but because Netatalk wasn't trustworthy. (Fortunately a few motivated developers wrote the CDB and DBD backends, and the problem disappeared.)
And the idea that its primary users didn't need to maintain it? Hogwash! Not only were many of the major storage vendors continually shipping it in their devices, but they were shipping privately maintained forks of it with fixes for the issues I mentioned. So it _was_ being maintained, but UMich's source tree was out of luck. The BSD license is why they didn't contribute the fixes back, because they didn't have to. And so Netatalk, always kinda broken, stayed kinda broken.
(Yes, Netatalk is pretty much the poster child for BSD projects which have been sorely neglected by their Fortune 500 users. IIRC, Quantum was the sole exception, but don't quote me on that.)
Now, it's reasonable to propose that if Netatalk had had a GPL license from the beginning, storage vendors might not have adopted it. But vendors ship tens of thousands of units every month running the GPL'd version, so it wouldn't hold water. In addition, there's no need to link to Netatalk in order to build an administration interface around it, something their developers and lawyers have surely always known.
Wrong, wrong, wrong. Absolutely wrong. You said that Netatalk in its UMich days was "once successful" and "fully mature," and that its previous users didn't need to maintain it anymore. Neither of those assertions are true. Fully mature? Reference my earlier post on CNIDs
I never ran into the CNID issue when using Netatalk on our Mac OS 8 systems. By the time Mac OS 9/Mac OS X came around, the project's necessity was already diminishing and I (like many others) had long since stopped paying attention.
I seem to recall contributing all of one patch to netatalk, and that wasn't because I was an evil corporate code stealer -- we just didn't need an AFP server anymore.
Fortunately a few motivated developers wrote the CDB and DBD backends, and the problem disappeared.
The BSD license is why they didn't contribute the fixes back, because they didn't have to.
Vendors had absolutely no reason to use a GPL fork unless new contributors then implemented considerable useful code under the GPL. In other words, making it GPL wasn't the magic that got vendors to use the GPL'd software, providing them more value for free did the trick.
But vendors ship tens of thousands of units every month running the GPL'd version, so it wouldn't hold water.
How many of those actually significantly contribute back to the project? I count three active committers.
By the way, I think I've omitted something from the discussion until now that may help you understand why the GPL was perceived as the right license at the right time for Netatalk.
The initial influx of developers after Netatalk's long moribund state was mostly caused by community discussion of the CNID issue. As users' hard drive sizes increased, more files were stored which increased the likelihood of triggering the bug which resulted in data loss. So more and more people hit the mailing list, wondering what was going on, what was going to be done about it, and were very anxious because not only was it a data loss bug, but a silent data loss bug. Even if users kept backups, they wouldn't know to use them unless they happened to notice a file was gone. This made Netatalk feel like a ticking time bomb. As the conversation's pace quickened, it attracted a handful of new developers who had a stake in Netatalk's success.
As users compared notes and the new devs ran tests, they learned, as mentioned before, that some storage vendors had been aware of and resolved the issue in their products, but refused to share the fixes. Users who had lost files became angry. Why? The feeling was that these vendors had benefited from Netatalk for a long time, and now when the community needed help, the vendors were turning their backs on them.
I think anger was an understandable reaction. After all, we're not talking about users missing out on some whiz-bang feature. If a cool new feature on your iPod is steak, then data integrity in a fileserver is water -- you can't live without it. Users were dying of thirst while the storage vendors were chasing them away from their freshwater wells. And so the community reacted, and decided that instead of hoping for the goodwill of others, a different license would be used to guarantee it.
So, yes, a group of BSD-lovin' devs could have written the code, and we might be where we are today. But the community felt it had been taken advantage of under the liberal license, and reacted to prevent a repeat.
In hindsight, the LGPL might've been a better license for libatalk by encouraging corporate use and development, but I'm not sure, and I don't know if that would've mollified the fans of liberal licenses anyway -- not that that latter point actually matters.
"I never ran into the CNID issue when using Netatalk on our Mac OS 8 systems."
That's good! Unfortunately I did, and so did many others. A quick perusal of the old mailing lists will turn up plenty of this. We tried a test rollout in a division of a Fortune 50 company, and our backups saved us -- when a user noticed a file was missing, that is.
"I seem to recall contributing all of one patch to netatalk, and that wasn't because I was an evil corporate code stealer."
Excellent! All patches were appreciated. We could've used more of that. (And we'd have happily accepted patches from the storage vendors, they just wouldn't play ball. I don't think any of us felt the corporations were "evil," just that they were behaving like ... moochers.)
"How many of those actually significantly contribute back to the project? I count three active committers."
First, that's misleading. The three active committers take patches from others as they please. So to get a true picture you'd need to go through the mailing list and see where all the patches originally came from. And I haven't been involved in the project for some years, so you'll need to go research that yourself.
Second, you've completely missed the point. And it's one you should really like.
Netatalk entered a sick state because the people who had the desireable patches chose to hold them back. The BSD license allowed them to do so. Then other developers came in and said, we'll commit our patches, but we want a guarantee that those who ship our work will have to do the same. And that was enough to motivate them to make Netatalk fully mature -- every significant enhancement/fix implemented privately became available publicly, and more, thanks to those devs.
And what was the outcome for ALL of Netatalk's users? The storage vendors were happy because they could stop maintaining their private forks and just ship from upstream. The users were happy because all these bugs were fixed and they had a responsive place to seek help. The devs were happy because they were assured that they were now on equal terms with the storage vendors. Whether the vendors continued development or not wasn't actually the issue.
So everybody won, the users, the developers and the storage vendors.
No, the GPL didn't write the code, but the BSD license allowed the code to remain private, and that's where everybody started losing. The GPL assured everyone that that couldn't ever happen again, which, as it turned out in this case, was a necessary precondition to success.
You can't seriously argue both that the GPL is too onerous and too easy to circumvent.
The GPL rubs many developers and proprietary software houses up the wrong way as it takes away their power over their customers. This is illustrated nicely by this very article with Apple wanting to include compiler stuff in their software without putting it all under the GPL and how Google had no issue with the GPL as it didn't interfere with their business model even though their unique selling point is software based, just server based software. Similar applies to the 99% of businesses that use software, and even create it, but don't need to sell it.
I feel like the GPL's overly political nature is basically a type of political DRM. If you try hard enough you can skirt the restrictions. If you're an end user you have to deal with the fallout which trickles down in a variety of ways but can generally be summarized as "making things harder than they really need to be" The NVIDIA example is a good one. It would be hard to argue that the GPL has benefited users in this case. It's been an annoyance to NVIDIA and a huge headache to end users.
Nvidia's the annoying exception, and I say that as an owner of an 8800GT who has to recompile the module for each Debian kernel upgrade. But when I think of all the other hardware in my machine which runs without a hitch under GPL'd drivers because the manufacturers were forced to contribute the code, I like the tradeoff.
I think your observation is astute -- for a literal example, see the 'GPLONLY' implementation in the Linux kernel. Unless your module explicitly declares itself as GPL licensed, Linux will refuse to vend (new) symbols to your module.
For desktop apps and standalone tools, the GPL is fine. But if you're writing a compiler, interpreter, library or even an operating system, choosing the GPL will be a bloody stupid decision.
Reality seems to contradict your opinion. GCC, Linux and thousands of quality libraries are written under GPL license.
Releasing software as open source dows not mean giving it away for free. With GPL it literally means that you give it for freedom.
As a developer of a commercial program, the GPL (with dual licensing) is the best choice if you want to release your source code and have control over it. Your users get it for free, but your competitors cannot modify it legally to take advantage over you. It's a win-win situation.
Furthermore you have always the freedom to not to use GPL libraries if you think it causes more harm than good.
Foss code licensed under GPL and variants thereof is more common than every other license combined: http://license-info.appspot.com/ . The plural of anecdote is not data -- N examples of individuals/companies who choose not to go the GPL route cannot refute the fact that it has spearheaded free software.
His example of Apple's use of LLVM as evidence that "you don't necessarily get good results from forcing people to do things" is purely confirmation bias. If he really went looking, he'd realize that Apple also used WebKit/KHTML despite being 'forced' to release their contributions to that library. It is also telling that they stop contributing back the moment the LGPL allows them to.
What about his point that the GPL causes harm:
"A few people in different companies have recently told me something that leads me to believe that the GPL actually does cause harm.. [they use bsd due to compliance worries]"
Oh noes!!! A few people in different companies told him they use BSD instead of GPL! This is the real smoking gun against the GPL, folks! How will it ever survive now?