Open-source licensing - fact and fantasy (or at least religion)

Open-source, as discussed in the previous posting on network equipment, is a fascinating world. Perhaps the best intellectual and business promotion ever written is Eric Raymond's "The Cathedral and the Bazaar." There is no question that open-source has led to an upheaval in the world of business technology, enabled entirely new industries, and benefitted the overwhelming majority of individuals and companies out there, with few tears shed for those commercial vendors that have lost business due to open-source competitors. For those who do shed such tears, I strongly recommend Joseph Schumpeter's "Capitalism, Socialism and Democracy."

In this article, we will explore the legal side of open-source. This article was inspired by a rather heated debate on open-source licensing with The Schlossnagle. Theo is probably one of the best system engineers and architects I have met. He is the author of a book on building scalable Internet applications, and founded and runs the consulting firm OmniTI.

Open-source creates an interesting and unique series of challenges for its creators.

• Copying: In the closed-source world, while someone else can potentially reverse-engineer your product, or duplicate its functionality, in the open-source world, the original source is available right there for anyone to take. Thus, the only protection you have as to how your code is used is legal in the form of copyright.
• Usage: In the closed-source world, you have the option of using code inside your software to restrict its usage and functionality, based on, for example, license keys, which you control. In the open-source world, such an option does not exist. Since the code is open-source, it is easy for anyone to see how the usage controls work and bypass them.

Unsurprisingly, most open-source products allow for unlimited usage. For example, anyone can download and run as many copies of Apache, Linux or OpenBSD that they want. It is almost a truism that open-source and unlimited usage are the same. Obviously, they are not, but they essentially go hand-in-hand.

Where it gets interesting is in redistribution or repackaging. To understand this, we need to delve a little bit into the arcana of copyright law.

In most modern developed countries, copyrights give the author of some creative work the exclusive right to decide how his or her work may be redistributed. This does not include an original, depending on the laws of a country in question and sometimes the particular sales agreement, but duplicates. Thus, if I create a painting, and you (for some unknown reason, given my artistic talents) purchase it, in most cases you may then resell that painting to whomever you want and for whatever price makes you happy. However, under copyright law, you do not have the right to duplicate or copy (hence rights to copy or "copy-right") that exact painting and sell it off. In doing so, you are violating my copyright. I, and only I, have the right to decide how my work gets duplicated.

All of this is particularly relevant in the world of open-source code. If I create an open-source product, when you download it, you have already created a copy. You are welcome to use it for your own use as you see fit. However, if you distribute it to someone else, especially for some form of compensation, and you have not received my permission to do so, you have violated my copyright.

Given all of the above, it is crucially important to decide exactly how the creator of open-source software will license that software. There are, essentially, two schools of thought in open-source licensing: GPL and BSD/Apache/MIT, which, for brevity, we will call BSD.

• GPL: The Gnu General Public License, based on the Gnu project by Richard Stallman, is a restrictive distribution license. While it has many details, its philosophy is, essentially, "I made this for free, you can use and distribute it for free. If you want to make money off of it, you cannot since I did not." The GPL restricts distribution of the software to inclusion in any other software or product that is also GPL (or compatible). For many open-source developers, this makes a lot of sense. They are more than happy to contribute their work product to the good of the community, but do not want someone using that work product to make money unless they do. There really is one downside to the GPL: it restricts adoption. If what you have is unique, or used only in GPL-type products, then adoption will be high. But given the choice between a GPL product and an unrestricted one, a new product developer will always prefer to incorporate an unrestricted one.
• BSD: This is a class of license that says, essentially, do what you want with my product. There are variants on the BSD (not taking into account who was first) incorporated in the BSD, Apache, MIT and several other licenses, each of which contain legally important differences, such as limitations of liability, requirements of attribution, and other legalities, but essentially all of these licenses let someone use and redistribute the product largely at will. Thus, if I am building a commercial product, I am unable to use a GPL-licensed product in mine, but I can use a BSD one.

The battles between the BSD and the GPL camps can get fierce at times. The GPL was created by a "religious extremist," the BSD is an "invitiation to legal piracy," the list goes on. When a very powerful Web 2.0 rich client library, ExtJS, converted from a less restrictive version of the GPL (LGPL) to the full GPL, criticism by users was severe. In the end, both of these philosophies are valid, and are entirely subject to developer's choice. If you created a product, you really do have three choices:

1. Keep it closed-source and sell it commercially. Microsoft and Oracle have built huge business on this, as have countless other companies. There is nothing wrong with reaping the financial benefits of your financial investment.
2. Open-source it and make it completely available, i.e. BSD. Again, there is nothing wrong with being fully community-focused, and either making no money on the product, or making money through ancillary services, such as consulting and support arrangements.
3. Open-source it and restrict it only to similar products, i.e. GPL. If there is nothing wrong with making money off of your labour and investment, and it is certainly commendable to contribute to the community, it is certainly acceptable to take a middle road that says, "I want to make money, but am willing to be altruistic towards others who are also altruistic." Many products in the GPL world are dual-licensed, wherein the GPL applies to other GPL products, but if you want to embed it into a commercial product, you need to buy a typical commercial license.

Theo did raise one interesting objection to my middle-of-the-road argument in favour of GPL and/or dual licensing. He said that commercial and BSD-style are very clean and clear, black and white. One has a very clear picture where one stands. The GPL and dual-licensing, on the other hand, are much more in the middle, a shade of grey, and can be confusing. While I understand that objection, I am not convinced it holds for several reasons.

1. Life is grey. Very rarely is life, or business, black and white. Humans work quite well on the middle ground, codified as Maimonides' "golden mean."
2. If it works, use it. If the philosophy applies well to the situation at hand, then it should be used.

Which does this author prefer? None. Each license - commercial, BSD, GPL - has its time and place.