When I started my career as an open source attorney, a significant concern was the proliferation of new forms of open source licenses, each requiring time-consuming analysis. As my colleague Scott Peterson points out in his article, "Open source licenses are shared resources":
"Focusing on a small number of licenses has an upside. Experiences and discussions can more readily reduce uncertainty through broader common understanding of a few licenses than if license-related actions and debates were divided among hundreds or thousands of different licenses."
The community response to license proliferation over the last many years has been positive, and I am pleased to see that the majority of open source projects are choosing to select from a certain set of options (e.g., GPL, LGPL, AGPL, BSD, MIT, Apache 2) that are all well-understood by engineers and lawyers. As such, there is no time wasted interpreting their terms and a low-friction ecosystem is fully enabled.
Once a project adopts an open source license, it usually adopts the standard "inbound=outbound" model; a phrase coined by Richard Fontana. Fontana describes the inbound=outbound model as contributions that are understood to be licensed under the applicable outbound project license, making it easy for contributors to participate in projects without intimidation and red tape. This is a very simple model that dovetails well with a smart license choice detailed above.
Unfortunately, many open source projects have chosen not to adopt inbound=outbound and, instead, require some form of a contributor license agreement (CLA). CLAs vary in scope and purpose. A good description of CLAs and Developer Certificates of Origin (DCOs; discussed below) may be found in Ben Cotton's article "CLA vs. DCO: What's the difference?"
Before a project that uses CLAs will accept contributions, they will require a CLA to be on file from the contributor, as an individual, or from the company that employs them. Unless the CLA is a standard CLA (e.g., the Apache Software Foundation [ASF] CLA with non-substantive customizations; see the next paragraph) where the terms are well understood by engineers and the lawyers that may represent them, contributions typically come to a grinding halt, since a very close read of the CLA terms must be performed to ensure the terms are fully understood. This process may take days or weeks to complete depending on workload and whether negotiations are required with the license drafter. In my experience, the end result is to go back to standard CLA terms! The whole torturous process leads to lots of wasted time and effort. In addition, the CLA will require some form of signature, adding more delays and complications that may be significant in large bureaucratic organizations. This is not a happy path and is highly erosive to the open source/collaborative development model.
Note that when I refer to a "standard CLA," I am referring to a CLA that is based on a well-known CLA such as the ASF Individual or Corporate CLA. While ASF CLAs are used in their original form by the ASF itself, they are often modified in a non-substantive way for use by other organizations. For example, most organizations are careful to get rid of the part at the beginning about the charitable mission of the license and they also customize the license name. These non-substantive variants of the ASF CLA are distinguishable from the Dr. Moreau-variants described in this article.
I am concerned about the recent proliferation of CLAs. We seem to be experiencing the same phenomenon we experienced with open source license proliferation over a decade ago. In fact, I have seen at least 20 different CLAs cross my desk at Red Hat over the last year that contained slight but substantive deviations from the very common ASF Individual or Corporate CLA. These changes are often minor to clarify language or rights, but some others are larger, hybrid abominations that remind me of the new animals created by Dr. Moreau by his process of vivisection (see The Island of Doctor Moreau on Wikipedia). Whether the changes are small or large, their effect may be significant and often leads to confusion, significant review time, and negotiations.
For example, it is generally accepted practice amongst lawyers to use initial capitalization on terms defined within a license or contract. Inadvertently using the lower-case form of that same term leads to ambiguity as to whether the standard/dictionary definition should be used or the narrower or broader term as defined in the agreement. Although this may seem like an insignificant change to the casual observer, this often leads to significant reduction or expansion in permissions received/granted by the license or to unacceptable ambiguity. Other changes are so poorly drafted that they have to be rejected outright since their meaning is so unclear.
In one recent example, a CLA's patent license language deviated from the Apache CLA version to include the term "derivative works" in a perplexing way. This was so vague that I was forced to reject its use since the scope of patent license being granted seemed overly broad and potentially unbounded. I am not sure if this was the result intended by the drafter of this specific CLA, but a significant amount of time and cost went into this review, ultimately restricting our engineers from contributing to the project. A sad result that benefits no one.
As a community, let's learn from our previous mistakes regarding open source license proliferation. Use an inbound=outbound model—preferably with the DCO—instead of a CLA. If you choose to use a CLA, then strongly consider one of the standards like the ASF Individual or Corporate CLA instead of creating new, fanciful, or absurd licenses akin to the monstrosities on Dr. Moreau's island in that H.G. Wells classic.
Comments are closed.