![]() They aren’t just helping Opscode – they are helping each other, and anyone else who uses Chef. 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. ![]() ![]() 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. It’s a fine model, and I respect many companies who follow it.įor 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. 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. 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. Companies using this model include MySQL (GPLv2 w/FOSS exception, commercial license), Funambol (AGPLv3, commercial license), and Hyperic. 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. 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 real differentiation comes when you talk about how you make that money, and whether you allow others to make money in the same way. Really, every mainstream Open Source license will allow you to make money from your software. 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.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 a license that allowed us to build a business from our creations. We are an Open Source business – meaning we want to make money from our Open Source software.In a nutshell, we had three broad requirements for the license we released our open source software under: You should choose the license that is right for your project. So if you geek out about open source licensing, and the intersection between business requirements and license choices, read on.Ī 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. ![]() 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).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |