What is contributoragreements.org?

contributoragreements.org offers new templates for contributor-friendly, multi-purpose contributor agreements. A contributor agreement is an agreement for the management of copyrights and patents when people cooperate in a common project they plan to release to the public. The main focus of contributor agreements is on creative work intended for publication, such as books or software. But the agreements can also be used for other types of collaborations, artwork, etc.

What are Contributor Agreements?

Contributor agreements are agreements between a Free and Open Source Software (FOSS) project and contributors to the project that set out what the project can do with the copyright of the contribution: code, translation, documentation, artwork, etc. The purpose of such agreements is to make the terms, under which contributions are made, explicit and thereby protect the project, the users of the project’s code or content, and often also the contributors themselves. Contributor agreements provide confidence that the guardian of a project’s output has the necessary rights over all contributions to allow for distribution of the product under either any license or any license that is compliant with specific principles. To put it in a nutshell, contributor agreements avoid as far as possible any future legal issues regarding the individual contributions, such as disputes over origin or ownership of respective rights.

What are “inbound” and “outbound” licenses?

Inbound licenses are the licenses you grant to a project entity, e.g., a foundation, company, publisher, or any other entity that manages the rights for your content, contribution or project. Contributor agreements or author’s contracts are popular examples for inbound licensing schemes.

Outbound licenses are the licenses provided to third parties, that regulate permissions granted to third party users. In the case of a typical FOSS project, there might be an “inbound” exclusive license clarifying the relationship between each contributor and the respective project as well as a corresponding “outbound” non-exclusive license in the form of a GPL license to regulate permissions granted to third party users.

Why not license contributions directly under the respective FOSS (outbound) license (“Inbound=Outbound-licensing-model”)?

Inbound=Outbound is often used to refer to the standard model of licensing in the FOSS ecosystem and the release of standardized contributor agreements does not intend to change that. It is widely recognized that contributions are most straightforwardly licensed under the applicable outbound license. This makes it easy for contributors to participate in projects without the burden to read, understand and sign additional agreements.

Contributor agreements are complementary to the standard Inbound=Outbound licensing model. They become especially relevant in case two companies want to collaborate on a FOSS project. They also become relevant in case a project with a large community of different contributors wants to have more flexibility in terms of the respective outbound licensing model, such as license change, and more possibilities in terms of enforcement. With the inbound=outbound licensing model, FOSS projects cannot change the outbound licensing model without consent of each individual developer but can only make upward compatible changes to the outbound license. The inbound=outbound licensing model also puts the burden of enforcement of license obligations on the shoulders of each individual developer.

Why not require contributions to be put in the public domain?

First, in many jurisdictions it isn’t actually clear whether it is legally possible to release works into the public domain while you are still alive and the copyright term has not yet expired. Second, even if a work is released in the public domain, the creator can be held liable for damages caused by their contributions. So unless you are dead and the copyright term has expired, releasing into the public domain turns out to be inferior to granting a similarly permissive license.

Releasing a contribution or any other work into the public domain means that it is not protected by intellectual property laws and can be used by anyone without permission. As a general rule, most works enter the public domain because of old age, but in some jurisdictions, there is also the possibility for the rightsholder to release the work into the public domain even before copyright period has expired. The CC0 project was launched to achieve this goal in the U.S. and to have at least a similar effect in most jurisdictions.

One of the consequences when releasing a work into the public domain is that there are absolutely no restrictions on the use. People who use the work don’t have to comply with any conditions or requirements nor do they have to give attribution to the original author. Missing attribution is of particular concern for most authors, contributors and projects, and especially in the context of FOSS projects or Open Content projects. Modifications can be created and published without referring to the original author(s). Copies or modifications of public domain works can also be licensed under proprietary licensing schemes, which can easily create conflicts with free, open source and open content initiatives.

Who uses contributor agreements?

Popular examples include:

Apache: http://www.apache.org/licenses/icla.txt

Ariba: http://aribaweb.org/AribaWeb_Contributor_Agreement.pdf

Debian Social Contract: http://www.debian.org/social_contract

Django: https://www.djangoproject.com/foundation/cla/

Fedora: https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement

FSF Assignment (GNU): http://ftp.xemacs.org/old-beta/FSF/assign.changes

FSFE (e.g. KDE): http://fsfe.org/activities/ftf/FLA.en.pdf

Google: http://code.google.com/legal/individual-cla-v1.0.html

Joomla!: http://developer.joomla.org/contributor-agreements.html

Linux Developer Certificate of Origin: http://elinux.org/Developer_Certificate_Of_Origin

Mambo: http://mambo-manual.org/download/attachments/5833166/mca.pdf?version=1

Mozilla: http://www.mozilla.org/hacking/committer/committers-agreement.pdf

Nokia (QT): http://www.kde.org/community/whatiskde/QtContributionLicenseAgreement-1-1.pdf

Novell: ftp://sdk.provo.novell.com/ndk/evolution/docs/copyright_form.pdf

OpenWebFoundation: http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owf-contributor-license-agreement-1-0—copyright-and-patent

Oracle: http://www.oracle.com/technetwork/oca-405177.pdf

Perl: http://www.perlfoundation.org/contributor_license_agreement

Twitter: https://dev.twitter.com/opensource/cla

SugarCRM: http://www.sugarforge.org/content/community/participate/contributor-agreement.php

Symbian Foundation: http://www.symlab.org/wiki/images/9/9e/Non-Member_Contribution_Agreement.pdf

RedHat: http://www.redhat.com/licenses/ccmpl.html

Zimbra: http://www.zimbra.com/license/contribution_agreement_2.0.html

What is the difference between copyright assignment agreements and contributor license agreement?

There are two categories of contributor agreements: copyright assignment agreements (CAA) and copyright license agreements (CLA). The CAA requires assignment and therefore a transfer of copyright to the project owner, whereas the CLA requires an irrevocable license to allow the project owner to use the contribution. While an assignment is typically used in the US context to give the project owner all necessary rights to sublicense and legally enforce the project, copyright law in some jurisdictions may not allow for an assignment of copyright but only for a license. To address this problem, CAA’s usually provide a fallback license agreement as an alternative method to ensure that in those jurisdictions sufficient rights are granted to the project to permit the use and distribution of each contribution in the same way as the CLA would permit.

The new contributor agreement templates are based on copyright license agreements only and offer the possibility to choose between an exclusive license and a non-exclusive. The exclusive license option gives the project (licensee) all necessary rights to grant sublicenses or transfer an unlimited number of licenses. Exclusive license agreements also empower the licensee to enforce copyright infringement, so that an absolute transfer of ownership allowed through assignments in some jurisdiction can be omitted. If you still wish to use an assignment, please consult with your lawyer.

What is the difference between an exclusive license agreement and a non-exclusive license agreement?

A non-exclusive license is the right to use something (content, code, artwork etc.) on a non-exclusive basis, meaning that the licensor can also grant a license to someone else to use the respective material. In short this means that the licensee is allowed to use the licensed material, but the licensor can also let others use the same material. For a contributor agreement, a non-exclusive license gives the receiving project the right to use the contribution, but makes clear that the contributor as the licensor remains free to exploit the same contribution and to allow any number of other licensees to also exploit the same contribution.

An exclusive license is an exclusive transfer of the economic rights in a copyright protected work and means that no other person or company can exploit the licensed rights, including the licensor himself. For a contributor agreement, an exclusive license means that only the receiving project is allowed to use the contribution. In order to also let the contributor exploit the respective rights, a contributor agreement structured as an exclusive license agreement includes a non-exclusive license back to the contributor.

What is a Patent Pledge?

A patent pledge is a promise not to sue any user, distributor or developer of technology based on specific and publicly identified patents.

The number of patent pledges and their different legal structures has grown over the past years, including prominent examples by IBM , Red Hat, and most recently Google. By using a patent pledge, ownership of the respective patent remains with the pledging or promising party but is subject to an enforceable pledge or promise governing how the owner or holder will or will not enforce the patent in the future.

Why use the Patent Pledge Option?

The patent pledge option is designed for contributors and especially contributing companies who are reluctant to use the broad patent license included in most contributor agreements currently available. Experience has shown that the commonly used worldwide, royalty-free, non-exclusive and irrevocable patent license applied to the contribution can easily create a burden for companies to collaborate and contribute to the FLOSS ecosystem. Quite often legal counsel and management will put an end to valuable contributions because of the “risk to loose control over their patents”. In order to address this concern, our contributor agreements offer the possibility to choose a patent pledge as an alternative to the traditional patent license.

The patent pledge option assures that the contributing party remains the owner of all patents potentially relevant for the contribution and keeps direct control over these patents while still allowing for the contribution to be used and distributed by anyone accepting the pledge. The pledge is subject to a defensive termination, meaning it will be withdrawn in case the pledging party gets sued first.

By offering the patent pledge option as an alternative mechanism to address patents in contributor agreements, we do not only intend to encourage more companies to collaborate and contribute to the FLOSS ecosystem, we also hope to generally encourage companies to consider innovative patent approaches and similar models that would reduce the number of lawsuits.

How to use a contributor agreement and where to get it?

Our agreement chooser provides a set of standardized contributor agreements, which can be tailored to accommodate specific needs by selecting different pre-defined options. Such standardized and widely understood agreements increase efficiency and significantly reduce transaction costs.

Alternatively, another way to obtain a contributor agreement is to instruct a lawyer to draft the respective agreement for your project. Such a customized agreement can be very expensive and will greatly increase costs to potential contributors.

What is the difference between a public license and a contributor agreement?

Public licenses such as Creative Commons or GNU General Public License are designed to regulate the external relationship between rightholders of content or software and their users. Typically, public licenses are drafted non-exclusively to accommodate the relationship between one or more rightholders and a variety of users.

Contributor agreements are complementary to the framework of public licenses: They provide a legal tool to regulate how content and software from different sources can be combined in the first place. Different from public licenses, contributor agreements regulate the internal relationship between content or software projects and developers or authors who want to contribute to that respective project. (Typically, but not necessarily, projects will use a public license to make content and software available to a variety of users).

How are the Contributor Agreements at contributoragreements.org different from other already existing contributor agreements, such as the Harmony Agreements available at harmonyagreements.org or the Fiduciary License Agreement offered by the Free Software Foundation Europe?

The next generation of standardized contributor agreements is based upon a detailed analysis of the Harmony Agreements and other already existing contributor agreements, but has incorporated additional research and further legal analysis of some of the most important questions concerning contributor agreements, such as the most suitable inbound licensing model and the appropriate patent licensing model. In this context, the next generation of standardized contributor agreements offers the possibility to chose a non-assertion patent pledge instead of the traditional and rather broad patent license included in most contributor agreements currently available. The agreements have been carefully revised and written in plain language.

In addition, the agreement chooser offers adopters to use an e-sign process, which can either be sent by E-Mail directly to their contributors or can be embedded in their project websites if needed.

How can I get help in evaluating and choosing the optimal inbound and outbound terms for my project?

If you have questions about the usage or different options to build your own contributor agreement, such as the different inbound and outbound licensing models offered through our agreement chooser, please consult with your lawyer. If you don’t have your own lawyer to get advice on legal questions, please contact the team at PeerPractice for assistance.

I like the contributoragreements.org project. How can I help?

Please contact us directly at team@contributoragreements.org if you wish to support our work. We always welcome your feedback.