Alphabet CLA Policy and Rationale

This document does not provide legal advice, and represents the views solely of the Google Open Source Program Office. Please consult with your own lawyer for legal advice.

Introduction

It is common for technology companies to use code owned by external parties. Third-party code can even be incorporated into core components of a company’s products. But while third-party code can be a tremendous resource, using it carries great responsibility.

This document spells out corporate best practices for accepting code contributed by third parties and explains the basis for these practices in agency law. These best practices consist of three components: an Apache-type Contributor License Agreement (CLA), a procedure for accepting CLA signatures, and a procedure for accepting code submitted under the agreement.

This document will summarize the legal framework applying to code ownership, laying out the rationale for employing an Apache-type CLA, and will then discuss the specific laws and risks related to each part of the CLA signing and code acceptance process.

Overview

Under international copyright law, copyright attaches automatically in the creation of creative works, such as software.¹ The moment that a work of sufficiently original software is fixed in a tangible medium, it is protected by copyright. Domestic copyright laws often place copyright ownership in the hands of a creator's employer.² Code submitted by external employees may also exercise that company’s patents. When a programmer submits code to a company, that code may be owned by the programmer’s employer. To ensure that a company is granted the permissions necessary to utilize the code it receives, Contributor License Agreements (CLAs) should generally be obtained from every organization whose employees contribute code. The language of the Apache CLA, and the best practices for accepting CLAs, serve two interrelated aims: First, to ensure that the company is granted permission to use the code. Second, to ensure that the CLA effectively binds the signee’s organization.

CLA Terms

The language of the Apache CLA protects companies by clarifying the ownership of and permissions to the intellectual property being created and used.³

Section 2 of the agreement grants the receiving company a “perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license” to the organization’s contributions. The “no-charge, royalty-free” language permits the receiving company to use the code without incurring expense. The “non-exclusive” language reserves the contributing organization freedom to use the code themselves, or to license the code to others under different terms.

Section 3 spells out patent license terms, granting the receiving company and downstream users a perpetual license to any patents implicated by the contributed software, subject to certain conditions such as a license-termination mechanism.⁴

Sections 4 and 8 require the signee to certify that they wield the requisite authority to enter into the CLA on behalf of their organization. These clauses alert the signee that proper authority is required to enter into the agreement on behalf of their organization. It also places the responsibility on the signee to ensure that such authority is secured.

CLA Acceptance Procedure

In addition to the terms of the CLA itself, an effective CLA acceptance procedure consists of three protective measures to ensure that the CLA binds the signee's organization.

First, authentication, such as email verification through a document signing service, should be used to verify the identity of the signee. This provides assurance that the signee is a real person and a representative of the contracting organization.

Second, signees’ professional titles should be reviewed, and submissions should be rejected if the signee's title is not one that generally confers authority to contract on behalf of an organization. This is done to ensure that the company’s reliance on the authority of these signees is reasonable.⁵

Third, all employees of the contributing organization should be individually appointed to contribute under the agreement by an established point of contact before making contributions. Funnelling all contributors from a given organization through a single point of contact prevents contributions from being made without the contributing organization’s knowledge, and prevents misunderstanding.

Discussion

This discussion will first delve into the legal and operational considerations underpinning the language of the Apache CLA, then lay out best practices for CLA submission and code contribution acceptance procedures with an eye to the particular fact patterns that create risk for receiving companies.

CLA

Standard inbound license

Using one standard inbound license that grants the receiving company broad permission to use contributed code in products is beneficial to the company and downstream users alike.

Technology companies will naturally want to make productive use of any code made available to them. However, if all of the code being received by a company was subject to various inbound licenses with conflicting terms, the process for authorizing the use of the code would be cumbersome because of the need for constant checks for compliance with the various licenses. Whenever contributed code were to be used, the particular license terms for every single file would need to be reviewed to ascertain whether the application would be permitted under the terms of that code’s specific license.⁶ This would require considerable human resources and would slow down the engineers trying to utilize the code.

The benefits that a company receives under a standard inbound license pass to downstream users as well. Explicit patent permissions and disclaimers of obligations and warranties clarify the recipients’ rights and duties. The broad grant of rights provides code recipients opportunities to make productive use of the software. Adherence to a single standard license promotes consistency and common understanding for all parties involved.

Grant of patent license

Section 3 of the Apache CLA operates to clarify that the agreement controls all aspects of the intellectual property interest in the software. Having patent license terms clearly and explicitly stated protects all parties’ interests.

Origin of works

Sections 5 and 7 require the signee to represent that all contributions under the agreement are the “original creations” of the contributing organization. This is done to protect the receiving company (and downstream users), because the CLA may not shield recipients from claims by owners of code that is submitted to them by a third party. Requiring CLA signatories to certify that their code contributions are their original creations - hence copyrighted works that they actually own - gives recipients some recourse against those signatories if their contributed code turns out to have been improperly obtained from a third party.

Individual CLA

For circumstances where the code being contributed is not done within the scope of the contributor’s employment,⁷ the contributor should be required to sign a CLA in their individual capacity to ensure that a license is granted to the code that the contributor owns as an individual.

Procedure

Signatures

The intricacies of copyright ownership are not always obvious to those who are creating and exploiting copyrighted works. This introduces risk to code creators and users when they enter into agreements governing the use of code. The consequences of using code without proper authorization, or for accidentally giving away code, can be ruinous.

Code contribution agreements are also typically signed digitally, and remotely, which introduces convenience at the expense of risk.

This section will highlight the particular fact patterns that could pose risks to a company employing a CLA to receive code contributions, and will then detail the legal framework underpinning the largest of those risks: unauthorized signees.

Fraudulent signee

To illustrate what a fraudulent CLA submission might look like, imagine that an engineer named Alice contacts B Corp to say that she represents A Corp and wants to sign B Corp’s CLA on A Corp’s behalf. Alice signs the CLA and proceeds with submitting code to B Corp. B Corp proceeds with using that code in products across the company. It is later discovered that the code Alice submitted wasn’t actually owned by either Alice or A Corp - in fact, Alice doesn’t even work for A Corp and her name isn’t actually Alice. B Corp just recklessly incorporated and utilized code that belongs to a completely unrelated third party, and now that third party may have a cause of action against B Corp. This fact pattern demonstrates the value of authentication (such as email verification), as it ensures that the people signing a CLA are who they say they are.

Unauthorized signee

An unauthorized signee could be an engineer employed by an organization signing a CLA on the organization's behalf, where the engineer is confused about the need for special authority to execute the agreement. Suppose the engineer proceeds with signing the agreement and contributes code, but then the organization discovers this errant engineer's actions and revokes the agreement. This would likely require that the receiving company isolate and remove all of the code contributed by the engineer (and by other employees of the organization), which could be damaging to both the maintainers and users of the project. This unauthorized signee scenario is a realistic fact pattern in the world of code collaboration and presents a risk to technology companies. This is why measures should be taken to ensure that CLA signees are authorized.

Corporate signing authority

Under American corporate law, officers of a company generally only have authority to enter into contractual agreements on behalf of the company if the company's board of directors explicitly bestows such permission.⁸ Traditionally, "C-level" executives like CEOs or CTOs are expressly granted a degree of signing authority in the company’s bylaws, but there could be a narrower or broader designation of authority as the board sees fit.

This raises the obvious concern that, without reviewing every contributor’s company bylaws to determine whether a given officer has been granted signing authority, a company might be authorizing CLAs that are unenforceable against contributors. Here, Section 4 of the Apache CLA again operates to protect the contracting parties from surprise by requiring that the signee certify their authority to enter into the agreement on behalf of the company.

However, while Section 4 does place responsibility on the signee, it is likely insufficient protection should the receiving company accept this assertion from a signee whose title belies authority to grant the company a perpetual license to code owned by the signee’s employer. A court might view the receiving company’s acceptance of that CLA as unreasonable reliance upon the authority of the signee.⁹

Fortunately, agency law provides a framework for confidently accepting CLA submissions without needing to implement a labor-intensive procedure to ensure that each agreement is effective by law.¹⁰ In California, these tenets are spelled out in the corporate code:

“Any contract or conveyance made in the name of a corporation which is [...] done within the scope of the authority, actual or apparent, conferred by the board or within the agency power of the officer executing it, [...] binds the corporation[.]”¹¹

This statute embodies a core principle in contract and agency law: when an agent holds actual or apparent authority to act on behalf of the agent’s principal, the principal is bound by the agent’s actions.

Actual authority

Actual authority applies to all cases where an officer acting on behalf of a company is taking an action with the company’s knowledge and consent.¹² A company should naturally desire that all of its contractual agreements are entered into with actual authority. If an agent represents themselves to speak for an organization and enters into an agreement contrary to the organization's interests, it invites conflict that can harm both parties to the contract.

However, ascertaining actual authority rests upon facts that are outside the scope of what a receiving company may reasonably observe or control.¹³

Apparent authority

Apparent authority covers situations where someone transacting with an officer of a company relies on the officer’s authority to enter into that transaction based on the company’s representations signaling that the officer wields such authority.¹⁴ In other words, when a contracting party reasonably relies on the authority of an agent of a corporation in order to bind that corporation in an agreement, that agreement remains valid against the corporation, even if the corporation did not actually authorize its agent to enter into the agreement.

The benefit of apparent authority is that it presents criteria that are within a receiving company’s means to control. For this reason, these best practices focus on ensuring that apparent authority is satisfied.

In order for a receiving company to ensure that its CLAs are legally enforceable under a theory of apparent authority, it should take care that its CLA acceptance procedure satisfies the two criteria for apparent authority: 1) the company must reasonably believe that the signee has authority, and 2) that belief must be traceable to the manifestations of the contracting party (the company or organization the signee is representing).¹⁵

The receiving company’s belief in the authority of the signee must be reasonable. This requirement shields the signatory corporation from being bound by the actions of a non-executive employee. Imagine that a C Parcel Services delivery driver is making a delivery at B Corp and a B Corp executive asks the driver sign a contract between B Corp and C Parcel Services for new shipping rates for B Corp deliveries worldwide. The agreement would likely be unenforceable against C Parcel Services, because it is likely unreasonable to rely on the authority of the delivery driver to bind C Parcel Services to such an agreement.

The belief should also be traceable to the manifestations of the signatory corporation in order to shield the signatory corporation from the fraudulent acts of third parties. If someone walked into B Corp headquarters purporting to be an attorney acting on behalf of C Parcel Services, offering new shipping rates for B Corp deliveries, and B Corp were to sign that agreement with the attorney, it would similarly be unenforceable if the attorney’s claim to represent C Parcel Services were not traceable to some manifestation on C Parcel Services’ part.

Determining whether a signee’s authority is reasonably relied-upon and traceable to manifestations of the company forms a very fact-and-context-dependent inquiry, but it is amenable to common-sense considerations as to whether a given agent wields the imprimatur of authority.

It is important to note that the corporation’s manifestation need neither be direct nor in writing; bestowing a given title on an individual will do.¹⁶ For this reason, a CLA acceptance procedure may rely heavily on consideration of the CLA signee’s title to ensure that the role is one that reasonably carries authority for the transaction and that this authority is conveyed by a manifestation of the contracting corporation. This is also why receiving companies should be careful to utilize authentication to ensure that this manifestation is directly traceable to the contracting corporation.

A statute from the California civil code spells out the overarching principle at work in the apparent authority determination, and it provides a helpful lens for evaluating whether apparent authority should be satisfied:

"Where one of two innocent persons must suffer by the act of a third, he, by whose negligence it happened, must be the sufferer."¹⁷

This dynamic formula can operate in one of two ways in the context of honoring contractual agreements. The first, relying on the notion that a principal must take care in appointing and monitoring its agents,¹⁸ would have the contract be enforceable against the party who did not exercise care in monitoring its apparently-authorized agent’s activity (signing the CLA and contributing code under it). The second application, turning on reasonable reliance, would make the contract unenforceable by the party who accepted an agreement signed by an employee that did not present evidence of authority to bind an entire company.¹⁹ This critical lever underscores the importance of considering the title of every CLA signee before accepting CLA submissions.

Additionally, this lever highlights the value of funneling all contributors from a given organization through a single, authorized contact. CLA signees, by requirement, should hold an office of authority at their organization, and should assume the responsibility of designating a Point of Contact for managing the code contribution relationship.²⁰ This shields the receiving company from arguments that a rogue engineer contributed code unaware of the CLA. Moreover, by funneling contributors through a point of contact at their own organization, it creates the opportunity for that organization to exercise reasonable care in apprising itself of the activities of its employees.

Multiple signatures

In addition to maintaining a single version of the CLA that is used for all contributors, another best practice for maintaining CLAs is to only accept a single CLA from a given contributing organization.

There are three reasons for this:

First, there could otherwise be a problem at the code contribution stage. If code were to be contributed by an engineer who was covered under multiple CLAs, an additional layer of review would be required to determine which CLA the code was subject to.²¹

Second, if the terms of the company’s CLA were ever to change, there could be confusion as to which terms were controlling if multiple CLAs with different terms were executed.

Third, accepting multiple CLAs from different officers at a given company could undermine the validity of all of the CLAs signed by that company. The receiving company would have trouble arguing that it reasonably relied upon the authority of a CLA signee if the company were to ignore evidence that the signee’s organization had multiple officers each declaring themselves to be the single designated authority at the organization responsible for managing the CLA relationship.

Code contribution procedure

Above, it was noted that copyright law often operates to place ownership of creative works in the hands of one’s employer, but that is not always the case. In this regard, ensuring that all contributors from a given organization are funneled through a responsible contact serves another important purpose. Suppose an engineer whose employer has signed B Corp’s CLA submits code to B Corp. But let’s say that the engineer had written that code before going to work for that employer. If this engineer has not signed the B Corp CLA in her individual capacity, and if she is not certifying that the code is being contributed as property of the engineer’s organization (by coordinating through the point of contact assigned to the agreement), then B Corp may not have a license to use that engineer’s code. Funneling contributors through a single point of contact helps to ensure that the engineers’ submissions will be considered property of the engineers’ employers.

GitHub

Under the Apache CLA, a contribution must be intentional by definition. Under any circumstance where code is not submitted through a formal process, the intentionality of that contribution is put in question. Accordingly, a uniform code contribution process should be employed, which usually, but not always, takes the form of pull requests through GitHub.

Generally, as part of a contribution process, a contributor company will create a fork of the repository being contributed to, make edits and additions to the repository, and then submit a pull request to update the canonical version. Such a procedure entails two roles: someone who initiates the pull request (submitter), and one or more people who have authored the actual content of the pull request (commit authors).

Often times the submitter and commit author may be the same person. However, multiple employees at the contributor company might combine edits in a single submission, in which case the submitter would only be one of the authors of the commits being submitted. In order to accept the pull request, it should be verified that the submitter and commit authors are all covered by one common CLA.²²

Guidance

Instructions

As described throughout this document, having a procedure for accepting CLA submissions plays a vital role in the aims of validating the agreement and reducing the risk of suit. As a best practice, this procedure should consist of: a check to see if the contracting party has already submitted a CLA, verification of the signee’s email address to ensure that it is a company address, and evaluation of the signee’s title to ensure that the signee wields signing authority.

Titles that confer authority

Per the discussion of apparent authority above, the act of conferring a given title upon an employee constitutes a “manifestation” that may be “reasonably” relied upon for establishing apparent authority. When evaluating a CLA signee's title, the following positions are regarded as wielding the requisite authority to execute the agreement:

President/CEO: presidents hold broad authority to take executive action on behalf of their company and will be considered to have authority to execute virtually any agreement.²³

Vice-President: there have been cases where a vice-president was found to lack apparent authority to sign on behalf of a company, but this turned on the contracting party’s knowledge that the vice-president lacked this authority²⁴ or where the agreement concerned matters outside the vice-president's scope of employment.²⁵ Generally, a vice-president will be found to wield authority to execute an agreement of significant import, such as a CLA.

General Manager: though an uncommon title in the context of software engineering and CLA execution, general managers are regarded as having broad authority to act on behalf of their company in the ordinary course of the company's business.²⁶

Chief Technology Officer/Director of Engineering: a "chief" officer or "director" holds significant executive authority, but this authority is generally confined to a specific function. Chief or director positions in departments that are related to software development can provide strong assurance of CLA signing authority.

Counsel: attorneys employed by a company are potentially be subject to heightened fiduciary obligations to the company, just as its officers and board of directors are. Absent evidence to the contrary, an action taken by counsel could be treated as a decision made with the company’s full knowledge and consent.²⁷

Titles that likely lack authority

If a corporate CLA were submitted by an individual with a title other than one of those listed above, it should be evaluated carefully. Accepting a signature from an employee with an irregular title might be appropriate after discussion to clarify the nature of the signee’s authority, but without such assurance it should likely be rejected. The following positions represent the most common titles of corporate CLA signees that should be regarded circumspectly:

Software Engineer: companies must be wary of developers and engineers attempting to sign corporate CLAs, as they might be acting independently of the organization they work for, and likely do not wield signing authority to bind the organization.

Director of Sales, Product Manager: as a counterpoint to the examples concerning chief officers and directors above, “chief,” “director,” or “manager” roles that are not external-facing or executive in nature, or not directly related to software development, could be found to lack the authority needed to enter into the agreement.²⁸

Legal Assistant: While counsel for a company may hold the authority to make representations and warranties on behalf of the company, and can bear responsibility for ensuring that their actions are undertaken with the full knowledge and consent of the company, the same would not necessarily apply to a legal assistant. Sometimes companies employ paralegal “contract managers” specifically responsible for managing licensing relationships, but this constitutes the sort of case where a discussion for clarification is advised.

Minimal information collection from corporations and individuals

Minimizing the collection of signees’ personally identifiable information (PII) reduces maintenance costs and protects signees’ privacy, but a certain amount of information collection is necessary. The two pieces of information that should always be collected from CLA signees are email address and name. For corporate CLAs, the name of the corporation and the signee’s corporate title should also be collected.

Email address verification serves three critical purposes: identity verification, company employee status verification, and means of contact.

Obtaining the name of the signee is indispensable for identity verification, but is also necessary for substantiating the agreement.

In the case of corporate CLAs, the collection of this information not only furnishes evidence of the agreement in the event of suit, it provides the criteria for establishing apparent authority. The email address establishes that the signee is an employee of the company they represent and that the signee is acting in their capacity as an agent of the company. The title establishes that the company has conferred authority upon the signee to execute the agreement.