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.
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.
The FLA recommended by FSFE refers to the Fiduciary License Agreement, which was originally drafted by FSFE with support from a team of international experts to provide a well-balanced contributor agreement. Since the release of the first version in 2002, the world of IT has changed and FSFE has joined forces with the team behind contributoragreements.org to review and update the FLA and integrate the agreement in the agreement chooser. The revised agreement chooser now offers a direct way to generate the FLA, which is based on the exclusive copyright license option and the traditional patent license option. The FLA also includes a few additional options to be selected through the license chooser, such as different outbound licensing paths. Alternatively, the agreement chooser still offers to create your own contributor agreement, specifically tailored to your own needs.
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.
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.
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.
Popular examples include:
Debian Social Contract: http://www.debian.org/social_contract
FSFE (e.g. KDE): contributoragreements.org
Linux Developer Certificate of Origin: http://elinux.org/Developer_Certificate_Of_Origin
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.
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.
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.
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.
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.
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).
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 PeerPracticefor assistance.
A short introduction to the general concept of intellectual property can be found here. As one of the specialized agencies of the United Nations, the World Intellectual Property Organization provides detailed information about intellectual property and relevant international treaties on their website. The World Trade Organization has published materials on Trade Related Aspects of Intellectual Property. At the same time, the term “intellectual property” has also been criticized.
A summary of EU legislation in intellectual property and related policy can be found here and a comprehensive overview of the U.S. perspective on intellectual property law is available via Duke Law School at the Goodson Law Library.
Free and Open Source Software
The definition of Free Software can be found at the Free Software Foundation and the definition of Open Source Software can be found at the Open Source Initiative. The Institute for Legal Questions on Free and Open Source Software (ifrOSS) provides a nice overview of various different free and open source licenses. They have also published a comprehensive set of FAQ. Relevant news and interesting articles on free and open source software can be found at http://www.groklaw.net/index.php, http://www.linuxquestions.org/,
A quick look into history on Case Law dealing with software patents can be found at