The Licensing Corner

• Publication year: 2018
• Author: Sean Hogle

The Licensing Corner

Sean Hogle

Rooney Nimmo PC

OPEN SOURCE CONTRIBUTION LICENSE AGREEMENTS: A MODEST PROPOSAL

Founders of open source software projects sometimes employ contributor license or assignment agreements, to which software code contributors to the project are required to accept as a condition of their contribution. These agreements vary considerably. Many are controversial and viewed as obstacles to robust community participation. Many fail to adequately protect the legal interests of the project.

This article briefly explains the differences between the various inbound approaches to open source code contributions. It wades into the controversy surrounding the maximalist iteration of these approaches, while addressing the problems that arise without at least an exclusive license to code contributions. This article concludes with a proposed solution that should satisfy both project sponsors and code contributors alike.

Open source projects commonly start with an initial contribution of source code, made publicly available under the terms of the project's open source license. One of the more popular methods of hosting and maintaining open source projects is distributed version control, with systems such as "Git."¹ These systems solicit so-called "pull requests," or developer-originated requests to commit that developer's code contributions to the project's main repository (repo). The project maintainer evaluates the merits of the contribution, using tools that make the task easier. If accepted, the contribution is then merged upstream into the project codebase main repo.²

These pull requests can occur on a daily or even more frequent basis for the more popular open source projects. As each developer's contribution is committed to the main repo, the project codebase morphs and extends, with each variant forming the basis from which subsequent contributions are derived. Every code contribution is potentially capable of copyright and patent protection, either independently or in combination with the ever-evolving project codebase.

The purposes of contributor agreements are to clarify the legal status, and hence enable ambiguity-free adoption and integration, of these contributions; to memorialize the irrevocable and perpetual right to use, copy and distribute such contributions; and, in many cases, to require the contributor to warrant originality (or something similar). Many require that the contributor grant a non-exclusive license to all, under the terms of the open source license the projec t has adopted. Others grant to the project sponsor a non-exclusive right, in lieu of or in addition to the rights granted in the project's open source license.

The Apache Software Foundation Contributor License Agreement (CLA) is fairly representative of the most common approach.³This CLA extends, to both the Apache Foundation and to its (sub) licensees, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable copyright license to contributions, as well as a similarly-prefaced patent license with respect to licensable patent claims necessarily infringed by the contributions, alone or in combination with the project codebase.

Perhaps in recognition of the relative unpopularity of contribution agreements, the developer community helming the open source Linux operating system kernel has, since 2004, eschewed any kind of contribution agreement, in lieu of a simpler "Developer Certificate of Origin" (DCO):

By making a contribution to this project, I certify that:

1. The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or
2. The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or
3. The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.
4. I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.⁴

[Page 26]

Surprisingly, the vast majority of open source projects have not used any contributor agreement (or even a DCO-inspired statement) of any kind.⁵ In the absence of a contribution agreement, the project sponsor, at best, has an implied license from the contributor, the terms of which are most likely the same terms as those in the project's outbound open source license. This implied license framework is known by the "inbound equals outbound" moniker. By making a contribution, the theory goes, the contributor is impliedly agreeing to license that contribution under the terms of the project open source license.

Open source practitioner Pamela Chestek ably highlights the problems with this theory:

In the absence of a contributor license agreement, the commonly-accepted understanding is called 'inbound = outbound,' which is the concept that contributions back to the software corpus are licensed under the outbound project license. It is not entirely clear how this is legally operative, but is either that the

...