From GPL to BSD to LGPL: On the Issue of Business Friendliness
[ Marc Fleury ] [Permalink]
Open Source starts with licenses. The topic of the "business friendliness" of licenses is a recurring one. We will argue here that LGPL is the most business friendly license around. We will also argue that "business friendliness" is something that goes way beyond the licenses.
The GPL license comes from the Free Software Foundation (FSF). FSF licenses have a strong notion of property. Communal property is strictly enforced by quid pro quo that is built into the licenses. It basically says that if we give you something, you must give back. It is that simple, FSF licenses create a positive feedback loop.
The main difference between GPL, LGPL and BSD is that the BSD does not have this notion of quid-pro-quo. Yet many BSD fanatics rant about "business friendliness." "Steal this code" is what the BSD license basically reads. It is a license to steal. And who does that benefit? "License to steal" licenses are friendly to the very small subset of vendors, those who are in the business of creating proprietary software derivatives and selling them (Apple OS/X based on BSD, IBM WebServices based on Apache Axis). BSD IS GOOD FOR A MINORITY OF VENDORS BUT LEAVES EVERYONE ELSE IN THE COLD. LGPL is the opposite. It is friendly to the majority of actors, including developers, third party vendors and, most importantly, the end-user. In terms of business friendliness we believe the LGPL is a far better choice.
BSD is not friendly to developers. Let me explain. They get ripped off by or, ultimately to make ends meet, must seek employment with proprietary software companies that compete with their products. Interestingly enough, predominantly FSF style licenses historically have led to companies where the community of the core developers professionalizes itself (Linux, MySQL, JBoss). Second generation open source companies control their destinies. The quid-pro-quo mechanism says that we usually see the QA patches coming back and that there is no benefit for our proprietary competition to fork our codebase to build theirs. The success of Linux over FreeBSD is usually historically attributed to this very feature of the FSF licenses, lack of proprietary forking. Solaris however was loosely based on BSD and overtook BSD quickly. As a developer, the choice of BSD licencing means giving your competition the rope with which to hang you. LGPL, on the other hand, protects the developer while allowing third party applications to embed. FSF licenses are developer friendly.
But most importantly, the LGPL is friendlier to third party vendors, the mass of OEM/ISV channel users as well as end-user IT organizations. BSD fanatics fail to recognize the difference between third party vendors and competing vendors. The difference is huge. First of all, the LGPL license, unlike the more stringent GPL cousin, actually allows for embedding in third party applications for redistribution. IT WAS DESIGNED FOR THAT. This third party embedding has been the only factual advantage touted by the BSD crowd over GPL. It is a false and moot point of comparison against the LGPL. Today JBoss, which is licensed under the LGPL, holds the #1 market share as the application server of choice for third party embedding.
But it gets better than this, the one critical advantage the LGPL holds over the BSD is that feature of quid-pro-quo and thus project stability. Projects fork less and positive feedback keeps them growing. BSD fanatics tend to point to the success of Apache as proof of the superiority of the BSD license. When they blather on about the greater business friendliness of the BSD license, they conveniently forget to point out the far greater success of GPL-licensed Linux. In fact, I submit that the Apache project would have been successful if it had been licensed under the "walla walla" open source license. Apache was successful because it was the first decent http server, and it was released at the time that market was being born. Apache was first in the market, got big fast and essentially "nuked" the possibility of a profitable market for the core product. There is no billion dollar http market, the way there is in the app server/data base/operating systems spaces. In those smaller spaces where there is value add in http land, such as SSL, this has been done as a proprietary forks by multiple vendors.
Let's take an example we at JBoss had to live through, the ill-fated Axis project. JBoss Inc. was a third party packager of the technology. When we initially saw the Axis project (IBM's implementation of SOAP distributed under BSD style licenses at Apache) we first thought it looked good on the surface of things. We started building our own solution on top of Axis. We are paying the price of this decision today. IBM pulled support away and forked internally, something encouraged by BSD licenses. With a semi-stalled Axis codebase, JBoss Inc. needed to rewrite a lot of Axis code just to be up-to-snuff with the J2EE testsuite. Since we have no professional interest in giving this code back to our competitors, we will not release our commits under BSD. We have committed this code in the JBoss source tree under LGPL, ironcically participating in yet another mini-fork of a BSD-style codebase.
That kind of instability in a BSD-licensed project, allowed by the license and compounded by the interests of a minority of vendors (including us), is the worse thing for an end-user. IBM has burnt a lot of third party ISVs with their fork of BSD Axis. When I hear the pony-tail fringe of the open source community chanting peace and love, the virtues of BSD licenses being "more open," I think to myself "more open to getting screwed by your own competition."
Bottom line is that LGPL and GPL, by disallowing proprietary forks, are friendly to developers and end-user communities, as well as the vast majority of third party vendors that will commit and invest in those projects. Stabilization of open source communities under FSF licenses is something that is getting clearer by the day. FSF creates stability for end-users, third party vendors and the developers themselves--and that is business friendly.
Finally I will argue that all the previous argumentation about licences and the past 5 years of religious debate on this theme is mostly irrelevant noise. At the end of the day, licensing is but one aspect of business friendliness. The truth is that without a company or companies which employ the core developers of open source, it doesn't work. It comes down to open source projects controlled by a single company or multiple companies, as well as the few individuals who made enough money in the Linux boom to contribute to that project without a professional employer. Linus Torvalds told me that the Linux project has about 1000 read-write committers, 900 of which gave one patch and twenty of whom write 80% of the Linux kernel code--all of them funded full-time.
"There is no such thing as a free lunch." These words by Nobel prize-winning economist Milton Friedman are as applicable to open source today as they are to general economics. The unfounded optimism with which businesses and individuals believe that open source is some sort of magic medium that will grow successful open source projects and communities out of nothing never ceases to amaze me. At the end of the day, it is all about the money. Yes, individuals will devote time to open source because this is what they enjoy doing, because they wish to learn, because they want to build a solution that is not currently available. I started out this way, as did some of the key developers hired by JBoss Inc. However, there comes a time when reality comes knocking at the door, when developers need to earn a living, when they need a personal life, and devoting every spare minute to open source, that is every spare minute left after a demanding full-time job, this just doesn't cut the mustard. People may contribute the occasional patch and bug fix to an open source project, they may start pet projects, however, in order for them to commit long-term, in order for them to structure the development of the project in a professional manner, to offer the level of support demanded by enterprise consumers--open source eventually needs to become their full-time job, hence "professional open source."
In JBoss we achieve business friendliness by "professional open source." By enabling developers to transform open source into their full-time job, to structure their open source communities, indeed professionalizing them, we are able to not only enable them to earn a living but also facilitate their interaction with third party business interests, end users and OEMs alike. Companies all of the sudden have an entity to deal with. THAT is business friendly.
Growing a business out of the community and standing up to take professional responsibility for our software is business friendly. Computer Associates, Unisys, AtosOrigin, Intel, Novell and Hewlett Packard are JBoss Inc. partners. JBoss Inc. presents a business face they can interact with. End users, OEMs, ISVs and SIs want to know that there is a company directly accountable for the codebase on which they will build and deploy business critical applications--not some loose affiliation of goodwill that will fall apart when the going gets tough. They don't want to do business with a website, they want to do business with a real company, they want a "throat to choke." In short, JBoss Inc. looks like a traditional software vendor with the exception that we don't charge for our licenses.
Posted on Mon, 2 Aug 2004 12:27 by ( day(s) old) Trackbacks [0]
