From time to time, we get asked why new contributors to any Opscode project have to sign a Contributor License Agreement (or a Corporate Contributor License Agreement.) While there is an explanation on the Opscode Wiki, we’ve never gone into deep detail on how we made the choice of the Apache License, nor why we follow the Apache Foundation’s practice of requiring contributors to sign Contributor License Agreements (CLAs) (and Corporations to sign Corporate CLAs). So if you geek out about open source licensing, and the intersection between business requirements and license choices, read on.
A quick disclaimer – I am not a lawyer, and this post is intended to make sure we’re as clear as we can be with our community, friends, and partners about why we chose the Apache License. You should choose the license that is right for your project.
Our Requirements
In a nutshell, we had three broad requirements for the license we released our open source software under:
Our Business
Really, every mainstream Open Source license will allow you to make money from your software. The real differentiation comes when you talk about how you make that money, and whether you allow others to make money in the same way. For example, a common practice in many commercial open source businesses is to license their software under a strong copyleft (GPLV2, GPLv3 or AGPLv3) and require copyright assignment from contributors. The important part here is the copyright assignment: this allows the company to be the sole copyright holder for the work, which provides them the benefit of being able to re-license the work as they see fit. Companies using this model include MySQL (GPLv2 w/FOSS exception, commercial license), Funambol (AGPLv3, commercial license), and Hyperic.
The intent of this model is clear: as the creators/originators of their respective products, each of those companies uses the copyleft to ensure that the playing field is level for those contributing back to the project. For those who wish to be free from those restrictions, they can pay a licensing fee, and then can do with the software what they will. It’s a fine model, and I respect many companies who follow it.
For us, though, this model comes into conflict with our second and third requirements: that anyone whose problems are solved by our software can use it, and that we not reserve any rights for ourselves that we don’t grant to other people (or companies) who help us build the software. Companies like Engine Yard and RightScale already have commercial offerings around Chef – they did so without needing to ask our permission, and with a high degree of confidence around the contents of the Chef code base. They are both contributing back to the project – not because they are bound to by the license, but because the eco-system encourages them to do it. They aren’t just helping Opscode – they are helping each other, and anyone else who uses Chef.
Which brings us to how we feel about the relationship of our license in terms of helping us make money on our free software. The license sets up the level playing field upon which a truly fertile community can grow – of individual contributors and corporations. We believe that we can build a business that works for us, and our investors, through building true and lasting partnerships based on equality and mutual purpose. Our decision on the Apache License reflects that choice.
Anyone can use it
The idea that anyone whose problems are solved by our open source software should be able to use that software is core to our culture. If Chef, Ohai, or any other project released by Opscode helps you: use it. Any time you can come up with a new use-case for our software, we want the answer to be: Go for it. Are you a company that wants to embed Chef for configuration management? Go for it. Are you an individual who wants to use Chef as a library in your open source application? Go for it. Do you want to license your cookbooks under an open source license and give them away? Go for it. Do you want to sell proprietary cookbooks? Go for it.
This desire is what led us away from the strong-copyleft licenses. Many of the open source projects produced by Opscode are libraries – Chef is a library, Ohai is a library, etc. Using the strong GPL variants would have caused our choice to restrict yours: if you wanted to distribute a work that used our software, it would need to be GPL-ed. An interesting potential problem would have occurred regarding cookbooks – since they essentially use Chef as a library, would they need to be GPL-ed if they were distributed? You could make an argument either way, but we decided it wasn’t worth it.
The weak-copyleft (LGPLv2/3) licenses would have overcome the above (or something like MySQLs FOSS exception could have as well.) They would still apply to the libraries themselves, though. So if your use case required you to modify the way internal workings of the library functioned, but needed that to be proprietary, the door was closed to you.
Which left the two major non-copyleft licenses on the table: Modified 3-Clause BSD and Apache v2. In order to understand why we didn’t use the BSD license, we need to expand the definition of “anyone can use it” a little further by allowing it to also mean “lowering the barriers to adoption”.
For many companies, choosing whether or not to use a piece of Open Source software hinges on factors that don’t normally come up in the lives of every day open source developers. Three large ones are:
While the 3-Clause BSD license allows you to do pretty much anything you want with the code in question, it provides no direct language around these areas. The Apache License, on the other hand, does. It makes very clear that individual contributors grant copyright license to anyone who receives the code, that their contribution is free from patent encumbrances (and if it is not, that they license that patent to anyone who receives the code,) and that use of Trademarks extends only as far as is necessary to use the product. It also includes a patent termination clause, should a lawsuit arise.
One impact of these additional clauses in the Apache license is that, when you receive a copy of Chef from Opscode, you know that all those bases have been covered. Concerned about patent liability? It’s in the license. Want to know how you can use our trademarks? It’s in the license. These protections are central to why we require CLA’s and CCLA’s, which I’ll jump into after we talk about…
Equal and Open Community
This is the biggest reason we chose the Apache license, and why we respect the goals of the Apache Foundation so highly. We truly believe that our software is made better, every day, by every person who runs it, files tickets about it, or patches it. The value of those contributions is huge – each one is given freely, in service and respect to the other members of that community. Opscode is a part of that community and a sponsor of that community – but we aren’t any more important than anyone else.
Opscode employees get paid to write Chef – every time a company like Sonian contributes, or an individual like Matthew Kent makes a difference, they are putting significant quantities of their time and money into the project. In return they deserve the respect and status equal to their commitment. One way we show that respect is by not restricting their use of Chef.
Why the CLA and CCLA are important
The Apache License already includes language around Copyright, Trademarks, and Patents. The addition of the CLA and CCLA makes each individual (or corporate) contributor explicitly state that they grant Copyright and Patent license, that all contributions are given voluntarily, that you are not expected to provide support for your contributions, and more. It adds the final layer of security to everyone who uses Chef – every single line has been covered, every contribution has been vetted, and each individual and corporation freely enters into the agreement.
What it doesn’t do is assign copyright to Opscode – we think that doing so would set us apart from our community in an inappropriate way. This is one of the more nuanced aspects of the CLA – when you sign it, and then give your contributions to Opscode, you are enabling us to bundle and re-distribute your work for you. If there should ever arise a legal issue regarding the project, it is the presence of these CLAs that help Opscode to defend it on your behalf.
The requirement for the CLA is for everyone’s protection – end users can be sure that the code is free from legal entanglements, developers can be certain their rights are explicit, and companies can be assured that by using the software they don’t expose themselves to any additional legal risk.
Why don’t more projects require them?
Many projects do require CLAs, or something similar. Many FOSS projects are simply started by an individual, published, and maintained – they never intend or need to grow into a larger community. As they grow, and projects become more popular, almost everyone winds up having to come to some conclusion about copyright licensing or assignment – even if their answer is “do nothing and live with the ambiguity”.
Faxing things is no fun
We agree. We’re talking with our lawyers about what the requirements are for gathering a legally binding CLA/CCLA, and how we can streamline the process. When we have definitive answers to those questions, trust us: we’ll be making the process easier. On the bright side, you only have to send it to us once for every project we publish. :)
Outro
If you have any questions about why we chose the Apache License, or why we require CLAs, you can always drop us an email – info@opscode.com.