Archive

Posts Tagged ‘open course licenses’

Critical Analysis of Open Source Licenses

September 4th, 2009 2 comments

I’ve worked on a number of projects in the past decade that I have been considering releasing under an open-source license. However, I have been a bit leery of giving away something for free on which I have worked multiple-years, and which I recognize has strong value to help the consumer improve their business processes and deploy new, strategic services that can earn them substantial revenues. It’s not as easy as it may appear. It’s somewhat of a leap of faith, psychologically similar to trusting your money to a bank to protect it for you, rather than hoarding it under the mattress. Instead of a bank, you’re trusting the legal system, and people’s honesty in knowing the limits of how they can use, create derivations and distribute your software.

Apparently, I am not the only one to have struggled with this. There is a much more eloquent post by Zed Shaw (of the Ruby Mongrel fame) [Warning: Profanity Zone]. He gives 5 very convincing arguments why an open source license is good for (his) business, and great for the larger open-source community.

I have several motivations for releasing my code under an open-source license:

  1. I like to share. When other people use my software, it does not reduce the utility to me at all
  2. If others have access to the source-code, they can then re-purpose it, and perhaps even improve it, which makes it more valuable for me (and everyone else)
  3. I may get some consultancy opportunities when others use this software. As Hal Varian pointed out in Information Rules: A Strategic Guide to the Network Economy, software is an experiential good, and the value is only realized when it is consumed. Thus, I want my software to be widely adopted and consumed. When this occurs, I may receive requests for features, improvements and implementation support, which will only help my business

When I asked Andrew Ross about this a month ago, he suggested that I look into the GPL license, as that appeared to fit my needs. On the basis of his advice, I dug around a bit to learn about this license. I’ve been a huge open-source proponent for years and trained over 300 of my students when I was teaching at NUST to take the jump into the open-source arena. I’ve read the GPL license multiple times, and have used more GPL software than I am capable of measuring, but I must confess that until recently I did not really dig deep into the license. Forgive me, I am a researcher and an engineer, and not a lawyer. Some things are just too gray, boring and unappealing until a reason arises to make them important to you. Like getting sued, or not being able to use or build on software that you’ve created because you did not consider the ramifications of not having a permissive license in place.

Serendipitously, there was recently a very interesting (and entertaining) debate arranged by FOSSLC between Matt Asay, Mike Milinkovich and David Maxwell about the relative merits of the EPL, GPL and BSD license. These are three individuals for whom the open-source license is a very important part of their lives. It’s the whole difference between being involved and committed (or a committer in this case — pun alert). You should listen more closely when a committed individual tells you about something in their field; it’ll be a longer, more nuanced, heart-felt and sophisticated description with probably more than one “it depends” in there. It sure beats the simplistic tales of storytellers.

You can view the entire debate at the FOSSLC site.

The summary, for those who want to walk away from this post with something substantial is:

The BSD license (and variants such as the Apache, Artistic License etc) are universal donors. You can take their code and do essentially anything with it you want, including making two lines of changes and claiming the entire code-base for yourself (as long as you provide attribution to the original). If you release software under this license, you probably are a strong believer in karma, thawab, whuffie or other divine justice system, an incredibly evolved human being, all-around-nice-guy/gal and someone I’d like to have a coffee with. Indeed, silverstripe (the popular CMS) goes into some detail about why they have released their software under the BSD license.

Simply put, it comes down to this: We’re not in the business of developing software; we’re in the business of helping our customers. The way we do this is by figuring out what our customers need and delivering well. What we deliver is usually a combination of business analysis, technology development, and tight working relationships with the customers.

It’s as close as you can get to putting your software into the public domain, and this works fine for some people. The Apache project in particular has a very mature code-base and a living community around the core offerings, and many of the committers are either employed full-time by large firms to work on these projects, or have a vibrant consulting practice around the code they have created. There is nothing stopping other people from deploying the Apache code-base without any permission or requirements, but for the most high-stakes implementations, you would be wise to call in the services of individuals who are intimately familiar with the code-base as they have developed it. As a bonus, the BSD license is extremely easy to understand and explain to others, consisting of only three main clauses that you could write on one-third of a sheet of paper.

The GNU General Public Licenseis by far the most popular of the three licenses. Until I did the research, I assumed that the GPL was something like the BSD. I could not be further from the truth. While the BSD essentially ‘gives away’ the right for others to use your software freely and do anything they want with it, GPL gives consumers the rights to use the software for free, however (other) developers need to tread more carefully, as yes, they are free to make changes to the GPL’ed code, but have to freely release the source-code of all changes and additions they make. This derivative sharing enforcement provision guarantees that any changes made will always be available freely as well. The immediate ramification of this for a business is that their code is ‘hidden in plain sight’; none of their competitors will touch this code with a 10-foot pole, as using your IP will immediate require them to freely publish their own IP that is built on top of your code, or even co-compiled (some exceptions apply). Of course this provision is limited to the ‘distribution’ of the code, which in the Web 1.0 world was in the form of CDs, downloads etc. If someone takes GPLed code and does _not_ redistribute this code, and simply provide services around it (like Google does), they do not need to disclose their own code.

As for the GPLed codebase (and to some extent the EPL), you have two flavours in which the original projects can be stewarded, via an independent foundation or via a private-entity. Thus the MySQL (GPL private-entity) approach essentially forces all contributors to sign over their rights to the additional IP they have created to MySQL AB prior to it being incorporated in the main code-base. Some people may feel a bit irked by ‘working for’ a private corporation this way, and would rather contribute their code to a foundation such as the Eclipse or Mozilla foundation.

Without the sign-over provision, all changes are owned by the individuals who have made it. This obviously serves the purpose of GPL, which is essentially to enable the software to be free (and freely available), and essentially have a life of its own. However, if you are a startup and dreaming of an acquisition one day, this fragmented IP ownership will kill your dreams. You have been warned. Of course, if the acquisition will be based on the services you provide, or the customers or people you have, this should not preclude it from happening. If it is solely based on the software, you need to probably adopt and MySQL-like strategy of consolidating ownership.

RedHat, which is based on the GPL makes close to half a billion dollars of revenues annually. That is not chump-change.

The Eclipse Public License is mostly like the GPL. The only two exceptions are that any additions or changes made to the original work are owned by the parties making the changes, and patent litigation is excluded. This provides an incentive for firms to create complementary products, plugins, and wholly new applications based on the original EPL code-base and does not preclude them from commercialization of the new work they have contributed. This license is very friendly to both large and small firms (who now have an incentive to invest efforts and resources on development based on the EPL code-base), and also encourages the development of a community (or several communities) that are larger than the original copyright owner.

In summary, there are viable business models around all three licenses. Most of the recognized open-source licenses fall into a category similar to those represented by one of these three variants. However, all three are recognized open-source licenses and enable the rich collaboration that transcends national and corporate boundaries, creed and languages. They have enabled a rich-ecosystem for development that has enriched us all in many ways, and it is definitely an honourable action to share in the same spirit and be a part of this larger positive, productive community.

In addition, as the copyright owner, you also have the right to dual-license your software (again as MySQL did). This essentially means that you can distribute the software under (typically) the GPL or EPL, and give customers who want to NOT be bound by the redistribution and derived work clauses the option of having a commercial licensing arrangement with you instead. Thus the open-source license encourages adoption and wide-dissemination of your codebase, and is essentially a full-featured demo version, and if you set things up properly, a fair number of users will make the jump from the open-source license to commercial licensing with you.

To learn about a few more interesting business models, be sure to read the fascinating article on Peter Fenton’s 1.6 billion dollars open source success.