Contributor Agreements

Contributor Agreements

Why do contributors contribute? There are certainly as many answers to that question as there are contributors. But one thing is certain: People contribute to open source projects whose goals they share. There is usually camaraderie among project members , whether the project is structured as a loose confederation, a formal nonprofit corporation, or a corporate-sponsored activity. When camaraderie fails ”for either technical or personal reasons ”projects may fork into rival projects. Open source contributors are free to join either fork or leave altogether. Such forks, by the way, have proven to be very rare in open source projects.

Contributors may leave a project but their contributions remain . Once software is made available to a project under an open source license, the project may continue to copy the software, create derivative works from it, and distribute it even after the contributor's participation ends. That is because open source licenses are perpetual , even though most licenses don't expressly say so. As long as the project continues to honor the terms of the licenses under which it received contributions, the licenses continue in effect. There is one important caveat: Even a perpetual license can be revoked . See the discussion of bare licenses and contracts in Chapter 4.

For most projects, receiving contributions under an appropriate open source license from the contributor provides more than enough authority to do what they need to incorporate the contribution into the project's software. That, after all, is what the Open Source Principles stand for.

As long as each contributor's license is compatible with the project's open source license used for its distributions, then the contributor/distributor food chain evolves as I described in the previous section. This is always the case when identical licenses are used for contributions and for the project's derivative works. For example, if a project accepts contributions under the BSD license, it can then license derivative works under the BSD license; if it accepts contributions under the GPL, it can then license derivative works under the GPL.

But compatibility encompasses much more than simply identical licenses. A contributor license for his contribution is compatible with a project license for its collective or derivative work if the contributor's license contains no terms or conditions that would conflict with the terms and conditions of the project's license. Determining whether two licenses have conflicting terms and conditions requires a provision by provision comparison of the two licenses.

That comparison must be analyzed separately in each direction. For example, as I shall describe later, a contributor license like the BSD license is compatible with the other project licenses in this book, including the GPL, but the converse is not true; contributions licensed under GPL cannot be used in BSD-licensed projects. Incompatibility may exist in both directions; GPL-licensed contributions cannot be used by the Apache project and Apache-licensed contributions cannot be used by GPL projects. I will have much more to say about license compatibility in Chapter 10.

What happens if a project decides that it wants to use a contribution in a way that is incompatible with the terms of the contributor's license? The answer is obvious: The project is bound by the terms of the licenses under which it receives contributions. In general, if the contributor's license is incompatible with the project's open source license, then the project cannot use the contribution.

Open source projects are usually not the owners of the copyrights in the contributions to them, and they have no right to change those licensing terms on their own. Sometimes, to ensure that they have freedom to choose licensing terms, open source projects seek to own the copyrights in contributions made to them, or to enter into written agreement with contributors that expressly allows the projects to decide license terms for contributions. These contributor agreements take the form of copyright and patent assignments that actually transfer ownership of the intellectual property, or broad license grants much more comprehensive than the open source licenses in this book. License compatibility is not an issue for projects that are copyright and patent owners , because the contributors no longer have any right to refuse the projects' licensing decisions for contributions the contributors no longer own.

What happens, then, if an open source project faces an actual relicensing decision but it doesn't own the copyrights and patents in its contributions? For compatible relicensing, no additional license is necessary. But it must obtain the agreement of the contributors to any relicensing that is incompatible with the terms of the license it received from its contributors.

Who should have the right to make future licensing decisions about contributions, the project or the contributor? There is no single answer to this question in the open source community. In fields other than software, this issue has long been a fruitful source of litigation. Musicians and artists have often fought against their own publishers, to whom they once willingly assigned their copyrights, trying to regain those valuable rights for other markets. In recent years , contributors to newspaper articles fought against their own publishers for the rights to republish their articles in new online forums. These cases often turn on the interpretation of contributor agreements. Of course, had they been handled as copyright or patent assignments, no rights would remain and the musicians, artists, and newspaper writers would have been without recourse regardless of what decisions their publishers made.

I personally don't want to give up too much control to my publisher. When the words are mine, I want to own them. I will license them to everyone under an appropriate open source license, but I will not give them away to someone else who can then elect to take them private or license them in ways of which I don't approve. This is true no matter how much I like my publisher, and no matter how much I want to save my publisher from having to worry about future relicensing problems.

This is obviously just my own opinion about an issue of copyright policy. Each contributor of intellectual property to a project or to a publisher must decide for himself how many rights ”and therefore how much control ”to give away. Beyond this I will not advise and will merely proceed to explain the various kinds of open source licenses that projects adopt. If you intend to contribute to an open source project and it presents you with a contributor agreement different from an open source license, make sure you read it carefully and consult an attorney if you are unsure what you're being asked to give away.