Guide to the Contributor Agreements

This guide is a complete walkthrough the Harmony contributor agreement templates and the options a FOSS project may choose when adopting them. The best way to read the guide is together with the combined agreement document with comments, which lists all the options together.

Quick Summary

The agreements start with an introduction to remind the contributor that the document is legally binding and should be considered carefully. Section 1 provides the defined terms used throughout the agreements. Section 2 provides for the "Inbound" transfer (either license or assignment) by which the contributor makes her contribution available to the project. This section also includes five options for how the project handles the "outbound" license of the contribution, and a separate, broader license for media (materials other than software). The inbound license options are generally very broad to enable the agreements to cover any of the licenses commonly used by FOSS projects as an "outbound" license, from BSD, to Apache, to GPL. Section 3 confirms that the contributor has both the necessary rights to make the transfer and that the transfer does not conflict with other rights that have been given to third parties. This section also includes a section which deals with "mixed contributions" which means contributions including works whose rights are owned by third parties. Finally, the agreements include two sections dealing with "disclaimers" of certain legal provisions (see the discussion of "Other Laws" in the Overview). A final section deals with a variety of legal issues which are common to contracts, such as choice of governing law and waivers of certain rights.

Detailed Walkthrough

Introduction

The introduction identifies the contributor (You) and the project (We) and ensures that the contributor understands that the individual or company is entering into a binding legal agreement. The assumption of all of the agreements is that the FOSS project is managed by an entity, whether it is an individual, foundation, non-profit corporation, or for profit corporation. This section also provides the opportunity for the project to establish the means by which the project will make the agreement legally effective. Projects may take different approaches to making the agreement effective; the most traditional, and most legally conservative, approach is to have signed agreements. However, projects may decide that they would prefer to employ digital signatures or conditional licenses and that choice is left open to the particular project. This section makes it clear that the agreement may apply to projects (like Apache) that manage more than one body of software.

Definitions

The definitions section is a critical part of the contributor agreements. Definitions simplify the agreements by making it possible to avoid repeating various descriptions in the rest of the text.

The definition of "Contribution" is the most important definition because it describes the nature of what is actually being either licensed or assigned to the project. This provision is based on definitions of "Contribution" in many common FOSS licenses. The definition is also based on ownership of the copyright in the work of authorship which can be text, media or code that is "Submitted". Contributors may submit works which include works of third parties. For example, contributors may submit patches in the form of the a branch of a revision control repository or a modified copy of the entire software. Such submissions include the base software whose copyright is probably not owned by the contributor of the patches. After considerable discussion, we decided to limit contribution to works of authorship in which the contributor owns the copyright in order to enable projects to determine how to deal with "mixed" submissions. Projects may take a variety of measures to determine whether or not third party code may be provided to the project: from a certificate of origin to a more elaborate procedure (see the procedure adopted by the Eclipse Foundation). The agreements outline that the project will determine their procedure for dealing with "mixed" submissions and provide a link to it in Section 3(d).

"Copyright" includes a general definition of copyright law as well as "neighboring rights." As noted in the Overview, copyright varies by country. Thus, an individual or a company does not own a "copyright," but rather owns rights arising under the (i) copyright law of the United States (in the United States), (ii) copyright law of France (in France) and (iii) copyright law of Germany (in Germany). Neighboring rights are those similar to copyrights, such as database rights, public lending rights, moral rights and performers rights. Most of these rights do not apply to software, but may apply to other works of authorship such as documentation, video, and images. Such rights are included in the agreements because they apply to both software and related works.

"Effective Date" ensures that Contributions are covered even if the Contributor Agreement is executed after the date of submission of the Contribution.

"Legal Entity" is based on the definition of "Legal Entity" found in FOSS licenses and includes the various forms of corporate entities; through Affiliates it includes other members of the corporate family. The definition of Affiliates includes parent companies, sister companies, and subsidiary companies. As noted in the definition of "You" these definitions are needed to deal with the complexities of the ownership of intellectual property rights within companies.

"Patent Claims" is based on the definition of patent claims found in FOSS licenses which provide patent licenses to users of the Contribution. We have included the definition in the alternative to cover the various manners in which patent claims are used in FOSS licenses. For corporations, we have defined Patent Claims to include patents owned by the corporate entity submitting the Contribution as well as other members of its corporate family (its Affiliates).

"Media" is all of the works of authorship which are not code. The most common types of works of authorship in this category are documentation, images and videos. We have separated out these types of works because most FOSS licenses are only designed to license software. In a significant number of cases, the licenses are too narrow to permit a project to use these works in the common ways, such as including the documentation in a wiki. Thus, the agreements give much broader rights for "outbound" licenses for media than they do for "outbound" licenses for software.

"Submission" is defined to include the work of authorship which is Submitted and which may include works whose copyright is owned by third parties. For example, contributors may submit patches in the form of the entire software program and such submissions include the base software program whose copyright is probably not owned by the contributor of the patches. After considerable discussion, we decided to limit Contribution to works of authorship in which the Contributor owns the copyright in order to enable project to determine how to deal with "mixed" submissions.

"Submitted" is based on definitions in many common FOSS licenses and defines the procedure by which a contributor communicates with a project in providing a Contribution, by any form of electronic, verbal, or written communication adopted by the project. It also provides that a contributor may mark a Submission to indicate that it is not a Contribution.

"Work" is the software that the project distributes to users. It does not include the Contribution (which is generally a modification or addition to the Work).

"You" describes in more detail who is making the Contribution. This definition is used most heavily in the Entity versions of the agreements, to ensure that Affiliates of a corporate contributor, who own or have the relevant intellectual property rights in the Contribution, are covered by the agreement. Many corporations have split up the ownership of their intellectual property in complicated ways to minimize taxes. Thus, the corporate entity which employs the individual who creates the Contribution may not own the intellectual property rights in the Contribution. For example, some large companies have all their intellectual property owned by a Swiss subsidiary even though the companies may otherwise do very little business in Switzerland.

Transfer Options: Copyright License

Section 2.1(a) merely clarifies that the copyright license version of the agreement means that the contributor retains ownership of the copyright and the patents which are the subjects of the license.

Section 2.1(b) is a very broad license from the contributor to the project under the relevant copyrights which includes all of the traditional copyright rights such as reproduction, distribution, modification, display and performance (we have not included "public performance" and "public display" because of potential differences in copyright laws in other countries). The license is perpetual and irrevocable. In addition, the license permits the project to sublicense these rights through multiple tiers of sublicensees, which means that the license permits the project to sublicense to its users and those users to in turn sublicense to their users. Although some open source licenses provide a "single" tier license such as GPLv2 and do not permit sublicensing, many other FOSS licenses expressly permit sublicensing. The license grant is "conditioned" on one of several options relating to the "outbound" license of the software (see the notes on Section 2.1(d)).

Section 2.1(c) provides a patent license that grants a license of sufficient scope to be compatible with the scope of the "outbound" patent license in many common FOSS licenses. For example, the patent license in Apache Software License 2.0 is different from the patent license in the Mozilla Public License, but the "inbound" Harmony patent license could be used with either.

Section 2.1(d) is a set of five mutually exclusive options around how the project handles the outbound license of the Contribution. The different options are provided to fit the most common variations in cultural values across FOSS projects. Options One through Four define a set of "outbound" licenses which are the only licenses the project may use when distributing the Contribution. These options also include the right to use future versions of the licenses, such as a move from GPLv2 to GPLv3. Option Five puts no restrictions on the project's choice of "outbound" license, but makes the Contribution available under the same license as the Work it was contributed to. Any of these options are appropriate for use with copyleft "outbound" licenses (such as the GPL) or permissive "outbound" licenses (such as the BSD). The "outbound" licenses specified by each option are the following (where "original licenses" means the license(s) that the Work was released under when the Contribution was Submitted):

Option One: The original licenses
Option Two: The original licenses and any additional licenses listed.
Option Three: The original licenses and any additional licenses approved by the Open Source Initiative.
Option Four: The original licenses and any additional licenses recommended by the Free Software Foundation.
Option Five: Any license, with the promise back that the contribution will also be licensed under the original licenses.

Transfer Options: Copyright Assignment

Section 2.1(a) provides for a worldwide assignment of copyrights. In some jurisdictions, copyrights may not be assigned. Sections 2.1(b) and 2.1(c) provide a license an agreement not to assert as alternative methods of ensuring that in those jurisdictions sufficient rights are granted to the project to permit them to distribute the Contribution. The assignment, license, and agreement not to assert are "conditioned" on one of several options relating to the "outbound" license of the software (see the notes on Section 2.1(f)).

At the same time as the assignment, Section 2.1(d) provides an immediate very broad license back to the contributor, to enable the contributor to use the contribution for any purpose. This license back to the contributor has the same scope as the license from the contributor to the project in the copyright license version of the agreement.

Section 2.1(e) provides a patent license of the same scope as in the copyright license version of the agreement. The patent license grants a license of sufficient scope to be compatible with the scope of the "outbound" patent license in many common FOSS licenses. For example, the patent license in Apache Software License 2.0 is different from the patent license in the Mozilla Public License, but the inbound Harmony patent license could be used with either.

Section 2.1(f) is a set of five mutually exclusive options around how the project handles the outbound license of the Contribution (the options are identical to those in the copyright license version). The different options are provided to fit the most common variations in cultural values across FOSS projects. Options One through Four define a set of outbound licenses which are the only licenses the project may use when distributing the Contribution. These options also include the right to use future versions of the licenses, such as a move from GPLv2 to GPLv3. Option Five puts no restrictions on the project's choice of outbound license, but promises to make the Contribution available under the same license as the Work it was contributed to. Any of these options are appropriate for use with copyleft outbound licenses (such as the GPL) or permissive outbound licenses (such as the BSD). The outbound licenses specified by each option are the following (where "original licenses" means the license(s) that the Work was released under when the Contribution was Submitted):

Option One: The original licenses
Option Two: The original licenses and any additional licenses listed.
Option Three: The original licenses and any additional licenses approved by the Open Source Initiative.
Option Four: The original licenses and any additional licenses recommended by the Free Software Foundation.
Option Five: Any license, with the promise back that the contribution will also be licensed under the original licenses.

Transfer Options: Common

Section 2.1(g) is optional, and provides an extended set of outbound licenses for Media beyond those listed in the other Section 2.1 options. In many cases documentation may need to be licensed under broader terms than are permitted by software licenses. We expect that in many cases these additional licenses will be Creative Commons licenses which are more appropriate for documentation, images, video and other Media contributions.

Section 2.2 waives moral rights. Moral rights are those rights which permit an author of a copyrightable work to control the modification of the work or his name associated with the work. Many countries have limited or eliminated these rights in the case of software, but the Harmony agreements also include licenses to Media which may be subject to moral rights.

Section 2.3 makes clear that the project is not required to use a contribution simply because it has been submitted.

Section 2.4 deals with certain cases which provide that licenses may be "implied" unless this type of provision is included.

Agreement

Section 3 provides standard legal promises to ensure that the contributor has the appropriate rights to provide the transfers in Section 2. These promises are in three parts:

Section 3(a) confirms that the contributor has legal authority to enter into the agreement. For individuals, this promise is a reminder to employees who may need approval of their employers and minors who may need approval of guardians or parents. In addition, corporations generally have a limited number of individuals who can bind the corporation.
Section 3(b) confirms that the individual or entity has the rights needed to provide the transfers. This issue is particularly important for corporations that may have the intellectual property rights divided among different entities for tax purposes.
Section 3(c) provides that the transfer obligations in Section 2 do not violate any other agreements. This issue is particularly important for employees of corporations who, if they have developed the contribution during their employment, may not have the rights to grant the transfers in Section 2.

Section 3.4(d) provides the project with an opportunity to deal with the issues of submitted software with copyright owned by third parties. As noted above and after considerable discussion, we decided to limit Contribution to works of authorship in which the contributor owns the copyright in order to enable projects to determine how to deal with "mixed" submissions. Projects may take a variety of measures to determine whether or not third party code may be provided to the project: from a certificate of origin to a more elaborate procedure (see the procedure adopted by the Eclipse Foundation).

Disclaimer of Certain Implied Warranties

Section 4 disclaims the "implied" provisions found in Section 2 and certain other consumer protection statutes which impose obligations. As noted, local laws such as Article 2 (see the Overview) may imply certain warranties into all software licenses unless properly disclaimed. Article 2 requires that the disclaimer of the warranties of merchantability and fitness for this particular purpose must be "conspicuous" with disclaimers in bold, capitalized or in different colors. Given the variety of text forms that are used in software licenses, we have included these disclaimers in capital letters. The requirements for disclaiming the warranty of non-infringement are not clear, but a disclaimer in capital letters will disclaim this particular warranty. In the assignment version of the agreement, the disclaimer is also from the project to the contributor because of the license back to the contribution in Section 2.1(d).

Waiver of Certain Types of Damages

Section 5 eliminates the potential liability for consequential damages (lost profits) which would otherwise be available under Article 2. Section 2-719(3) permits parties to limit or exclude consequential damages unless doing so would be unconscionable. In the assignment version of the agreement, the waiver is also from the project to the contributor because of the license back to the contribution in Section 2.1(d).

Miscellaneous

Section 6.1 provides for the choice of law. All contracts are governed by a particular law and the same words may be interpreted differently in different jurisdictions. If a contract does not include a choice of governing law, the first issue in any dispute will be determining the applicable law. The selection of the governing law is determined by a body of law known as conflict of laws. This area of law can produce different outcomes for the same set of facts if the contributor and project are in different jurisdictions. After significant discussion, we decided that it was better for FOSS projects to have predictability in interpretation of the terms of the contributor agreement. In addition, the term disclaims a treaty, the United Nations Convention on the International Sale of Goods ("UNCISG"), which is similar to the UCC and would apply automatically to the contributor agreement if the parties are in different countries which are each members of the UNCISG. UNCISG has rarely been used and is an unpredictable combination of civil law and common law, and thus would lead to further ambiguity about the interpretation of the terms of the contributor agreement.

Section 6.2 deals with other standard issues. The first sentence is an "integration" provision which ensures that the terms of the agreement are only those stated in the contributor agreement and excludes all other discussions or other agreements prior to the contributor agreement. The second sentence permits the agreement to be assigned either by the Project or by the contributor but any assignment is conditioned on the assignee agreeing to the terms of the contributor agreement. This provision was the subject to significant discussion, but we believe that this flexibility is very important for Projects. Such permission is required for non exclusive copyright licenses under United States law. Since Projects may change entities or otherwise need this flexibility in the future, we have protected the expectation of the contributors by requiring that the assignee agree to the terms. The third sentence ensures that a single "waiver" of the rights of a party does not imply a future violation of the same provision. For example, if a project had promised to only use the GPLv2 as an "outbound license," the project uses the Apache Software License and a contributor does not complain about this violation over a period of time, the contributor might be deemed to have waived that change. This provision ensures that such a waiver would not occur. The fourth sentence provides that if a court finds a provision of the agreement to be unenforceable under the relevant laws, the court will replace the unenforceable provision with a provision that comes the closest to the intentions of the original provision. The final sentence deals with Article 2 provisions that have occasionally been used to not enforce a consequential damages waiver under Sections 2-719(2) and (3). We are trying to ensure that it is as clear as possible that it is the intention of the parties to prohibit the application of this doctrine to set aside the limitations on remedies, including the waiver of consequential damages.