ou can find the license information for open source software by looking at the source code. Different views, or reports, of that license information can be generated to address differing needs.

While providing license information directly in the source code is not a requirement for open source software, the practical benefits of doing so became apparent early. As open source licenses facilitate movement of software, license information that travels with the code simplifies administration by making the statements of the permissions readily available to those who have the code, even if they receive the code indirectly.

What are the license terms?
The value of embedding the license information in the source tree is underappreciated. Let us pause and reflect for a moment how useful this common practice has been [insert a moment of silence here].

What are the license terms? For much open source software, there is a simple answer: A single license text contains all the license information for the entire body of software. But the power of open source is that it facilitates other developers building upon that starting point, and that process can complicate license information.

Open source software can be extended, repurposed, and combined with other software. Unlike mechanical devices, on which collaboration by a diverse group is more challenging, it is practical for complex software to benefit from the work of many. Open source licenses provide the permissions to facilitate that development dynamic. Software with a complex history may also have complex license information.

Consider the following example: Someone writes a new program, including in each source file a copyright notice with a statement that the software is licensed under the Apache License, version 2.0, and including in the root of the source tree a copy of the text of the Apache License. Later, a file is added with a different copyright notice and a copy of a BSD 2-clause license. Then a new subdirectory is added, in which files have Apache license statements, but with copyright notices that identify a different copyright owner. Then a copy of an MIT License is added to a new subdirectory that includes files with copyright notices that are the same as in the MIT License file, but without any other license indication.

This example shows that license information embedded in a source tree can be complex and detailed. There may be license texts in the root and/or in various subdirectories. Some source files may have license notices; others may not. There may be copyright notices identifying various copyright holders. Separating the legal-looking bits from the code may not be possible without loss of information. Thus, the source code is the license.

Seen in the context of the source tree, interpretation of the license information in the example above is fairly straightforward. However, it would be challenging to capture that license information in a simple and unambiguous standalone statement. A license statement that captures all the license information present in the source code would be shorter than the source code, but it would be awkward—who would want such a highly detailed standalone statement? Most users would likely prefer a summary that, while incomplete, captures elements that match their own particular interests and sensitivities.

Summarizing license information: views
Responding to “What are the license terms?” with a copy of the full source tree may not be seen as helpful as it is bulky and dilute. Most people want a summary. But there is a challenge: When the license information is complex, people want different summaries because they have differing ideas of what is important.

For some, answering “yes” to the following questions might be adequate: Is the software 1) licensed under one or more open source licenses, and 2) assembled and licensed such that its distribution and use is consistent with all those licenses? Others may want a list of all the licenses, or they may want to see which software component corresponds to which license. Still others might want a component-by-component list that identifies any copyleft licenses (perhaps to do their own deep dive into copyleft compliance). And some might have an interest in seeing all the copyright notices and associated lists of software components.

A single summary will likely not address the interests of all. Simply making the summary more detailed may reduce its utility to some while remaining inadequate for others. Thus, there is a need for different “views” of the license information that is expressed in the source code. Think of the term view here as similar to how it is used in reference to databases. Alternatively, you might think of views as “reports.”

There is an advantage in thinking of (a) the source code as the license, and (b) there being multiple different views that may be extracted from it.

You might try to create a “do-everything” summary, from which other shorter summaries could be created. But an intermediate representation of license information has at least three shortcomings:

Timing: The maintainer of that master summary may not update on your schedule.
Versions: The master summary may be based on a different version of the software than what you use.
Quality: Your view inherits the error and judgment characteristics of the master.
Thus, there is value in generating your preferred view on demand, directly from the version of the source tree that you use.

Tools can generate views. On-demand view generation depends on tooling. The efficacy of that tooling is facilitated (or impeded) by the clarity (or confusion) of how license information is represented. We do not need machine-specific coding of license information, but we should take advantage of the many sources of experience representing information in ways that are both human-readable and machine-extractable.

In his article, An economically efficient model for open source software license compliance, Jeff Kaufman makes a related point: Because the source code contains the license information, distributing source code can be an efficient way of meeting certain license requirements.

Embedding all the license information in the source tree is a best practice. If you discover that license information is not represented in the source tree, consider improving the project by submitting a bug report recommending that that information be added to the source tree.

The source code is the license. From that complete record, views of license information can be generated. Tools can extract license information into various reports to meet particular needs or sensitivities.

We have work to do to obtain the full benefits of this vision. What is your sense of the state of tools and license information representation?

Too often, I hear it said that the MIT License has no patent license, or that it has merely some possibility of an “implied” patent license. If the MIT License was sensitive, it might develop an inferiority complex in light of the constant praise heaped on its younger sibling, the Apache License, which conventional wisdom says has a “real” patent license.

This distinction is repeated so often that one might be tempted to think there is some great legal significance in whether or not the word “patent” appears in the text of a license. That emphasis on the word “patent” is misguided. In 1927, the U.S. Supreme Court said:

“Any language used by the owner of the patent, or any conduct on his part exhibited to another from which that other may properly infer that the owner consents to his use of the patent in making or using it, or selling it, upon which the other acts, constitutes a license and a defense to an action for a tort.”

The MIT License unquestionably has an express license. That license is not limited to the granting of any particular flavor of intellectual property rights. The statement of license does not use the word “patent” or the word “copyright.” When was the last time you heard someone expressing concern that the MIT License merely had an implied copyright license?

Since neither “copyright” nor “patent” appear in the text of the grant of rights, let us look to the words in the MIT License to see what we might learn about what rights are being granted.

Permission is hereby granted,

That’s a straightforward start to the granting of permissions.

free of charge,

No fee is needed in order to benefit from the permission.

to any person obtaining a copy of this software and associated documentation files (the “Software”),

We have some basics defined: subject of the license and who is to benefit.

to deal in the Software without restriction,

Well, that’s pretty good. Now we are getting to the heart of the matter. We are not messing around with nuance: “without restriction” is pretty clear.

including without limitation

This introduction to a list of examples points out that the list is not a backhanded limitation: It is a list of examples.

the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so,

We have a mixed assortment of actions one might undertake with respect to software. While there is some suggestion of exclusive rights of a patent owner and some suggestion of exclusive rights of a copyright owner, these are not really focused on the specific lists of exclusive rights provided by particular intellectual property laws; the focus is software.

subject to the following conditions:

The permissions are subject to a condition.

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

The condition is of the type that has become typical of so-called permissive licenses.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

For completeness, let’s include the disclaimer.

There is nothing that would lead one to believe that the licensor wanted to preserve their right to pursue patent infringement claims against the use of software that the patent owner created and permitted others “to deal in the Software without restriction.”

Why call this an implied patent license? There is no good reason to do so. Let’s look at an example of an implied patent license. The patent dispute in Met-Coil Systems Corp. v. Korners Unlimited concerns an implied license for a patent (US Patent 4,466,641, long ago expired) on a way of connecting sections of metal ducts of the kind used in heating and air conditioning systems. The U.S. court that handles appeals in patent disputes concluded that the patent owner’s (Met-Coil) sale of its roll-forming machine (a machine that is not the subject of the patent, but that is used to bend flanges at the ends of metal ducts as a part of making duct connections in a patented way) granted an implied license under the patent to its customers; thus, sale by the alleged patent infringer (Korners Unlimited) of certain patent-related components (special corner pieces for use with the flanges that resulted from the Met-Coil machine’s bending) to those customers was not a contributory patent infringement because the customers were licensed (with an implied license).

By selling the metal-bending machine whose purpose was to play a role in using the patented invention, the patent owner granted a patent license to purchasers of the machine. In the Met-Coil case, one can see a need to talk about an “implied” license because there was no written license at all; the court was finding a license implied by behavior.

patent_illustration.png
Patent illustration
Now, let’s return to the MIT License. There is an express license. Does that express license grant patent rights? Indeed, with permission granted “to deal in the Software without restriction,” it does. And there is no need to arrive at that conclusion via anything more than a direct reading of the words that grant the license.

The phrase “express patent license” could be used with either of two intended meanings:

an express license that includes a grant of patent rights, or
a license that expressly refers to patent rights.
The first of those is the contrast to an implied patent license. If there is no express license that grants patent rights, one might move on in the analysis to see if a patent license might be implied.

People have often used the phrase “express patent license” with the second meaning. Unfortunately, that has led some to incorrectly assume that lack of such an “express patent license” leaves one looking for an implied license. However, the second meaning has no particular legal significance. The lack of expressly referring to patent rights does not mean that there is no express license that grants patent rights, and thus the lack of expressly referring to patent rights does not mean that one is limited to an implied grant of patent rights.

Having said all this, how much does it matter?

Not much. When people and companies contribute software under the MIT License, they do so without expecting to be able to later assert patent rights against those who use the software that the patent owner has contributed. That’s a strong statement, and of course, I cannot see directly the expectations of contributors. But over the 20+ years that I have observed contribution of code under the MIT License, I see no indication that contributors think that they are reserving the right to later charge patent license fees for use of their contributed code. Quite the contrary: I observe behavior consistent with the “without restriction” phrase in the license.

This discussion is based on the law in the United States. I invite experts on the law in other jurisdictions to offer their views on whether the result would be different in other countries.

On May 25, 2018 the General Data Protection Regulation will go into effect. This new regulation by the European Union will impact how organizations need to protect personal data on a global scale. This could include open source projects, including communities.

GDPR details
The General Data Protection Regulation (GDPR) was approved by the EU Parliament on April 14, 2016, and will be enforced beginning May 25, 2018. The GDPR replaces the Data Protection Directive 95/46/EC that was designed “to harmonize data privacy laws across Europe, to protect and empower all EU citizens data privacy and to reshape the way organizations across the region approach data privacy.”

The aim of the GDPR is to protect the personal data of individuals in the EU in an increasingly data-driven world.

To whom does it apply
One of the biggest changes that comes with the GDPR is an increased territorial scope. The GDPR applies to all organizations processing the personal data of data subjects residing in the European Union, irrelevant to its location.

While most of the online articles covering the GDPR mention companies selling goods or services, we can also look at this territorial scope with open source projects in mind. There are a few variations, such as a software company (profit) running a community, and a non-profit organization, i.e. an open source software project and its community. Once these communities are run on a global scale, it is most likely that EU-based persons are taking part in this community.

When such a global community has an online presence, using platforms such as a website, forum, issue tracker etcetera, it is very likely that they are processing personal data of these EU persons, such as their names, e-mail addresses and possibly even more. These activities will trigger a need to comply with the GDPR.

GDPR changes and its impact
The GDPR brings many changes, strengthening data protection and privacy of EU persons, compared to the previous Directive. Some of these changes have a direct impact on a community as described earlier. Let’s look at some of these changes.

Consent
Let’s assume that the community in question uses a forum for its members, and also has one or more forms on their website for registration purposes. With the GDPR you will no longer be able to use one lengthy and illegible privacy policy and terms of conditions. For each of those specific purposes, registering on the forum, and on one of those forms, you will need to obtain explicit consent. This consent must be “freely given, specific, informed, and unambiguous.”

In case of such a form, you could have a checkbox, which should not be pre-checked, with clear text indicating for which purposes the personal data is used, preferably linking to an ‘addendum’ of your existing privacy policy and terms of use.

Right to access
EU persons get expanded rights by the GDPR. One of them is the right to ask an organization if, where and which personal data is processed. Upon request, they should also be provided with a copy of this data, free of charge, and in an electronic format if this data subject (e.g. EU citizen) asks for it.

Right to be forgotten
Another right EU citizens get through the GDPR is the “right to be forgotten,” also known as data erasure. This means that subject to certain limitation, the organization will have to erase his/her data, and possibly even stop any further processing, including by the organization’s third parties.

The above three changes imply that your platform(s) software will need to comply with certain aspects of the GDPR as well. It will need to have specific features such as obtaining and storing consent, extracting data and providing a copy in electronic format to a data subject, and finally the means to erase specific data about a data subject.

Breach notification
Under the GDPR, a data breach occurs whenever personal data is taken or stolen without the authorization of the data subject. Once discovered, you should notify your affected community members within 72 hours unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. This breach notification is mandatory under the GDPR.

Register
As an organization, you will become responsible for keeping a register which will include detailed descriptions of all procedures, purposes etc for which you process personal data. This register will act as proof of the organization’s compliance with the GDPR’s requirement to maintain a record of personal data processing activities, and will be used for audit purposes.

Fines
Organizations that do not comply with the GDPR risk fines up to 4% of annual global turnover or €20 million (whichever is greater). According to the GDPR, “this is the maximum fine that can be imposed for the most serious infringements e.g.not having sufficient customer consent to process data or violating the core of Privacy by Design concepts.”

Final words
My article should not be used as legal advice or a definite guide to GDPR compliance. I have covered some of the parts of the regulation that could be of impact to an open source community, raising awareness about the GDPR and its impact. Obviously, the regulation contains much more which you will need to know about and possibly comply with.

As you can probably conclude yourself, you will have to take steps when you are running a global community, to comply with the GDPR. If you already apply robust security standards in your community, such as ISO 27001, NIST or PCI DSS, you should have a head start.

Container technology has, for many years, been transforming how workloads in data centers are managed and speeding the cycle of application development and deployment.

In addition, container images are increasingly used as a distribution format, with container registries a mechanism for software distribution. Isn’t this just like packages distributed using package management tools? Not quite. While container image distribution is similar to RPMs, DEBs, and other package management systems (for example, storing and distributing archives of files), the implications of container image distribution are more complicated. It is not the fault of container technology itself; rather, it’s because container distribution is used differently than package management systems.

Talking about the challenges of license compliance for container images, Dirk Hohndel, chief open source officer at VMware, pointed out that the content of a container image is more complex than most people expect, and many readily available images have been built in surprisingly cavalier ways. (See the LWN.net article by Jake Edge about a talk Dirk gave in April.)

Linux Containers
What are Linux containers?
What is Docker?
What is Kubernetes?
An introduction to container terminology
Why is it hard to understand the licensing of container images? Shouldn’t there just be a label for the image (“the license is X”)? In the Open Container Image Format Specification, one of the pre-defined annotation keys is “org.opencontainers.image.licenses,” which is described as “License(s) under which contained software is distributed as an SPDX License Expression.” But that doesn’t contemplate the complexity of a container image–while very simple images are built from tens of components, images are often built from hundreds of components. An SPDX License Expression is most frequently used to convey the licensing for a single source file. Such expressions can handle more than one license, such as “GPL-2.0 OR BSD-3-Clause” (see, for example, Appendix IV of version 2.1 of the SPDX specification). But the licensing for a typical container image is, typically, much more complicated.
In talking about container-related technology, the term “container” can lead to confusion. A container does not refer to the containment of files for storing or transferring. Rather, it refers to using features built into the kernel (such as cgroups and namespaces) to present a sort of “contained” experience to code running on the kernel. In other words, the containment to which “container” refers is an execution experience, not a distribution experience. The set of files to be laid out in a file system as the basis for an executing container is typically distributed in what is known as a “container image,” sometimes confusingly referred to simply as a container, thereby awkwardly overloading the term “container.”

In understanding software distribution via container images, I believe it is useful to consider two separate factors:

Diversity of content: The basic unit of software distribution (a container image) includes a larger quantity and diversity of content than in the basic unit of distribution in typical software distribution mechanisms.
Use model: The nature of widely used tooling fosters the use of a registry, which is often publicly available, in the typical workflow.
Diversity of content
When talking about a particular container image, the focus of attention is often on a particular software component (for example, a database or the code that implements one specific service). However, the container image includes a much larger collection of software. In fact, even the developer who created the image may have only a superficial understanding of and/or interest in most of the components in the image. With other distribution mechanisms, those other pieces of software would be identified as dependencies, and users of the software might be directed elsewhere for expertise on those components. In a container, the individual who acquires the container image isn’t aware of those additional components that play supporting roles to the featured component.

The unit of distribution: user-driven vs. factory-driven
For container images, the distribution unit is user-driven, not factory-driven. Container images are a great tool for reducing the burden on software consumers. With a container image, the image’s consumer can focus on the application of interest; the image’s builder can take care of the dependencies and configuration. This simplification can be a huge benefit.

When the unit of software is driven by the “factory,” the user bears a greater responsibility for building a platform on which to run the software of interest, assembling the correct versions of the dependencies, and getting all the configuration details right. The unit of distribution in a package management system is a modular unit, rather than a complete solution. This unit facilitates building and maintaining a flow of components that are flexible enough to be assembled into myriad solutions. Note that because of this unit, a package maintainer will typically be far more familiar with the content of the packages than someone who builds containers. A person building a container may have a detailed understanding of the container’s featured components, but limited familiarity with the image’s supporting components.

Packages, package management system tools, package maintenance processes, and package maintainers are incredibly underappreciated. They have been central to delivery of a large variety of software over the last two decades. While container images are playing a growing role, I don’t expect the importance of package management systems to fade anytime soon. In fact, the bulk of the content in container images benefits from being built from such packages.

In understanding container images, it is important to appreciate how distribution via such images has different properties than distribution of packages. Much of the content in images is built from packages, but the image’s consumer may not know what packages are included or other package-level information. In the future, a variety of techniques may be used to build containers, e.g., directly from source without involvement of a package maintainer.

Use models
What about reports that so many container images are poorly built? In part, the volume of casually built images is because of container tools that facilitate a workflow to make images publicly available. When experimenting with container tools and moving to a workflow that extends beyond a laptop, the tools expect you to have a repository where multiple machines can pull container images (a container registry). You could spin up your own. Some widely used tools make it easy to use an existing registry that is available at no cost, provided the images are publicly available. This makes many casually built images visible, even those that were never intended to be maintained or updated.

By comparison, how often do you see developers publishing RPMs of their early explorations? RPMs resulting from experimentation by random developers are not ending up in the major package repositories.

Or consider someone experimenting with the latest machine learning frameworks. In the past, a researcher might have shared only analysis results. Now, they can share a full analytical software configuration by publishing a container image. This could be a great benefit to other researchers. However, those browsing a container registry could be confused by the ready-to-run nature of such images. It is important to distinguish between an image built for one individual’s exploration and an image that was assembled and tested with broad use in mind.

Be aware that container images include supporting software, not just the featured software; a container image distributes a collection of software. If you are building upon or otherwise using images built by others, be aware of how that image was built and consider your level of confidence in the image’s source.

In 2018, Opensource.com again tackled the intersection of open source and the law, with the most-read articles addressing topics from privacy to patents.

One of the most impactful legal changes in 2018 was the implementation of the General Data Protection Regulation (GDPR), so it’s not surprising that many readers were interested in how the new law will affect open source communities.

As in previous years, open source licensing was a popular topic. One well-read article focused on recent court cases that helped shed light on what remedies exist for breaches of the General Public License (GPL). Another article explored whether the MIT License has a “real” patent license.

Since not all of our readers are lawyers, several articles aim to help open source contributors address legal concerns. For example, one article educates readers on meeting the legal challenges that may arise from distributing software through container images. Another helps open source contributors choose between a Contributor License Agreement and a Developer Certificate of Origin by explaining the difference between the two.

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.

The speed and agility of open source projects benefit from lightweight and flexible governance. Their ability to run with such efficient governance is supported by the potential for project forking. That potential provides a discipline that encourages participants to find ways forward in the face of unanticipated problems, changed agendas, or other sources of disagreement among participants. The potential for forking is a benefit that is available in open source projects because all open source licenses provide needed permissions.

In contrast, standards development is typically constrained to remain in a particular forum. In other words, the ability to move the development of the standard elsewhere is not generally available as a disciplining governance force. Thus, forums for standards development typically require governance rules and procedures to maintain fairness among conflicting interests.

What do I mean by “forking a project”?
With the flourishing of distributed source control tools such as Git, forking is done routinely as a part of the development process. What I am referring to as project forking is more than that: If someone takes a copy of a project’s source code and creates a new center of development that is not expected to feed its work back into the original center of development, that is what I mean by forking the project.

Forking an open source project is possible because all open source licenses permit making a copy of the source code and permit those receiving copies to make and distribute their modifications.

It is the potential that matters
Participants in an open source project seek to avoid forking a project because forking divides resources: the people who were once all collaborating are now split into two groups.

However, the potential for forking is good. That potential presents a discipline that drives people to find a way forward that works for everyone. The possibility of forking—others going off and creating their own separate project—can be such a powerful force that informal governance can be remarkably effective. Rather than specific rules designed to foster decisions that consider all the interests, the possibility that others will take their efforts/resources elsewhere motivates participants to find common ground.

To be clear, the actual forking of a project is undesirable (and such forking of projects is not common). It is not the creation of the fork that is important. Rather, the potential for such a fork can have a disciplining effect on the behavior of participants—this force can be the underpinning of an open source project’s governance that is successful with less formality than might otherwise be expected.

The benefits of the potential for forking of an open source project can be appreciated by exploring the contrast with the development of industry standards.

Governance of standards development has different constraints
Forking is typically not possible in the development of industry standards. Adoption of industry standards can depend in part on the credibility of the organization that published the standard; while a standards organization that does not maintain its credibility over a long time may fail, that effect operates over too long of a time to help an individual standards-development activity. In most cases, it is not practical to move a standards-development activity to a different forum and achieve the desired industry impact. Also, the work products of standards activities are often licensed in ways that inhibit such a move.

Governance of development of an industry standard is important. For example, the development process for an industry standard should provide for consideration of relevant interests (both for the credibility of the resulting standard and for antitrust justification for what is typically collaboration among competitors). Thus, process is an important part of what a standards organization offers, and detailed governance rules are common. While those rules may appear as a drag on speed, they are there for a purpose.

Benefits of lightweight governance
Open source software development is faster and more agile than standards development. Lightweight, adaptable governance contributes to that speed. Without a need to set up complex governance rules, open source development can get going quickly, and more detailed governance can be developed later, as needed. If the initial shared interests fail to keep the project going satisfactorily, like-minded participants can copy the project and continue their work elsewhere.

On the other hand, development of a standard is generally a slower, more considered process. While people complain about the slowness of standards development, that slow speed flows from the need to follow protective process rules. If development of a standard cannot be moved to a different forum, you need to be careful that the required forum is adequately open and balanced in its operation.

Consider governance by a dictator. It can be very efficient. However, this benefit is accompanied by a high risk of abuse. There are a number of significant open source projects that have been led successfully by dictators. How does that work? The possibility of forking limits the potential for abuse by a dictator.

This important governance feature is not written down. Open source project governance documents do not list a right to fork the project. This potentiality exists because a project’s non-governance attributes allow the work to move and continue elsewhere: in particular, all open source licenses provide the rights to copy, modify, and distribute the code.

The role of forking in open source project governance is an example of a more general observation: Open source development can proceed productively and resiliently with very lightweight legal documents, generally just the open source licenses that apply to the code.

In 2018, we saw a clear demonstration of the free and open source software (FOSS) business model’s importance when IBM moved to purchase Red Hat for $34 billion. The FOSS ecosystem also celebrated its durability last year, as the Open Source Initiative (OSI) celebrated the 20th anniversary of the open source movement.

Meanwhile, old legal problems returned. We saw another significant increase in litigation decisions involving FOSS issues, and several of these cases are very important. This increase in litigation is a reminder of the importance of an active compliance program for all corporations that use FOSS (which now means virtually all corporations).

Continuing the tradition of looking back to spot trends that will affect the future, the following are 2018’s top 10 legal developments in FOSS.

1. McHardy, the Linux system copyright troll in Germany, returns
Patrick McHardy, an early contributor to Linux, has been using the threat of litigation in Germany to obtain monetary settlements, essentially acting like a copyright troll. He has been active for five years and is believed to have approached over 80 companies. This number is difficult to estimate because many companies have settled without court action, and German court proceedings are confidential. McHardy’s litigation activities were first identified publicly in 2016, and he was inactive for a time in 2017.

However, in early 2018, we saw an important decision in his enforcement action against Geniatech: Initially, McHardy won an injunction against Geniatech prohibiting further distribution of its satellite TV receivers due to their alleged violation of the GPLv2 for Linux software. However, in March 2018, the appellate court in Cologne reversed the decision, ruling that:

a) McHardy is not co-author of the Linux kernel nor Netfilter;

b) McHardy might have rights in derivative works but did not provide sufficient evidence of the copyrightability of his contributions; and

c) McHardy might have misused his rights (if any), but the court noted that this issue would require further analysis. McHardy avoided further proceedings by withdrawing his petition for injunctive relief.

The finding on “joint ownership” is quite important because it would be very confusing if contributors were found to be joint owners of the copyright in the relevant program because the effects of joint ownership vary dramatically by country.

This case was unusual because McHardy has rarely been in court; his strategy is to threaten copyright enforcement against a company for violation of the GPLv2 through the use of an expedited copyright enforcement procedure available under German law. He then obtains a “settlement” with the company that he alleges violated the GPLv2. The settlement agreement includes a provision that the company will comply with the terms of the GPLv2, a common term in these types of settlements in Germany. McHardy then returns to the company several months later with another demand based on the settlement agreement; these demands can be for hundreds of thousands of euros. The enforcement of a settlement agreement is considerably simpler than enforcement of the GPLv2, which would raise many novel issues (see the summary of the VMware case below). Although he will sometimes characterize his actions as focused on “compliance,” he is clearly more concerned with making money.

2. EC antitrust decision against Google’s tying of Android software to its services
The European Commission fined Google €4.34 billion for breaching European Union antitrust rules. According to the EC, since 2011, Google has imposed illegal restrictions on Android device manufacturers and mobile network operators to cement its dominant position in general internet search. In addition, the EC demanded that Google bring the conduct effectively to an end within 90 days of the July 18, 2018, decision or face penalty payments of up to 5% of the average daily worldwide turnover of Alphabet, Google’s parent company. According to the EC, Google uses anti-fragmentation agreements to keep manufacturers on Google’s version of Android; currently most Android handsets (in all countries except the People’s Republic of China) ship with Google’s software and services bundled on them. Commissioner Margrethe Vestager, in charge of competition policy, identified three restrictions that violated EU antitrust law:

a) Google has required manufacturers to pre-install the Google Search app and browser app (Chrome) as a condition for licensing Google Play, its app store;

b) Google has made payments to certain large manufacturers and mobile network operators on the condition that they exclusively pre-install the Google Search app on their devices; and

c) Google has prevented manufacturers wishing to pre-install Google apps from selling even a single smart mobile device running on an alternative version of Android that was not approved by Google (so-called Android forks).

Google has appealed the decision.

3. Red Hat expands commitments to the GPL Cooperation Commitment
Red Hat expanded the companies who have agreed to the GPL Cooperation Commitment, which is a statement, signed by GPLv2 and LGPLv2.x copyright holders, that gives licensees a “cure” period for projects licensed under GPLv2 and LGPLv2.x licenses to correct unintentional violations before their licenses are automatically terminated. This approach is based on the cure provisions included in GPLv3. Red Hat significantly expanded the number of signatories in 2018, from four companies in 2017 (Red Hat, Facebook, Google, and IBM) to 40 companies at the end of 2018. Red Hat is also inviting individual contributors to sign the Commitment. Red Hat has shown significant thought leadership in finding a solution to a significant problem for the community.

4. Open Invention Network continues its expansion
OIN has been critical in minimizing the potential for patent litigation in the Linux ecosystem. OIN says it is the largest patent non-aggression community in history, with more than 2,750 community members. Prominent new members joined OIN in 2018, such as Microsoft, Tencent, Ant Financial, and Alibaba. Microsoft was a particularly interesting recruit because as recently as 2014, it made about $3.4 billion from licensing its patents to manufacturers of products using the Android operating system. OIN also expanded the scope of patent non-aggression agreements to include 151 new packages, bringing the total number of protected packages to 2,873.

5. OpenSSL license change
The OpenSSL project announced that it had completed its shift from the OpenSSL/SSLeay license to the Apache Software License version 2 (ASLv2). The project announced the proposed change in 2015. The original OpenSSL/SSLeay license was a non-standard permissive license and included a number of clauses, particularly relating to attribution, which were common in early FOSS licenses but dropped from more recent ones. The process took three years and emphasizes the difficulty of completing such transitions and, thus, the importance of selecting the most appropriate license at the beginning of a FOSS project. ASLv2 is becoming the favorite license for FOSS projects targeted at the enterprise.

6. Rise of FOSS in blockchain projects
Many blockchain projects are licensed under FOSS licenses. However, the blockchain community has not engaged with the FOSS community, and many of its choices seem unusual for infrastructure technologies. For example, the traditional Ethereum blockchain clients were licensed under GPLv3 and LGLv3.0. However, the blockchain community appears to be becoming more sensitive to these issues, and the release of the new PegaSys client under the ASLv2 represents a new sophistication to these issues.

The team that developed PegaSys noted: “To get Ethereum to production, we also need to lower the barrier to entry for enterprises. Many companies’ legal or compliance departments restrict them from using software under the GNU Public License (GPL), which the mainstream Ethereum clients currently use. We have heard stories of enterprises that completed a successful pilot on Ethereum, only to be stopped from going to production because of company policies around OSS licenses. We hope to solve that pain point by releasing Pantheon Core under an Apache 2.0 license and smooth the path for adoption.”

7. Oracle v. Google redux
The Court of Appeals for the Federal Circuit (CAFC) published its second decision in the ongoing case of Oracle against Google, ruling that Google’s unauthorized use of 37 packages of Oracle’s Java application programming interface (API) in its Android operating system infringed Oracle’s copyrights. The CAFC overturned the first district court decision to find that the APIs were copyrightable and returned the case to the district court for a decision upon the fair use defense. Once again, the district court found against Oracle on the basis that Google’s use of the APIs was fair use. Oracle appealed. The CAFC, once again, overturned the district court decision, finding that Google’s use of the APIs was not fair use as a matter of law. The case has been remanded to the district court to rule on damages. Given the increasing use of APIs in FOSS, this case has important implications for FOSS license compliance in the future.

8. Red Hat enters an agreement with IBM for acquisition for $34 billion
Red Hat has entered into an agreement with IBM to be acquired for $34 billion. If approved, this price will be the largest amount ever paid for a software company, much less an open source software company.

9. Rise of cloud conflicts and new licenses
Many FOSS companies express concern about the use of their programs by cloud service providers who don’t provide payments to the FOSS company. Last year, Redis Labs changed the license for Redis modules developed by Redis Labs from AGPL to Apache 2.0 modified with Commons Clause (these Redis modules are add-ons on top of Redis core, including RediSearch, Redis Graph, ReJSON, ReBloom, and Redis-ML). It introduced the Commons Clause (which it added to its ASLv2) to limit its products’ use by cloud service providers. The introduction of this hybrid license was quite controversial, and very few companies adopted it.

To date, Redis Labs has not sought OSI approval for this license. In October 2018, a group called GoodFORM announced it was forking the code prior to the addition of the Commons Clause and would provide it under the AGPLv3. More recently, MongoDB took a different approach to this issue by revising the AGPLv3 to create the Server Side Public License (SSPL). This license has broader obligations to make Complete Corresponding Source Code available to users of the software. However, MongoDB has announced that it has submitted the SSPL to OSI for approval.

10. Tension between FOSS projects and standard-setting organizations
As FOSS has become widely prevalent as a development methodology, standard-setting organizations (SSOs) have been working to integrate FOSS approaches into their own processes. However, the methodologies of FOSS projects and SSOs are quite different: FOSS projects run on a more decentralized basis with very different assumptions. One source of friction is the common approach in SSOs that provides for members to license their patents on a royalty-bearing basis (under FRAND terms). However, most FOSS communities assume that patents in FOSS projects will be licensed on a royalty-free basis.

Although some FOSS licenses have express patent license provisions (such as ASLv2), the existence and scope of patent licenses in other FOSS licenses are more ambiguous. This difference in approach to royalty payments for patents is creating tension between the FOSS and SSO communities. This issue is unlikely to be resolved in the near term.

Development of standards specifications and development of open source software have much in common: both are mechanisms by which competitors can collaborate; both can facilitate interoperability; both can be used to facilitate the adoption of new technologies; both can be used to crystallize or harmonize mature technologies.

A technology may use both standards and open source: sometimes one precedes the other; in other cases, they may proceed in parallel. Increasingly, they may use similar tooling and process practices (e.g., fine-grained version control; driving certain development discussions with issue trackers).

The extent of the similarities can lead to over-generalization, incorrectly implying that everything is interchangeable—mix-and-match—pick a practice here; combine it with a process there. Indeed, it can be valuable to take experience gained in one domain and see if the benefit it provides might be obtained in other contexts. However, for certain practices, the context matters more than might be apparent.

While there are similarities, there are also significant differences. In an earlier article (Governance without rules: How the potential for forking helps projects), I discussed how governance of open source software development and standards development differ in the ability to take advantage of the potential for forking as a force that can facilitate lightweight governance. Another difference relates to the choice of patent rules.

Treatment of patents
Treatment of participant patent rights is typically arranged differently in open source software development and in standards development. There is a rationale for the difference. And, the difference has consequences for structuring the development process.

Open source: Patent licenses granted when contributing to open source projects are generally scoped by each contributor’s contribution.
Standards: Patent commitments made by participants in standards development are generally scoped by the entire, final specification.
Open source projects: contribution-based patent rules
What do I mean by a contribution-scoped patent rule? If a patent owner contributes software such that, as a result of the software’s addition to the project, the project software infringes a patent owned by that contributor, then the contributor ought not to come back and expect a patent license fee for use of software that it contributed. Of course, there are plenty of different license texts that could keep us busy analyzing the interpretation of each license and talking about uncertainties and nuances in the situations. In another article, I talked about this issue in the context of the MIT License (Why so little love for the patent grant in the MIT License?). I believe that, essentially, the shared expectation in open source development is as I have described above: When you contribute to open source, you are giving all the needed permissions that you have for the software that you contribute, and you will not later come back asking for a license fee for use of the software that you contributed.

Standards development: specification-based patent rules
In contrast, in development of standards, there is generally a higher expectation: Participants are expected to make a commitment with respect to patents that are essential to the entire, final specification, not merely to their contributions. Those patent commitments do not depend on determining who contributed what idea to the specification; for those who are part of the group developing the spec, their commitment is to the whole specification.

Patents included
The analysis to determine the relevant patents is also somewhat different between software and specifications. Software will typically include implementation details that would not be required if compared to a corresponding standards specification; permission to use any patents on those details would be included when contributing software. In contrast, the patent commitment for specification development is limited to patents that are “essential” or “necessary” to the specification. This, of course, depends on what is specified. For interoperability standards, the specification should only include the level of detail needed to accomplish interoperability, allowing implementation details to differ among competing implementations of the standard. A commitment to essential patents would not include patents on implementation details, which may be used as competitive differentiators.

Basis for differences in patent rules
Why is there this difference in treatment of patents? This different treatment makes sense in light of differences in how standards and open source software are developed.

The more limited, contribution-based expectation concerning patents fits with the incrementally evolving, open-ended nature of most collaborative software development. Open source projects often undergo continuous development, the direction of which may evolve over time. While roadmaps and milestones may be set and snapshots taken, these are less common and have less restrictive impact than the scope limitations and version targets that are common among standards projects.

One can see how the higher expectation that is typical of standards development (the whole final spec, not only contributions) makes sense considering differences in how development of standards specifications is structured. Standards specifications typically undergo a strongly version-oriented evolution with explicit scope. Specification development typically works toward specific snapshot versions. A standards development activity will often have a target set of functionality (typically expressed in a document such as a charter). This provides a clearer shared advance expectation as to the scope of technologies that are likely to be implicated in a standards development activity than would be the case for many software development activities. This clarity of scope facilitates a potential participant’s evaluation of the patent implications of participating in a standards development project at the time of beginning participation. Contrast this with a more open-ended open source software development project, which would not generally exclude the possibility of incorporating any particular technology.

Implications on management of open source projects and standards
These different approaches to patents require different approaches in project management.

An open source project is often prepared to accept patches from new contributors. Contributors may come and go over time. Some stay. Others may stop by the project to address a single, limited issue. With software contributions, it is easier to have an understanding of who contributed what software than to have a precise understanding of who “participated” in some more abstract way.

On the other hand, there is typically greater formality associated with participation in a standards development activity. And, such formality of participation is important when it comes to the patent commitments. A patent commitment to the final spec makes sense when one participates through much of the development of that spec. Can a standards development process expect a full final specification commitment from one who provided a single, narrow contribution? It is important to have a process that leads to a clear understanding of who is participating and who is not. Clarity of participation is needed to support patent commitments from the actual patent owners, which are generally the companies who are represented by the individuals who are sitting at the table (speaking metaphorically; although this can involve actual tables).

How is a specification-wide commitment obtained? The royalty-free patent commitments that are typical of software standards are most commonly implemented as a condition of membership in the standards organization or membership in the particular committee that is responsible for development of the specification. In order for this mechanism to work, membership must be a well-defined concept, so that there is a clear membership decision point (i.e., a well-defined action that would be used to trigger the undertaking of patent commitments) and a clear record on which the beneficiaries of the commitments can rely. In addition to participation clarity, in order to facilitate participation by skeptical patent-owning participants, projects need to have an explicit scope and a clear beginning and end (with clarity of what is the “final specification” to which commitments will apply). This model for participation differs significantly from typical open source projects, which may have a continuum of participation extending from a few main drivers down to those who may submit only a single patch.

Patent policies
While the difference I have described is generally the case, there may be reasons for a particular activity to follow a different pattern. For example, consider the software that is a reference implementation that accompanies a standards development activity. There may be a strong rationale for expecting participants to commit to the full, final resulting reference implementation, not only to their contributions to it. Of course, other edge cases may exist; there may be rigidly scheduled open source development; there may be continuous, free-wheeling specification development.

Patent policies for standards development can be categorized as reasonable and non-discriminatory (RAND) or royalty-free (RF): essentially, whether patent licensing fees for implementation of the standard are considered OK (RAND) or not (RF). Development of standards relating to software (the focus of this article) more often uses a royalty-free policy. This matter of whether patent license fees are expected or not is a separate dimension of the policy from the scope of the license or commitment.

Conclusion
Development of standards and development of open source software typically have different scopes of patent expectations from participants (only to contributions or to the entire final deliverable). Rather than arbitrary differences, there is a rationale for these different choices that is based on significant differences in how development is typically undertaken.

Few legal topics in open source are as controversial as contributor license agreements (CLAs). Unless you count the special historical case of the Fedora Project Contributor Agreement (which I’ve always seen as an un-CLA), or, like Karl Fogel, you classify the DCO as a type of CLA, today Red Hat makes no use of CLAs for the projects it maintains.

It wasn’t always so. Red Hat’s earliest projects followed the traditional practice I’ve called “inbound=outbound,” in which contributions to a project are simply provided under the project’s open source license with no execution of an external, non-FOSS contract required. But in the early 2000s, Red Hat began experimenting with the use of contributor agreements. Fedora started requiring contributors to sign a CLA based on the widely adapted Apache ICLA, while a Free Software Foundation-derived copyright assignment agreement and a pair of bespoke CLAs were inherited from the Cygnus and JBoss acquisitions, respectively. We even took a few steps towards adopting an Apache-style CLA across the rapidly growing set of Red Hat-led projects.

This came to an end, in large part because those of us on the Red Hat legal team heard and understood the concerns and objections raised by Red Hat engineers and the wider technical community. We went on to become de facto leaders of what some have called the anti-CLA movement, marked notably by our opposition to Project Harmony and our efforts to get OpenStack to replace its CLA with the DCO. (We reluctantly sign tolerable upstream project CLAs out of practical necessity.)

Why CLAs are problematic
Our choice not to use CLAs is a reflection of our values as an authentic open source company with deep roots in the free software movement. Over the years, many in the open source community have explained why CLAs, and the very similar mechanism of copyright assignment, are a bad policy for open source.

One reason is the red tape problem. Normally, open source development is characterized by frictionless contribution, which is enabled by inbound=outbound without imposition of further legal ceremony or process. This makes it relatively easy for new contributors to get involved in a project, allowing more effective growth of contributor communities and driving technical innovation upstream. Frictionless contribution is a key part of the advantage open source development holds over proprietary alternatives. But frictionless contribution is negated by CLAs. Having to sign an unusual legal agreement before a contribution can be accepted creates a bureaucratic hurdle that slows down development and discourages participation. This cost persists despite the growing use of automation by CLA-using projects.

CLAs also give rise to an asymmetry of legal power among a project’s participants, which also discourages the growth of strong contributor and user communities around a project. With Apache-style CLAs, the company or organization leading the project gets special rights that other contributors do not receive, while those other contributors must shoulder certain legal obligations (in addition to the red tape burden) from which the project leader is exempt. The problem of asymmetry is most severe in copyleft projects, but it is present even when the outbound license is permissive.

When assessing the arguments for and against CLAs, bear in mind that today, as in the past, the vast majority of the open source code in any product originates in projects that follow the inbound=outbound practice. The use of CLAs by a relatively small number of projects causes collateral harm to all the others by signaling that, for some reason, open source licensing is insufficient to handle contributions flowing into a project.

The case for CLAs
Since CLAs continue to be a minority practice and originate from outside open source community culture, I believe that CLA proponents should bear the burden of explaining why they are necessary or beneficial relative to their costs. I suspect that most companies using CLAs are merely emulating peer company behavior without critical examination. CLAs have an understandable, if superficial, appeal to risk-averse lawyers who are predisposed to favor greater formality, paper, and process regardless of the business costs. Still, some arguments in favor of CLAs are often advanced and deserve consideration.

Easy relicensing: If administered appropriately, Apache-style CLAs give the project steward effectively unlimited power to sublicense contributions under terms of the steward’s choice. This is sometimes seen as desirable because of the potential need to relicense a project under some other open source license. But the value of easy relicensing has been greatly exaggerated by pointing to a few historical cases involving major relicensing campaigns undertaken by projects with an unusually large number of past contributors (all of which were successful without the use of a CLA). There are benefits in relicensing being hard because it results in stable legal expectations around a project and encourages projects to consult their contributor communities before undertaking significant legal policy changes. In any case, most inbound=outbound open source projects never attempt to relicense during their lifetime, and for the small number that do, relicensing will be relatively painless because typically the number of past contributors to contact will not be large.

Provenance tracking: It is sometimes claimed that CLAs enable a project to rigorously track the provenance of contributions, which purportedly has some legal benefit. It is unclear what is achieved by the use of CLAs in this regard that is not better handled through such non-CLA means as preserving Git commit history. And the DCO would seem to be much better suited to tracking contributions, given that it is normally used on a per-commit basis, while CLAs are signed once per contributor and are administratively separate from code contributions. Moreover, provenance tracking is often described as though it were a benefit for the public, yet I know of no case where a project provides transparent, ready public access to CLA acceptance records.

License revocation: Some CLA advocates warn of the prospect that a contributor may someday attempt to revoke a past license grant. To the extent that the concern is about largely judgment-proof individual contributors with no corporate affiliation, it is not clear why an Apache-style CLA provides more meaningful protection against this outcome compared to the use of an open source license. And, as with so many of the legal risks raised in discussions of open source legal policy, this appears to be a phantom risk. I have heard of only a few purported attempts at license revocation over the years, all of which were resolved quickly when the contributor backed down in the face of community pressure.

Unauthorized employee contribution: This is a special case of the license revocation issue and has recently become a point commonly raised by CLA advocates. When an employee contributes to an upstream project, normally the employer owns the copyrights and patents for which the project needs licenses, and only certain executives are authorized to grant such licenses. Suppose an employee contributed proprietary code to a project without approval from the employer, and the employer later discovers this and demands removal of the contribution or sues the project’s users. This risk of unauthorized contributions is thought to be minimized by use of something like the Apache CCLA with its representations and signature requirement, coupled with some adequate review process to ascertain that the CCLA signer likely was authorized to sign (a step which I suspect is not meaningfully undertaken by most CLA-using companies).

Based on common sense and common experience, I contend that in nearly all cases today, employee contributions are done with the actual or constructive knowledge and consent of the employer. If there were an atmosphere of high litigation risk surrounding open source software, perhaps this risk should be taken more seriously, but litigation arising out of open source projects remains remarkably uncommon.

More to the point, I know of no case where an allegation of copyright or patent infringement against an inbound=outbound project, not stemming from an alleged open source license violation, would have been prevented by use of a CLA. Patent risk, in particular, is often cited by CLA proponents when pointing to the risk of unauthorized contributions, but the patent license grants in Apache-style CLAs are, by design, quite narrow in scope. Moreover, corporate contributions to an open source project will typically be few in number, small in size (and thus easily replaceable), and likely to be discarded as time goes on.

Alternatives
If your company does not buy into the anti-CLA case and cannot get comfortable with the simple use of inbound=outbound, there are alternatives to resorting to an asymmetric and administratively burdensome Apache-style CLA requirement. The use of the DCO as a complement to inbound=outbound addresses at least some of the concerns of risk-averse CLA advocates. If you must use a true CLA, there is no need to use the Apache model (let alone a monstrous derivative of it). Consider the non-specification core of the Eclipse Contributor Agreement—essentially the DCO wrapped inside a CLA—or the Software Freedom Conservancy’s Selenium CLA, which merely ceremonializes an inbound=outbound contribution policy.