Open source for lawyers: Costs of open source use

Open source might be free, but it’s not risk-free. Let’s examine the potential legal cost of open source use associated with license noncompliance.

Sponsorships Available

Modern software development involves putting together software puzzle pieces from a variety of sources, and open source represents an ever-growing and important part of that puzzle. Lawyers need to be aware of all the potential risks that come with using open source components in a commercial codebase if they are to advise their clients and protect them from those risks. This article is the first in a three-part blog series that discusses the costs, challenges, and real-world implications of open source use from a legal perspective.

The cost of open source use

Although open source is free of acquisition cost, it is not free of management cost or risk. Critically, those reusing open source must confirm initially, and on an ongoing basis that:

• The way they are reusing open source complies with the governing open source license.
• The open source they’re using does not contain any known security vulnerabilities.

A real challenge arises in managing these risks at an enterprise scale and pace. Developers are encouraged to reuse open source to do their jobs better, faster, and cheaper. There are around 8,000 source forges and over 500 billion lines (and growing) of open source code to use. However, management and legal visibility into what open source developers are using, as well as where and how they’re using it, is often lacking. It follows that automated tools for identifying and tracking any open source being reused by an organization have become an indispensable part of a meaningful open source management program.

Open source license compliance is a matter that many lawyers have been exposed to at some point, but for some, it remains shrouded in mystery. This is likely because there is little legal precedent in the field, the most popular open source licenses tend to be opaque, and the heavy use of acronyms creates a unique language that can handicap the uninitiated.

GNU General Public License (GPL)

Chief among open source licenses, and the license that garners the most attention, is the GNU General Public License (GPL). GPL 2.0 (GPLv2) is the license that governs, and will always govern, arguably the most important open source project in history: Linux. Owing in part to the popularity of Linux and the pioneering work of the Free Software Foundation in the field of open source, the GPLv2, and now the GPLv3, are critical mainstays of open source licensing.

61% of the audited codebases contained some form of GPL license conflicts.

The GPL is the source of much discussion concerning its interpretation, application, and overall impact on those who reuse software code licensed under it. The primary concern, shared by most lawyers, is that if a client/company reuses any code licensed under the GPL alongside, in connection with, or as part of any of the client’s own code, the terms of the GPL will somehow apply equally to the client’s code. In other words, by implication of the GPL terms, the client’s code will be “infected” by the “viral” terms of the GPL.

There is some basis for this concern, but the GPL should not be read this way. First, the GPL freely allows internal use and modification of licensed code with no obligations. Companies are free to use Linux, or any other projects licensed under the GPL, for internal operations. They may modify those GPL-licensed projects as much as they like. And they can do so with no concerns about implicating any of the possibly unwelcome terms of the GPL.

Take care, however, when the client’s intent is to modify GPL-licensed code, incorporate some of their own code, and then distribute the resulting work. It is the act of distribution, or conveying, GPL and client proprietary code that may implicate certain provisions of the GPL in a manner that may be undesirable by the client.

GPL and copyright law

Boiling it down, you can think of the GPL’s so-called copyleft or reciprocal terms as a natural extension of basic copyright law. Copyright law extends a set of rights to the copyright holder, typically the original creator of some work (in this case, software). One of those rights is the right to grant others the ability to create derivative works. The GPL is essentially saying to anyone who accepts code under it (the licensee) that the copyright holder (the licensor) is granting the licensee the right to create a derivative but that if the licensee distributes that derivative, such derivative will likewise be subject to the GPL.

Buried in this are questions that a lawyer must address:

• When has a derivative been created?
• What are the boundaries of that derivative?
• When does a distribution happen?
• What, precisely, are a licensee’s obligations if it has distributed a derivative of code originally licensed under the GPL?
• What happens if the licensee fails to follow the obligations of the GPL, either intentionally or because it was unaware that GPL code had found its way into the licensee’s development environment?

The answers to these questions can depend heavily on context. However, before engaging in a legal analysis of how the GPL might apply to a client’s code, it is important to be clear whether the GPL necessarily applies to that code.

Implications of using GPL-licensed code

Ideally, a client who reuses GPL-licensed code will have considered all potential implications of their reuse before incorporating that code into their own software and then distributing the resulting derivative product. However, as discussed above, given the incredible amount of open source available, the pace at which it is used, and the frequent lack of management oversight, GPL-licensed open source inevitably and without the client’s knowledge finds its way into software codebases that a client expected to keep entirely proprietary. In such event, according to the GPL, the undesirable outcome may be that the client’s software likewise must be licensed under the GPL.

In a perfect world, the client will have identified at the outset any code they were working with that was originally licensed under the GPL and will have taken the necessary steps to use that code in a manner consistent with the obligations of the GPL and the client’s goals. Failing this, remediation approaches include rewriting the code to remove the GPL-licensed code, approaching the code licensor (if one can be identified) and seeking permission to use the code under some other license, or, the riskiest option, doing nothing.

That last approach—do nothing and see whether anything comes of it—underlies a frequent sentiment: Many believe it unlikely that copyright holders will become aware of some misuse of their code licensed under the GPL, and even more unlikely that they will do anything about it. This sentiment, however, misses a critical element of open source reuse and management: the real-world business implications.

For instance, open source analysis is a staple in M&A and investment due diligence. Target companies, even those that are not primarily in software development, should expect an interested party to perform scans against their code to identify the following:

• What open source it contains
• What open source licenses apply to that code
• Whether the company is in compliance with those licenses

Here, it is not some copyright holder making the target pay for a lack of good open source management practices but rather the acquiring company using this fact as leverage to drive down a purchase price or to obtain more favorable deal terms.

Permissive licenses

Another category of licenses, often referred to as permissive licenses, are easy to comply with and are free of the copyleft or reciprocal concerns of the GPL. The MIT and the BSD licenses, for example, are popular permissive licenses. Both essentially say that the licensee is free to use the code licensed under them in any manner that the licensee requires, provided the licensee gives attribution, essentially credit, to the licensor.

Given the open-ended nature of permissive licenses, code originally licensed under a permissive license is often relicensed under a closed source proprietary license or even repackaged and licensed under the GPL. So before you accept as fact that a piece of code is licensed under the GPL, it is worth investigating that code’s pedigree to see whether its copyright holder originally released it under a permissive license. If you can determine that the code was originally licensed under a permissive license, you can choose to license it under that permissive license, instead of the potentially less attractive GPL, and follow the obligations of that permissive license.

Open source in the supply chain

Another key area where a lack of good open source management practices can cause financial pain is in supply chain management. Many customers require each vendor to produce a comprehensive list of all the open source and third-party software contained in that vendor’s products. For vendors, being able to readily produce such a list, and stand behind it, is clearly a competitive differentiator. Vendors that can’t do this may see a lost opportunity. Lawyers can help their clients gain this competitive edge by keeping tabs on the open source components in use and their applicable licenses.

Learn more about the cost of open source use

Our new white paper, What Lawyers Need to Know About Open Source Licensing and Management, provides more information on the history and risk of open source software, open source license types and their obligations, and the security implications of open source vulnerabilities. It also offers practical advice for helping your organization or clients.