E) Demystifying the Contribution License Agreement
1/29/2014 10:55 AM
This post is the ninth in a series that will explore why businesses should become active participants in open source communities. We’ll explore what open source is, the economics of OSS (open source software), who uses it, how to make projects successful, and how to participate in external projects. It will also taken a deep dive into more complex topics such as the commercialization of FOSS, community vs customers, managing inbound IP, licenses, software hygiene, and when NOT to publish a project.
Read the previous post: Community enables customers
Start from the beginning: Intro. What is it?
There comes a time in every successful project’s growth when provenance tracking becomes an issue. This typically happens in one of two ways:
- If a project started “in the wild”, i.e. no company involvement in the beginning, a time arrives in the successful growth of the project when commercial organizations want to get involved to use the software in their own products and services.
- If a company wants to start their own project, then they want to ensure that they have the rights required for any inbound contributions. Corporate lawyers that want to protect the company from inbound litigation and protect the flexibility of the business model want to ensure rights of ownership and use are clear.
Companies have different risk profiles from individuals. They want to know who owns the software they’re relying on if they don’t themselves own the project, or they want to know they themselves have the rights they need to the software if they themselves do own the project. Companies are also concerned in the reverse situation of who may receive the benefits of their own contributions.
The rights from the contributor can be either assigned to the project (such that the project then has complete control) or licensed to the project (such that the project simply has the rights to use the contribution). There are reasons and debates on both sides and from both perspectives:
- Two very outspoken and knowledgeable lawyers in the free and open source space come down on opposite sides of the debate. One feels a developer must never give up their rights of ownership. The other feels the only way a foundation can properly defend a body of software is to wholly own the rights to the software and all its contributions.
- Some feel the license of the FOSS project is a sufficient declaration for rights licensed in and nothing more need be done.
Corporations often err on the side of legal conservatism if they are the owner of the project and demand all rights of ownership for contributions be assigned to them. This comes with some risk to the project that it will scare away contributors that aren’t interested in the friction or having for-profit corporations own their work. This is because ownership can change and a contributor may see their contributions move in directions they didn’t intend. This was most obvious in the acquisition of MySQL AB (a company that insisted in contribution assignment) being acquired by Sun Microsystems that was then acquired by Oracle Corporation.
The assignment or license generally takes the form of some kind of agreement between the owner of the project and the contributor. Because contributors often work for corporations that own the rights to the contributor’s work through an employment agreement, agreements are generally worded to require the true IP holder to sign the contribution agreement. Just as there was a proliferation of FOSS licenses and the Open Source Initiative attempted to determine which licenses actually met the open source definition, so to exist many different forms of contribution license agreement (CLA) or assignment agreement. Work was done to attempt to rationalize these and the work is catalogued along with the template agreements at http://harmonyagreements.org/.
The fact remains that different successful open source software projects do different things when they grow successful enough that commercial organizations want to get involved. This varies as widely as the Apache Software Foundation projects working with licenses, to the Free Software Foundation requiring assignment. The Eclipse Foundation handles its rigorous IP management process through membership agreements and eschews CLA, and the Linux kernel project insists that a simple “Developer Certificate of Originality” (DCO) as a comment line in the version management system is sufficient. (One might want to consider the depth of the OEM legal bench protecting Linux before you naively consider this as the best solution.)
As discussed in the section on FOSS foundations, such foundations solve many of these provenance tracking and ownership issues; indeed, this is the core reason they exist regardless of what they otherwise represent to their memberships and constituencies.
Read the next post: When not to publish OSS software