Why we chose the Apache License

  • August 11, 2009
  • By Adam Jacob
  • Share Share

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:

  • We are an Open Source business - meaning we want to make money from our Open Source software. We wanted a license that allowed us to build a business from our creations.
  • We wanted anyone (or any company) whose problems were solved by our software to be able to use it, in any environment they wanted, in what ever way they wanted.
  • We wanted to build an open and equal community - we didn’t want to reserve any rights for ourselves that we didn’t grant to the other people (or companies) that help build the software.

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:

  • Copyrights
  • Patents
  • Trademarks

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.

4 Comments

Great article! (yah yah.. I'm biased)

This is a great explanation for a lot of the ideas, goals, and philosophy of the Apache Software Foundation. I love to see people outside the ASF consider and then end up at the same points.

There are two things about the article that I'd like to hilite, however. You used the phrase "grant copyright license" at one point which can be unsettling. A reader might think "grant copyrights" or "transfer copyrights", which neither you nor the ASF asks for. The longer form is something like "grant rights to the Chef project using a license based on copyright law". Ugh. Maybe just "provide rights" would do the trick.

The second point is about the CCLA. You mention the term but don't discuss it in the post. Fair enough, for a very specific reason: *you* don't care one iota about them. Protip secret: neither does the ASF. When a contributor signs a CLA, they are asserting they have the ability to grant you the necessary rights. Done. You're covered. There is no sense in second-guessing that piece of paper or the contributor. The CCLA [at the ASF] was conceived by some companies who wanted to tell themselves "yes, our employees have the ability to grant you the rights." But it was for *their* benefit. The individual CLA is more than enough.

Cheers,
-g

  • Ryan Tomayko
  • September 22, 2009
  • Reply

This seems sensible and addresses most of my initial
skepticism. I appreciate it. Let me dump out some of my
initial thoughts on the matter in return. It may help you hone
the messaging on this stuff even further so that contributors
aren't scared away by bad assumptions.

(I should mention that I'm speaking entirely from the
standpoint of a potential individual contributor here and not
in any way on behalf of Heroku.)

The ASF and Opscode are very different types of organizations.
The ASF is a non-profit, opscode a for-profit. The CLA
requirements were put in place at the ASF to protect the
community from the massive patent/copyright suites held by
corporate contributors like Sun, IBM, Oracle, etc. and also to
offer some protection to those same organizations from
individual contributors. It struck me as very odd to see the
same CLA used within the context of a for-profit, private
corporation. Do the implications of signing a CLA change when
granting a license to a for-profit as opposed to a non-profit?
IANAL, so I really don't know.

I do know that it's possible to effect the decision making
process at the ASF. The ASF's corporate assets are managed by
their board of directors, and the board is elected by ASF
members. I'm an ASF member immediately after signing a CLA and
contributing code (assuming it's accepted). Board meetings are
basically transparent, with minutes available on the web. And
the ASF was formed specifically with the goal of "creating an
independent legal entity to which companies and individuals
can donate resources and be assured that those resources will
be used for the public benefit." The ASF board's job is to
further that goal.

Opscode-the-corporation's goals are -- by legal definition --
very different from the ASF's, even if your current intentions
are very similar. It's clear from your thorough explanation
that your intentions are, well, wonderful (seriously. laying
them out like this took me from being afraid of opscode to
wanting to contribute because it's clear we believe in the
same things). The thing is, IANAL, so licensing situations
without precedence make me nervous. And legal devices are more
about *capabilities* than they are about intentions anyway.
And I don't get to vote on your board after signing the CLA
and contributing code.

I guess what I'm getting at is, 1.) it's less likely that the
ASF would mishandle the rights the CLA grants, and 2.) I have
many more avenues for impacting how the ASF uses those rights.
Does that make sense?

Your explanation doesn't really clear up much of the above,
but it does give me a good feeling for your intentions. That's
worth something.

One thing I was mistaken about after reading the FAQ, and
something you cleared up in this piece, is assignment of
copyright. You state above that, "what [the CLA] doesn't do is
assign copyright to Opscode - we think that doing so would set
us apart from our community in an inappropriate way." The FAQ
states, "that you grant copyright license for your
contributions to Opscode" and "that you grant patent license
for your contributions to Opscode." These two statements are
consistent but it's much more clearly stated here than in
the FAQ. A casual reading of the FAQ could leave potential
contributors with the sense that they're signing over
rights for their work, as opposed to granting a license to
use and distribute their work.

Lastly, I'll just mention what you already know: the CLA is a
big pain in the ass and that's going to decrease contributions
and overall acceptance. Signing and faxing the form is not a
big deal, it's having to think about it that sucks. It's a
very creative business model and maybe it strikes the right
balance but from the perspective of an individual outside
contributor, it worries me that the barriers to participation
are so much higher than most other projects.

Thanks. I hope this helps.

<p>Thanks for the thoughtful response, Ryan. </p>

<p>Let me address your concerns here:</p>

<p>First, the meta concern - that Opscode is not the ASF, and that we’re embarking into murky licensing territory by re-using a modified ASF CLA/CCLA. While it’s true that Opscode is not a non-profit dedicated to preserving open source software for the benefit of the public, we are a company who has clearly decided our open source software belongs to its community, and not to us. We also aren’t the only company that uses the ASF model for creating a vibrant community - one pretty prominent example is Google. They have essentially identical terms for contributing to their open source projects as Opscode. In fact, both of our documents derive from the same parent - the ASF CLA.</p>

<p>“it’s less likely that the ASF would mishandle the rights the CLA grants”</p>

<p>There are no special rights granted in the CLA/CCLA that aren’t granted to everyone who receives a copy of Chef. The worst we can do is manage the project poorly, at which point another member of the community is free to forge a different direction. What you <em>are</em> doing is making clear the terms under which your intellectual property has been contributed for inclusion into the version of Chef distributed by Opscode. The reason this act is necessary is so that a level of trust and defensibility can be built up around the project as managed (and distributed) by us. </p>

<p>The ASF operates specifically to ensure that projects are managed in the best interest of their members. It’s deeply in our best interest to behave in the same way - if we do something janky with Chef, our community is not beholden to that choice. The spirit of community, freedom, and openness embodied by the license and the process remains the same. If we behave badly, we will irreparably damage our business, our brand, and our partnerships. While we don’t have a charter that promises we’ll always act in the best interest of the public, we do have an obviously strong bias towards doing so - not only on a philosophical level, but on an economic one.</p>

<p>The rights the CLA grants, though, don’t actually give us any privileges that we can mishandle in a nefarious way. By contributing at all, even if we didn’t have CLAs, you agree to the terms of the license: they include the Grant of Copyright License, Grant of Patent License, Trademark privileges, etc. The CLA just makes it very, very clear that when you become a <em>Contributor</em>, you are doing so with full knowledge of what that means. You loose nothing, and everyone gains protection.</p>

<p>“Do the implications of signing a CLA change when granting a license to a for-profit as opposed to a non-profit? IANAL, so I really don’t know.”</p>

<p>The answer here most likely is “it depends on the terms of the CLA”. In our case, we have changed the CLA very little - we removed any reference to the ASF, added a section about what jurisdiction any dispute over the agreement would be in, and added more language around the fact that you give your contributions voluntarily, that contributing does not create a confidentiality obligation, and that we are not required to use (or not use) your contribution. In the end, you haven’t granted us any rights not granted to everyone who receives a copy of the software with your contribution included - you’ve just clarified that you meant to give it to us <em>so we can include it</em>. :)</p>

<p>“I have many more avenues for impacting how the ASF uses those rights.”</p>

<p>Sure - you’re a smart guy, and Heroku is neat, but you can’t be on our board of directors. But I think I answered this point above - you do have many avenues for impacting how Opscode manages Chef! By participating in the community, you influence the process. If we are bad stewards of that community, we won’t remain the steward for long. That choice was explicit on our part, and embedded in our culture and business. Our choice of license reflects that decision - going back would be terrible business. </p>

<p>“The CLA is a pain”</p>

<p>The reality here is that there is a mighty loophole in most open source projects, and it’s directly over the fact that they don’t collect some kind of CLA/CCLA or require copyright assignment. This is why almost every major open source company uses CLAs: the ASF, MySQL, OpenOffice.org, Fedora, Zend, and the FSF itself. Making the chain of intellectual property contributions explicit matters. The larger your project gets, the more it matters, and the harder it is to correct.</p>

<p>As to it being a barrier to contribution, it certainly turns off some people. But it’s not a problem for many - since the project was first released in January, <a href="https://www.ohloh.net/p/opscode-chef/contributors">31 different developers have contributed to Chef</a>.</p>

<p>I would love to live in a world where this sort of thing isn’t important - where the thing of maximum importance is how quickly we can go from clicking “fork” on github to having me (or someone else) type “git pull”. We just don’t live in that world… so until then, we have to keep any level of FuD about the software out. The CLA does that.</p>

<p>In the time it took to write the original blog post and this reply, we’ve put our <a href="https://secure.echosign.com/public/hostedForm?formid=PEQXK2G534V">CLA up as a form you can fill out via EchoSign</a>, which should speed the process up dramatically. Ideally, that makes the time it takes from “I have a patch” to me typing “git pull” is the time it takes for you to read the CLA, maybe this blog post (to answer the “why do I have to do this question”,) and fill out a web form. </p>

<p>If it hadn’t been for your influence on us, this might have taken months longer for us to get around to. Thank you for being the fly in that ointment, Ryan.</p>

<p>Let me know if I can answer anything else.</p>

  • Nicolas Grilly
  • January 15, 2010
  • Reply

Thank you for this excellent post about the reasons why the Apache license is sometime a more appropriate choice for a library, more appropriate than the GPL, LGPL and BSD licenses.

Leave a Reply