I wrote a recent blog post on which FOSS license to use and it provoked Twitter commentary that wanted more discussion on how FOSS license choice can affect a company’s business model. I’m still not sure I agree that the FOSS license dictates the business model or that the business model dictates the license. A few examples probably better illustrate what I’m trying to describe.
Let’s look at each of Red Hat and Linux, and MySQL AB and the MySQL database (before the cascading acquisitions). Both open source projects are licensed using Version 2 of the GNU General Public License (GPLv2).
Red Hat packages an asset that they neither own nor control. They influence the Linux kernel through participation in the Linux kernel community. They use the Linux kernel in their Red Hat Enterprise Linux and Fedora Project operating systems. They surround the kernel with considerable other software (most of it free and open source project-based from a collection of other project communities in which they participate). They support and warrant their product solution, as well as develop and enable the Fedora project community. They are the most profitable and successful Linux vendor and indeed the most successful open source company to date, finally cracking the US$1B revenue barrier in 2012.
MySQL AB (the company) built and packaged the MySQL database engine. Here, they ran a very different pair of businesses. They evolved the MySQL Network, which was a subscription "product" that again ensured the MySQL database product was supported and warranted to run in specific configurations on specific platforms. As the company completely owned the software asset, they completely controlled its use. Asset owners can license the asset to as many people as many ways and as many times as they choose. (Think Microsoft and the difference between a Windows EULA and an enterprise agreement for the same OS.) This allowed MySQL AB to also evolve a healthy secondary revenue stream from licensing the MySQL database to others that wanted to embed the engine in their proprietary products without attaching the GPLv2 license of the public version. Sun Microsystems acquired MySQL AB for US$1B.
In each case, the FOSS project was licensed under the GPLv2, but asset control and ownership dictated how very different billion-dollar businesses were built rather than the license. This can be seen in other key licenses such as the Apache 2.0 and Eclipse licenses.
IBM doesn’t control or own the Apache projects. (Again, they do participate deeply and therefore have influence.) A number of Apache projects are key components in the IBM proprietary Websphere platform, providing robustness and time-to-market and distributing the development costs over a large group of companies/people. The Apache license follows in the tradition of the older, academically focused BSD and MIT licenses and allows people to use the software in any manner they choose, including closing it into proprietary products. IBM followed in the OEM traditions of everyone embedding MIT-licensed X11 and BSD-licensed network stack software in their proprietary products, and relies on Apache-licensed software in Websphere.
The economics of living on a fork can get expensive unless there are really good business reasons so to do. We don’t know if IBM changes anything in the Apache projects they use in products. Presumably they do. IBM has always managed its hardware patent portfolio very carefully. They could well have patented hardware that requires changes to the Apache-licensed software to get maximum performance in Websphere, but they likely minimize the nature of the fork to minimize the engineering costs while also minimizing their perception of their legal exposure on their patent portfolio.
One can see the care taken around the IBM patent portfolio in their creation of the progression of licenses attached to our next example — Eclipse. The original IBM Public License, its evolution into the Common Public License, and now the Eclipse Public License, all maintain a particular phrase to ensure, "No hardware per se is licensed hereunder."
Putting that aside, these licenses belong to a class of licenses that began with the Mozilla license that encourages companies to build upon and extend the core project without necessarily being required to publish the extensions under the same license. Only modifications to and derivatives of the core project need be published under the original license. It was hoped that businesses would be encouraged to participate while feeling they could build and control proprietary products if needed. Red Hat had not yet demonstrated their long-term success on an asset they didn’t own and control when the Mozilla project started, nor had they yet been a public trading company long when the Eclipse project began. It was felt that a copyleft license that protected the core project software while enabling more do-whatever-you-want licensing around the core would be the best way to encourage the "best" community behaviour and support both the perceived needs of the software business community and the broad free and open source software community.
Many companies are now developing proprietary products on and around the Eclipse platform while others happily deliver software extensions for their own programming platforms licensed under open source licenses (e.g. Intel and Tizen and Amazon and Android).
Interestingly, commercial software ownership again doesn’t play a part in either example. It’s a neutral non-profit foundation that maintains the ownership, thereby setting the stage which encourages corporations to contribute and participate. The foundation maintains the robust inbound IP contribution management and tracking required by participating corporations for their own risk mitigation. The foundation defines the neutral non-profit level playing field corporations need to encourage them to share their non-core R&D investments.
In each case, the FOSS license isn’t what defines the business model. Neither does asset control necessarily define the business model (although certain business models cannot happen without asset ownership and control). The two most successful data points we have in Red Hat and MySQL AB both used a license often perceived as the most business-hostile (it’s not), and they each ran multiple different business models, only one of which was based on asset control.
License choice is an important consideration when making open source software, defining the initial social contract and sharing model for the technology in the early community. I’ve covered those discussions at length in two previous posts on making open source and making commercial open source. Businesses are based on creatively solving customer problems, and doing so better than potential competitive solutions. Free and open source software can play a vital role in delivering solutions regardless of the FOSS license applied. Christensen described how disruptive business models occur when "off the shelf" parts are assembled into new solutions. FOSS project communities themselves provide such components regardless of FOSS license, and businesses are in a great position to build new innovative business solutions when they create, participate, and contribute to such FOSS projects.