Open source for lawyers: Ongoing implications of open source use

by Matt Jacobs on January 8, 2020

Ongoing legal considerations associated with open source use include license enforcement, dual licensing, and deciding whether to license out your own code.

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 third in a three-part blog series that discusses the costs, challenges, and ongoing implications of open source use from a legal perspective.

Continuing implications of open source use

Many lawyers act strictly as open source license compliance gatekeepers; after evaluating any potential licensing challenges, they remove themselves from the ongoing management of open source reuse. Given the implications of a security breach or a license enforcement action, for instance, this is a mistake. Lawyers must stay involved and keep driving the continuing management of open source if they are to act in their clients’ or company’s best interests.

Sponsorships Available

One area where ongoing legal participation is particularly important is in license enforcement. The nature of license enforcement/compliance actions in open source has morphed from enforcement for ideological reasons to enforcement driven by companies against other companies for commercial reasons. This company-versus-company enforcement is potentially more concerning for open source users, since it isn’t just about “doing the right thing” but rather motivated by commercial drivers, such as lost revenue or competitive advantage.

Dual licensing

The classic example of commercially driven license enforcement is dual licensing. A company, as the copyright holder with the rights to license their software in almost any way they deem fit, may decide to license essentially the same code under two separate licenses. They may license their code under a traditional OEM-style license (typically for a fee) to anyone who wants to take that code and reuse it or embed it in a distributed commercial product without any GPL copyleft concerns. That same licensor may simultaneously license the same, or essentially the same, code under the GPL for those who want to use that code internally or who have no concern for the possible GPL copyleft implications, for whatever reason.

It happens with some frequency that a licensee, either out of lack of good open source management or negligence or as a product of willful misconduct, uses the code licensed under the GPL in their commercial applications where they should have paid for and used an OEM license that reflects their intended or actual use. In this scenario, it’s also likely that the licensee is not adhering to the other requirements of the license and is in breach.

This is straight-up copyright infringement. The GPLv2, under which many of these cases arise, has no cure provision. Accordingly, any breach of the GPLv2 results in an immediate termination of all rights granted thereunder, and thus any continuing use of that software is unlicensed. The dual-licensing scenario presents an easy case for calculating damages because the licensor can look at the OEM side of its business and calculate what the infringing licensee should have paid in royalties had that licensee assumed the correct license in the first place. Dual licensing is not the only scenario in which company-versus-company enforcement arises, but it is frequent and illustrative.

Licensing out of open source

Another area where ongoing legal management is important concerns the licensing out of open source, which many companies consider to be an important part of their business strategy. Companies adopting this strategy may include those who:

Are engaged in dual licensing
Wish to be open source friendly to attract and retain good engineering talent
Want to use the power of open source to encourage the adoption of a new platform or set of tools or other functionality that it hopes to then sell services or add-on software around

The decision to license out one’s own code, especially under one of the permissive-style licenses, should not be taken lightly. Once done, it is very hard, if not impossible, to reverse the implications of that decision. Recently, companies such as Redis Labs and MongoDB have expressed misgivings about building their businesses around permissive open source-licensed platforms in a manner that has allowed others, including competitors, to leverage those platforms without giving any commercial advantage back to the licensors (Redis Labs or MongoDB) or contributing any improvements or developments to the open source community generally.

Differences of opinion exist with respect to how a licensee who takes advantage of open source code exclusively for their own commercial advantage should be perceived, but the fact is that the permissive open source licensing model fully allows for this.

Learn more about the implications 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, the challenges related to open source use, and the security implications of open source vulnerabilities. It also offers practical advice for helping your organization or clients.