Website contributor agreement california

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.

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.

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: