One of the challenges free and open source software projects have that proprietary software doesn't is determining the best method for accepting developer contributions to a project from a legal perspective, not an engineering perspective. In proprietary software, where all of the developers work for the employing entity, the copyright in their work belongs to the employing entity under the “work for hire” doctrine found in
17 U.S. Code §101.
Free and open source development projects cannot (and really don't wish to) rely on the work for hire doctrine and have to develop their own rules of the road for developer contributions. One of the first issues to be addressed is context. What does the project seek to achieve? Who started the project? Is one entity principally responsible for most of the code in the project?
Where the project is largely managed by a single entity there is some benefit in having all copyright in the code base held by that single entity in order to assure compliance with the governing FOSS license. This is a bigger issue in the U.S. under copyright than it tends to be in some other countries. For example, one of the reasons that Harald Welte has been so active in GPL enforcement in Germany is the more lenient standards for standing (the right to sue) in German courts under copyright.
Where that single entity is a commercial entity, there may also be an interest in dual licensing, i.e., the ability to license the same code under a FOSS license and a proprietary license. This approach has been successfully employed by companies such as MySQL, but MySQL also wrote about 99% of the code in their code base. The original MySQL contributor agreement was replaced with one from Sun, and has now been replaced by this one from Oracle [PDF], which grants Oracle joint ownership of copyright. [NB: Joint ownership of copyright can be problematic, since each of the owners can license under terms they choose.]
There are also projects that are truly open source projects and where the project maintainers are more interested in simply assuring they have sufficient rights in the contributions in order to include them in the project. They may also be interested in maintaining some flexibility around which FOSS license to use as the project develops. Each of these approaches results in a different approach to how contributions of others are handled, and because each project is unique, contribution agreements tend to cover a wide range of approaches. Simon Phipps has written a good article discussing some of these issues and addressing Project Harmony, but more about Project Harmony later.
Some projects, like the GNU projects run by the Free Software Foundation (FSF), in some instances require an assignment of code submissions if they are to be included in the project. [See, Contributing to GCC as an example. There the FSF asks that contributors either assign their copyright or disclaim it (put the code in the public domain). In neither case does the contributor retain any rights under copyright in their contribution. Such an approach likely works for the FSF because they have been a trusted partner in assuring code stays free. You can see the full text of such an assignment to the FSF here:
Free Software Foundation
59 Temple Place Suite 330
Boston, MA 02111
For good and valuable consideration, receipt of which is acknowledged, (the "Assigner"), hereby transfers to the Free Software Foundation, Inc. (the "Foundation") its entire right, title, and interest (including all rights under copyright) in its changes and enhancements to the computer program , including changes in accompanying documentation files and supporting files as well as changes in actual program code, subject to the conditions below. These changes and enhancements are herein called the "Work". The work hereby assigned shall also include any future revisions of these changes and enhancements hereafter made by the Assigner.
The Foundation grants the Assigner non-exclusive rights to use the Work (i.e. the changes and enhancements, not the program which was enhanced) as it sees fit; this grant does not limit the Foundation's rights.
For the purposes of this contract, a work "based on the Work" means any work that in whole or in part incorporates or is derived from all or part of the Work.
The Foundation promises that all distribution of the Work, or of any work "based on the Work", that takes place under the control of the Foundation or its agents or assignees, shall be on terms that explicitly and perpetually permit anyone possessing a copy of the work to which the terms apply, and possessing accurate notice of these terms, to redistribute copies
of the work to anyone on the same terms. These terms shall not restrict which members of the public copies may be distributed to. These terms shall not require a member of the public to pay any royalty to the Foundation or to anyone else for any permitted use of the work they apply to, or to communicate with the Foundation or its agents in any way either when redistribution is performed or on any other occasion.
The Foundation promises that any program "based on the Work" offered to the public by the Foundation or its agents or assignees shall be offered in the form of machine-readable source code, in addition to any other forms of the Foundation's choosing. However, the Foundation is free to choose at its convenience the media of distribution for machine-readable source code.
The Foundation promises to give or send the Assigner, upon reasonable prior notice and payment of a fee no more than twenty times the cost of the necessary materials and postage, a copy of any or all of the works "based on the Work" that the Foundation offers to the public or that it has offered within the past six months, or that it distributed for the first time within the past six months. For works that are programs, the machine-readable source
code shall be included. Such a request shall detail whether the Assigner wish to receive all such works or specific works. The choice of works to request may affect the cost and therefore the fee.
The Assigner hereby agrees that if it has or acquires hereafter any patent or interface copyright or other intellectual property interest dominating the program enhanced by the Work (or use of that program), such dominating interest will not be used to undermine the effect of this assignment, i.e. the Foundation and the general public will be licensed to use, in that program and its derivative works, without royalty or limitation, the subject matter of the dominating interest. This license provision will be binding on the assignees of, or other successors to, the dominating interest, as well as on the Assigner.
The Assigner hereby represents and warrants that it is the sole copyright holder for the Work and that it has the right and power to enter into this contract. The Assigner hereby indemnify and hold harmless the Foundation, its officers, employees, and agents against any and all claims, actions or damages (including attorney's reasonable fees) asserted by or paid to any party on account of a breach or alleged breach of the foregoing warranty. The Assigner makes no other express or implied warranty (including without limitation, in this disclaimer of warranty, any warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE).
For the Assigner,
[name and title]
[signature and date]
For the Free Software Foundation,
Richard Stallman, President:
[Please write your snail address here, so I can snail a copy back to you.]
FSF uses the above approach where FSF itself is the principal developer of the project or where the principal developers have elected to assign copyright to the FSF. But this approach is not used on all GNU projects, some of which rely merely on the governing GPL to keep everything in line. [Note: See updates, below.]
You will also note from the above assignment text that the FSF makes an important commitment to the contributor as to the manner in which the FSF will relicense the contributed work. In other words, the FSF has limited itself to the GPL, LGPL, or Affero GPL, so any party assigning to the FSF can take comfort that their contribution will remain free.
But where does that leave other development groups, including those run by commercial entities such as Red Hat (Fedora Project) and Canonical, to say nothing of important projects like Apache and Eclipse that have their own communities. How do each of these entities approach the subject of contributions to projects they are managing.
Canonical, and more specifically, Mark Shuttleworth, have made
some news lately around Canonical's contributor agreement. The Canonical approach mirrors, to some extent, the approach taken by the FSF. Canonical asks contributors to assign the copyright in their contribution to Canonical, and Canonical then “simultaneously grants the contributor a very broad license back, so that the contributor retains full rights to re-use, distribute, and continue modifying the contributed code.” The language of the grant states:
Canonical grants to Me a world-wide, non-exclusive, royalty-free and perpetual right to use, copy, modify, communicate and make available to the public (including without limitation via the Internet) and distribute, in each case in an original or modified form, the Assigned Contributions as I wish.
As Canonical states, this is a very broad grant, and it would allow the original author of the code to relicense their code contribution to any other party under terms of their choosing, including a proprietary license. In terms of rights vesting in the original author, that would seem to be a bit of an improvement over the FSF approach which only provides the original author the same license in his/her contribution that everyone else receives, i.e., a license under either the GPL or LGPL as determined by the FSF, including the determination of which version of those licenses. In any case, Canonical obtains unfettered rights to relicense the contribution in any manner it chooses and makes no commitment as to the form of such license. There is no assurance that the license Canonical uses will be a FOSS license, although Canonical states that will “ordinarily” be the case.
The Canonical agreement addresses potential patents through a promise not to sue from the contributor. But clauses 7 and 8 of the Canonical agreement place a rather heavy reporting and notification burden on the contributor:
7. I will not assert or enforce any patent against (a) Canonical (b) anyone who received the Software and/or the Assigned Contributions from Canonical or (c) anyone who received the Software and/or the Assigned Contributions under a Free Software License, where that patent is infringed by any of them exercising copyright rights in the Software and/or the Assigned Contributions. I will promptly notify Canonical and provide details of any such patents (and any published patent applications which if granted are likely to constitute such a patent) for which I am the proprietor (or applicant). Canonical will not assert or enforce against Me any patent that is infringed by Me exercising My copyright rights in the Software and/or the Assigned Contributions.
8. If I am or become aware of any patent or other intellectual property right which is, or is likely to be, infringed by the use of the Assigned Contributions, I will promptly notify Canonical.
All of this has led to significant push-back on the Canonical approach even though it is only shades of difference from the original FSF approach. The primary reason for the push-back? Probably the fact that Canonical is a commercial entity.
By contrast, the historical method used in the Fedora Project sponsored by Red Hat has been to obtain a broad license from the developer but leave the copyright ownership with the developer. This can be seen in the now superseded Fedora Project Individual Contributor License Agreement. In another departure from both the FSF and Canonical approach, Red Hat obtained an express license in any patents the contributor held covering the contribution. But one of the significant shortcomings (at least in the eyes of a number of contributors) of this old approach by Fedora was that it did not assure Red Hat would relicense the contribution as FOSS. Not surprisingly, while this approach left the copyright in the hands of the original author, the broad license rights granted Red Hat with no assurance that Red Hat would only relicense the code as FOSS left a number of contributors cold.
But one of the things the maintainers of the Fedora Project came to realize is that Fedora is primarily an aggregator of projects, not an originator of projects. As an aggregator, Fedora is more interested in assuring that packages included in the distribution have an acceptable FOSS license that governs them rather than worrying about an assignment or broad license apart from that package license.
So Red Hat, having hired much smarter lawyers than the one responsible for the old CLA (I think his first name was Mark) and listening to the Fedora developers went back to the drawing board and came up with the
Fedora Project Contributor Agreement or FPCA. The FPCA is a very different animal. It is not a copyright assignment agreement, and it is not a broad grant of license in copyright to the code. Rather it works a lot like the Uniform Commercial Code does for commercial transactions under state law, i.e., if you specify a license for your contribution, that's what governs, but if you don't specify a license, then the contribution will be deemed made under the default license, which for the time being is the MIT license for software contributions. Now make no mistake about it, the MIT license is a very broad license, and it, too, would allow the code to be used in both FOSS and proprietary distributions. However, if you are concerned about the MIT-default, then specify your own. Your choice. You the developer control. Of course, if you specify a license that is unacceptable to Fedora (and they go to great lengths to let you know what is acceptable), then they won't accept your contribution.
This new Fedora approach would appear to be a vast improvement over any of the other approaches discussed above, at least on the copyright side, but for all of the improvement on copyright terms, it says nothing about patents. The problem there is that many of the FOSS licenses, including the MIT license, say nothing about patents. When asked why the omission, a Red Hat representative stated that it was a “considered decision,” recognizing there may be some risks but also recognizing that this keeps the process simple and acceptable to package maintainers and developers.
Returning to Canonical, it's not like they aren't trying to address the issue of contributor agreements. One need only look at Project Harmony, originating with Canonical general counsel Amanda Brock and described as:
Its initial goals are to avoid proliferation in contribution agreements across FOSS software projects where those organizations chose to work with contribution agreements. In doing this we hope to assist organizations which use contribution agreements by providing standardized variable templates with clear and concise explanations; to come to a common understanding on these; and to recognize the relative maturity of FOSS by dealing with its internationalization. We hope to make it easier for organizations to have and use contribution agreements. We believe that contribution agreements should make it easier for developers to contribute regardless of who their employers are.
Project Harmony is not a single contributor agreement; it is
a series of such agreements. You can use either a license approach or an assignment approach. Project Harmony simply proposes that you use one of its standardized forms of agreement as opposed to a uniquely drafted one so that contributors can be confident they have seen the agreement language before and understand the approach being taken. So Project Harmony is not necessarily a new approach but rather seeks to standardize contributor agreement language depending on the approach one elects.
A quick review of some of the other contributor agreements that have been or are being used:
- Android - Google utilizes the broad license approach.
- Mono - Novell requires a copyright assignment if the contribution pertains to C# compiler or the Mono runtime engine.
- Apache - The Apache Software Foundation uses the broad license approach.
To the extent you wish to upload, submit, or otherwise make Non-Code Content (as defined below) available to the Eclipse Foundation and/or the Members, you may make that material available under the terms and conditions of the EPL or any other license stipulated for that purpose at www.eclipse.org/legal. Non-Code Content is Content for which you own or control all rights, and which is not program code intended to be submitted to a Project and documentation related to such code. For example, Non-Code Content would include white papers, dissertations, articles or other literary works, power point presentations, encyclopedias, anthologies, wikis, blogs, diagrams, drawings, sketches, photos or other images, audio content, video content and audiovisual materials.
In summary, there are a number of different approaches to code contributions, and each approach is dependent on the nature of the entity, its particular goals, and the degree it is the predominant contributor to the project. There really is no one right answer, but there are also reasons why developers may balk at such terms. If a developer doesn't like the terms offered/imposed, they can elect not to contribute or start their own project. Ahh, the freedom of FOSS.
Update: We asked Richard Stallman if he had any comments to add regarding what FSF requires and regarding the Canonical CLA, and here is his response, plus a clarification from Brett Smith of FSF:
When a new GNU package is established, the developers can choose to
give the copyright to the FSF or to keep it. To give the copyright to
the FSF, they sign copyright assignments. Once the package is
FSF-copyrighted, we ask subsequent contributors to assign copyright
And Brett Smith clarified further:
In our copyright assignments we commit to releasing only with source
code and with freedom to redistribute. Other contributor agreements
place only very weak limits on what the company could do with your
The FSF published recommendations for contributors considering signing
such agreements, telling them what to look for. I don't remember the
URL and I can't see it in my machine. I cc'd Brett who can tell you
where to find it. He can also tell you more about what the Harmony
contributor agreement implies.
I think that under the Harmony contributor agreement, if the company
nearly always released your code in nonfree releases, it would be
violating the agreement. But it could go almost that far without
violating the agreement.
The article RMS is referring to is at
I'm pretty sure RMS was thinking about Canonical's copyright assignment
here, which says that "Canonical will ordinarily make the Assigned
Contributions available to the public under a 'Free Software Licence,'"
but "may also, in its discretion, make the Assigned Contributions
available to the public under other license terms." I'm not aware of
any analogous text in the draft Harmony agreements.
Update 2: - From Brett Smith at FSF:
It is true that the agreement does ensure that whenever the FSF distributes the assigned software, recipients will have access to the source code and be able to distribute the software themselves. However, this means we're not limited to using GNU licenses: any
non-copyleft free software license would also meet these criteria.
Further from Brett Smith of FSF:
Our copyright assignment agreement gives the contributor unlimited nonexclusive rights, so they can do anything whatsoever with their code -- even use it in nonfree software. We do not ask contributors to make a commitment about how they will use their own code; they are
already doing us a favor by assigning it. We make such a commitment to them, but they don't make such a commitment to us. Our usual
assignment form that we provide to individuals accomplishes this by saying:
FSF agrees to grant back to Developer, and does hereby grant, non-exclusive, royalty-free and non-cancellable rights to use the
Works (i.e., Developer's changes and/or enhancements, not the Program that they enhance), as Developer sees fit....
The form you posted is a specialized one we use when a company wants to assign a limited, specified set of changes to us. In it, a similar
grant back appears in the second paragraph. The wording we use in individual assignments is more precise (and we'll be updating the specialized form now that we see that), but substantively they do the same thing: give contributors rights to use and distribute their own work any way they like.