Electronics & Computers Deals here!Why you hate the GPL and why I love it
I'm helping to edit what is turning out to be a shockingly good book on the legal issues around open source, from the developer's perspective, which Van Lindberg is finishing up and which O'Reilly will be publishing. When it comes out, you will want to buy it. It's incredibly well-written and expresses things much more clearly than I've yet seen in my 10 years within the open-source community.
As a case in point, Van explicates the Great Divide between those who love and loathe the GPL by citing a post on the Python mailing list about a controversial bit of code called setuptools:
[T]his information is VERY helpful. It makes it blindingly obvious to me now that the difference between loving and hating setuptools is whether you're *intentionally* using it, or whether it shows up in your ecosystem uninvited....
Meanwhile, from the "outsiders" point of view, setuptools looks like the Matrix or the Borg, happily assimilating the masses, who then start coming to you and say, "But you'll be so much happier once you join us..." ...and off in the distance, you hear a quiet rumbling of zombies chanting "eeeeggs.... eeeeggggs.... mussst havve eggggssss!"
The controversy over the GPL is similar. As one person put it, there is "an unreasonable fear of infection" associated with GPL-licensed code because the legal ambiguity of the licenses makes people unsure about whether the GPL will show up in their ecosystem uninvited.
For those of we who believe that the GPL makes an excellent capitalist tool, we love the GPL. We love it precisely because it forces a black-and-white decision: If you're going to use my code, either contribute back code or cash (to avoid contributing code)." Very clean. Very powerful. No free-riding on the promise of open source.
The difficulty arises with those who want the software without the obligation. Some are proprietary software developers. For some odd reason, they think it's unreasonable to expect them to give something back even though they would never make their software available for free (as in freedom or as in near beer).
In other words, the GPL makes the same demands of a would-be software distributor that proprietary software does: Buy a license or contribute back one's code. The difference is that in the proprietary world, even buying a license leaves you shorn of real rights to the code and the "contribution" of code back generally involves expensive lawsuits and court-ordered injunctions.
I'll take the GPL over that alternative, thank you very much.
Matt Asay is general manager of the Americas and vice president of business development at Alfresco, and has nearly a decade of operational experience with commercial open source and regularly speaks and publishes on open-source business strategy. He is a member of the CNET Blog Network and is not an employee of CNET. Disclosure.
MySQL is a perfect example. If Sun borks it, than a fork would be likely. The perhaps unintended effect is that it keeps projects from disaster.
Java is not likely ever to have to worry about forks. Anyone can create add-on libraries and that does not negatively affect the language or the JVM. The JVM is complicated enough that few will actually mess around with it. No one wants to see Java end up with 10 incompatible language definitions and JVM's. That would be the death knell for Java.
Same deal with Flash, not that it is ever likely to be open sourced.
You mean nondisclosure agreement (NDA), It's not the same thing.
"Also, the GPL fails to protect certain projects from forking"
What so bad about forking. If you don't allow forking than you have non-free software and you depend of one's company(Adobe, Sun ..whathever) mercy. If they decide to drop support, what you gonna do?
"Also, the GPL fails to protect certain projects from forking, where it might be necessary to protect an open standard."
Users are more important then any standard. GPL protect users.
Why didn't you argue this statement. I just don't see your point.
The GPL rewards project leaders that treat the community well and do a good job. When this stops being the case, you may get a fork or movement to a similar project that does a better job (though it's easier to stick to source you already know, so devs would prefer a fork). If this happens, then the advantage starts to turn from the prior code owner to the new ones. Yet, the prior leaders still have the same access they always had (but they start to lose the unique advantages of copyright ownership as the fork grows). And for those that don't harvest copyright ownership (like Linus), there is no problem. It's just pure competition. At the end of the day both end users and devs generally want to contribute and use the best led code base.
This is healthy competition whether or not you are in it for money. The point is that the current copyright owner has a significant advantage, and they have to maintain at least a certain level of TLC towards the community to continue with its support. They don't even have to do the best job, just good enough, since forks are not trivial items to undertake or maintain (inertia also helps the incumbent.. like with most things in life).
In short, the GPL is only bad for the very greedy that really thrive on lopsided playing fields in their favor [http://again, even the GPL gives the code owner a lopsided field.. but it involves work to maintain. It involves not abusing the privilege and sharing your good fortune in some way.|http://again, even the GPL gives the code owner a lopsided field.. but it involves work to maintain. It involves not abusing the privilege and sharing your good fortune in some way.] The very greedy don't like to contribute one line of real code to anyone but love to take it. By not contributing code, they can spend that time grafting others' contributed code (eg, BSD) into their locked in systems. This maximizes profits. Of course, for strategic reasons (including to lure developers into a rat race), even very greedy companies will give away (buggy) documentation and code.
If it weren't for the contamination risks (and the embarrassment/costs of gaining few contributors), Microsoft would love to lead GPL projects where they keep the copyrights ..if they were going to do open source in any real way. Of course, they have closed source monopolies to protect for the time being, and they have proxy companies from which they can buy GPL code under good terms (eg, imagine a deal involving a large cash infusion to a company who would serve as a bridge for Microsoft to acquire source code under MS friendly terms). I avoid companies that deal too closely with Microsoft or which are highly suspect. Microsoft being the biggest threat by far to free markets and to user control. I don't care if companies sell closed licenses up to a point, but we all have to remember that companies like Microsoft have a very VERY strong market position, lots of marketing and legal talent, few ethics, lots of money, etc. Special licenses to them may not be worthwhile to the long term well-being of your own business (unless you charge a very very VERY high fee) or to its brand. As a dev, I would be wary of these companies dealing closely with Microsoft, at least until Microsoft gets knocked down a few notches and loses its solid grip. In fact, a fork would be the best way to further help fight the Monopolies if the Monopolist(s) have grown to depend on a particular code base.
Let me take one thing back. Microsoft would prefer a GPL like license of its own creation to the actual GPL.. at least if it was ever going to play with free software (vs. it's shared source nonsense). Besides the brand issue, they would be able to change the license in key ways once past version 1.0. They would love a "MSGPL v.X or later at your choosing" clause as it would give them the loophole needed to gain everything from you and give nothing back (ie, make one of the versions even more lopsided than shared source.. then they'd apply that license liberally since it would be a "later version at their choice").