Overview

Project Harmony is a collaborative effort to develop a series of template contributor agreements for use by the free and open source software ("FOSS") community. These templates reflect options for FOSS projects that wish to employ contributor agreements. The development of these contributor agreements does not suggest that all FOSS projects should use contributor agreements: many very successful FOSS projects such as Linux and Mozilla do not use contributor agreements. However, other FOSS projects, such as Apache and Eclipse have chosen to use contributor agreements. For those projects that chose to use contribution agreements, they (and the community) will benefit by having a limited number of well understood contributor agreements; over time such contributor agreements achieve a recognized level of acceptance across the community.

If a FOSS project wishes to employ a contributor agreement, it has a limited set of options because most of the existing contributor agreements are very tightly tied to the particular project for which they were developed. These contributor agreements may need to have significant changes to work with projects that use different licenses (for example, a contributor agreement for a GPL licensed project may have different needs than one for an Apache licensed project).

The goal of Project Harmony is to provide a toolset for FOSS projects that have decided to use contributor agreements. The template agreements include several options that cover the most common variations between projects. Where these options aren't sufficient, projects can also modify the template contributor agreements for their particular needs (for more on the conditions on modifications, see our policy page), though we recommend using the standard forms of the templates where possible.

As a FOSS project considers whether or not to use a contributor agreement, it should consider the following factors:

The culture of the project.
The procedure for screening incoming code to ensure that it meets the legal requirements of the project: these issues include ensuring that the contributor has the necessary rights to make contributions. For example, employed contributors need to obtain necessary waivers of their employers, and contributors who are minors need to obtain the required approvals by their parents or guardians to make the agreement enforceable.
The potential need to change the "outbound" license of the project. This flexibility will be important to many FOSS projects. The experience of the Eclipse Foundation is instructive: the Eclipse Foundation commenced the shift from the Common Public License (controlled by IBM) to the Eclipse Public License (very similar, but controlled by the Eclipse Foundation) in 2004, but six years later some projects remain under the original Common Public License. A more recent example is the attempt by the Open Street Map Project to change from a Creative Commons license (which most contributors to the Open Street Map Project voted to replace and most commentators believe is poorly designed for the complexities of licensing databases) to a specifically drafted Open Database License. The new license was approved in December 2009, but in 2011 a number of major contributors have not yet shifted to the new license. The Open Street Map Project is using the OpenStreetMap Contributor Terms for new contributions, but has not been able to shift the project as a whole to the Open Database License.
The need to coordinate enforcement of the rights of the project in the face of some harmful action against the project.
The potential demands by users of the FOSS project for the use of contributor agreements.
The reduction in legal review by contributors to multiple projects.
The need for broader rights in documentation and materials than the rights to software that are provided by existing free and open source software licenses, such as the Apache license and the GPL. These licenses are generally focused on the distribution of software and may not permit the use of documentation in wikis and other venues.
The need to provide greater certainty about the consequences of death of an individual contributor or the bankruptcy of a contributor.
The ability of the FOSS project to manage the administrative overhead of using contributor agreements.

Contributor agreements are contracts which must operate within the bounds of intellectual property laws and other laws which affect the licensing of software and other media related to software. Project Harmony was guided in drafting the agreements by two factors: (i) the norms of FOSS communities and (ii) the terms of the "downstream" licenses common to FOSS projects. The major intellectual property regimes which form the basis of these licenses are copyrights and patents. These intellectual property rights vary by country and, thus, an individual or a company does not own a "copyright," but rather has rights arising under the copyright law of the United States (in the United States), copyright law of France (in France) and copyright law of Germany (in Germany). In addition, these agreements are affected by certain other laws which provide an overlay on the intellectual property rights for licensing software. In the United States, software is considered a "good" which is governed by Article 2 of the Uniform Commercial Code ("UCC"). Both intellectual property laws and those other laws (similar to the UCC) are national in nature and vary by country. The initial drafts of the agreements are based on United States law, but Project Harmony intends to "internationalize" the agreements. Legal counsel from many major international jurisdictions have participated in the drafting, and further international perspectives will be sought during the public review period.

The major intellectual property laws and other laws in the United States form the framework for the contributor agreements. Just as in software development, legal agreements must follow certain rules.

Copyrights. Copyrights protect "original" works of authorship which are "fixed" in a tangible medium of expression. The standard for originality is very low. Copyrights cover manuals, firmware and computer software, as well as more traditional works such as songs, novels, images and motion pictures. Unlike patents, copyrights arise automatically when a work is created and do not require an application to the government (however, a United States company needs to "register" the copyright prior to bringing a court action for infringement). Although the term of copyright has varied over time and varies by country, currently a copyright in the United States developed by a company endures for the longer of ninety-five years after the date of first publication or one hundred and twenty years after creation (copyrights created by individuals have a different term). Copyright law gives the owner the exclusive right to reproduce, distribute, modify, publicly perform and publicly display the work. However, unlike a patent, a copyright does not protect the idea behind a work. Thus, while a patent may protect a method of creating a multi-threaded computer operating system, copyright law would permit multiple implementations of that idea so long as a company's implementation is not "substantially similar" to the implementation of another company.
Patents. Patents protect inventions which are new, useful and non-obvious (when we discuss patents, we will be referring to "utility" patents; other types of patents, design patents and plant patents are generally not applied to software). Such inventions can be electrical or a business process (few other countries permit patents covering software). Examples of inventions protected by utility patents are a method of running cash management accounts, and a method for curing rubber. The usefulness requirement is generally easy to meet, but the requirements of novelty and non-obviousness require that the invention must not have been known or used by others in any country before the applicant invented it. The owner of the invention must apply to the government agency in each jurisdiction in which protection is sought (in the United States, the agency is the Patent and Trademark Office) and comply with such jurisdiction's legal criteria. The patent prosecution process is an "adversarial" one in which the inventor needs to persuade the appropriate agency that the patent application meets the legal criteria. Currently, a patent in the United States has a term of 20 years from the filing date but the term may be extended under certain conditions (in the past the term was different). Patents permit the owner to "exclude" others from making, using, selling, offering for sale, and importing a product or service embodying the invention. The fact that a patent is a "negative" right is very important because it means that obtaining a patent does not give a person the right to sell a product or provide a service: many products and services are covered by the claims of multiple patents owned by different parties. Patents are generally viewed as the strongest form of intellectual property because they can prevent a competitor most effectively from making or distributing their product.
Other Laws. Many countries have laws that govern the sale of goods between various parties and these laws often apply to software transactions. In the United States, these laws are adopted by the states (as opposed to the U.S. government which is the source of laws on copyrights and patents), but are very similar in forty-nine of the fifty states because these states have adopted a standard law called the "Uniform Commercial Code." Courts have found that software is "goods" for the purposes of interpreting software contracts and, thus, are governed by Article 2 of the UCC (one limited exception to this approach in some cases is contracts dealing solely with developing software). Article 2 encourages freedom of contract but includes "implied" provisions in a software license unless they are properly "disclaimed" and certain "gap filling provisions" (essentially, "default provisions") which are "inserted" in the software license if a software license does not deal with the relevant issue. For example, Article 2 implies certain warranties from the software licensor (unless expressly disclaimed): warranty of non-infringement of third party intellectual property rights provides a warranty of merchantability, which means "average quality" in the software industry (this warranty is limited to licensors which deal regularly in software), and the warranty of fitness for particular purpose.

Most of these warranties are of uncertain scope in relation to software and virtually all software licensors disclaim (i.e. delete) these implied warranties. Article 2 requires that the disclaimer of the warranties of merchantability and fitness for a particular purpose meet certain requirements to be effective under Article 2: the disclaimers must be "conspicuous" which means that they must be in bold, capitalized or in different colors. Given the variety of text forms that are used in software licenses most software companies prefer to put these disclaimers in capital letters.

In addition, Article 2 provides certain remedies as defaults which may not be desirable for licensors. Article 2 provides that, unless disclaimed, a breach of license can result in the award of "consequential damages": such damages include lost profits which could greatly exceed the amount paid for the software. For example, one legal claim involved construction planning software which sold for $10,000, misestimated the cost of the building and resulted in losses of over $1,000,000. If the court had awarded consequential damages, the amount would have been $1,000,000. Consequently, virtually all software licensors "disclaim" the remedy of consequential damages.

Another important legal issue is the ownership of intellectual property rights. Once again, this issue depends on national law. However, the legal framework for employees is similar in most countries: the copyrights are owned by the developer, but, if working full time for an employer, most countries provide for ownership of copyright to vest immediately in the employer. The situation with relation to patents is more complicated. The rules of determining who is an employee are clear in most cases, but may extend to individuals who consider themselves contractors. Software developed as part of one's job or by using company resources will frequently be considered to be owned by the employer. These rights can be broadened or narrowed by contract. Consequently, the employee may not have the right to contribute software developed during his or her work for his or her employer.

In considering the adoption of a contributor agreement, FOSS projects should consider the following potential advantages:

Both the copyright license and copyright assignment forms of the contributor agreements include options to permit adoption of a different license for a project without seeking permission of each contributor.
Both types of contributor agreements deal expressly with potential problems arising from contributions by employees (ensuring that employers have agreed to the transfer) and minors (ensuring that appropriate approval is received from parents or guardians). Please note, that these issues can also be managed through appropriate intake procedures.
Both types of contributor agreements deal with the complexity of corporate contributions (such as including rights from Affiliates). A significant number of the licenses commonly used by FOSS projects do not address this issue.
Both types of contributor agreements provide for a patent license which a significant number of FOSS licenses do not address because the licenses were written prior to the application of patents to software.
The assignment form of the contributor agreement has the following additional considerations:

Consistency in Enforcement. If the project is the owner of the copyright in the software, the project will be able to ensure consistent enforcement. If the project does not own the copyright in a contribution, the individual contributors will remain the owner of the copyrights in their contributions and will be able to work together to enforce the license for the entire project. This split ownership can lead to different approaches by different owners of the copyright for the same use of the same software. For example, some of the copyright owners of the BusyBox project have enforced the terms of the GPLv2 and as part of settlements, have added conditions not found in the GPLv2. These terms are relatively modest and primarily administrative, such as the appointments of an Open Source Compliance Officer. However, at least one other contributor to the BusyBox project, Bruce Perens, has suggested that he believes that such conditions are inappropriate.
Avoid Problems Arising Due to the Death of the Contributor. The law relating to copyright licenses after the death of the author is complicated and varies by country. The copyright will be transferred to heirs and licenses may be affected.
Avoid Problems Due to Bankruptcy of the Contributor. The law relating to licenses in bankruptcy is complicated and varies by country. Under United States law, a license which is "executory" may be terminated by the licensor after bankruptcy, but Section 365(n) has changed the rules in the United States to permit the licensee to keep its rights under certain circumstances. However Section 365(n) does not apply to patents and copyrights outside of the United States. Bankruptcy laws are also national laws and vary from country to country. It is difficult to predict how a license would be interpreted in different countries.

The decision to use a contributor agreement also has potential disadvantages:

The use of contributor agreements requires administrative resources and the project may not have the resources to obtain them.
The culture of the project may be inconsistent with the use of contributor agreements.