Open Source Software Licensing: Not everything is as it seems.

Many have long agreed that software is eating the world.  The last few years have shown that open source software is a key part of both how and why this is possible.  It should surprise to no one reading this that the code for a typical commercial software product today is majority-open-source.  Companies large and small in industries that are heavily regulated or not regulated at all have embraced open source software and are building great things on top of it, sometimes open-sourcing the results and sometimes not.  This, of course, is why it is critical to review your open source usage: if you know the restrictions and obligations you must comply with, you are less likely to run afoul of them.

If you are at all familiar with open source software, you are aware that open source licenses are not all created equal; they are a very diverse bunch and are best thought of as a spectrum that ranges from the most permissive licenses (e.g. MIT-style license) to the most restrictive (e.g. GNU General Public License (GPL).  The core of any good compliance program is to concentrate the compliance efforts on the more restrictive software licenses and to approve with as little effort (and time) as possible, the most permissive ones.

So, if you are a developer who wants to use an MIT-licensed component like bedtools (https://github.com/arq5x/bedtools2), you exhale, knowing that your conversation with “legal” is going to be quick and painless.  Likewise, if you are a lawyer and a request for an MIT-licensed component comes in, you know that you are not going to have to be “the bad guy” today.  In fact, the MIT license is so permissive that you may have an auto-approve rule set up that bypasses legal review for components under this license entirely.  Such auto-approve rules can be a life-saver for busy compliance departments.  By taking care of the “easy” cases, they allow you to spend your time on the “harder” licenses and use-cases.

However, there is an exception to every rule, and bedtools appears to be just such an exception.  If you follow the link above, you will see that the LICENSE file states that the copyright is held by Aaron Quinlan and the date on the copyright is from 2009-2019.  However, if you look at the commit note associated with this file you will see that the license was changed 12 months ago (as of this writing).  License files are often changed to update the year on the copyright statement, but in this case the license was actually changed from the GPL v2 to the MIT license.  This also happens (though, much less frequently, and usually going the other way, from permissive to more restrictive), but it does require some additional thought.

We know from the README file that Mr. Quinlan was the original author of the code and that it is maintained by the Quinlan Laboratory at the University of Virginia.  The lead developers are listed as Aaron Quinlan, Hao Hoou, Brent Pedersen, and Neil Kindlon and significant contributions are acknowledged from Assaf Gordon, Royden Clark, John Marshall, Brent Pedersen, and Ryan Dalestats.  We also know, from the repository’s stats that 63 separate contributors have made 2,018 commits (or contributions of code) to this project and we can see that the majority of those commits predate the license change.

The project does not appear to have a Contributor License Agreement (CLA) which would govern the terms under which contributors make their contributions.  GitHub’s default rule, which you can find in Section D.5 of their Terms of Use (https://help.github.com/en/github/site-policy/github-terms-of-service#d-user-generated-content) is the open source community norm of inbound = outbound.  This means that, absent an agreement to the contrary, when someone contributes code to bedtools, they retain the copyright in that code and only grant bedtools and its maintainers a license under the terms of bedtools itself.

This is a potential problem.  For years, the bedtools project likely accepted contributions under the GPL (I say likely because there is a possibility of a separate contribution agreement existing outside GitHub, but this is unlikely) and this license does not allow the code licensed under it to be relicensed by the recipient.  This means that in order to properly change the license for the project from the GPL to the MIT license, every contributor whose contributions remained in the code would have to have agreed to the change.  There is nothing in the README file in the repository to tell us that this happened and, in fact, the project’s documentation (https://bedtools.readthedocs.io/en/latest/) still states (as of the update on April 25, 2020) “bedtools is freely available under a GNU Public License (Version 2).”

So, what’s the take-away here? There are three:

  1. Sometimes an “easy” case is not so easy and something that appears to be licensed under a permissive license may not actually be so licensed. In this case, absent additional information about how the license change was agreed to by all the contributors, there remains a risk that GPL-licensed code is part of bedtools.
  2. This is a great test-case for your rules engine (if you have one) – feed this component through and see if your auto-approve-MIT rule fires and what happens with it. Ideally, your tooling catches this and highlights it for review.
  3. It is very hard to change an open source project’s license if you accept contributions. So, if you are thinking of running an open source project and taking contributions, think long and hard about the license you pick and whether or not to require a CLA – the answer is not the same for everyone and for every case, but the choice requires careful consideration.

 

Leon Schwartz has almost two decades of professional experience with open source software. As an associate at GTC Law Group for almost a decade, he has helped a range of clients from startups to Fortune 500 companies navigate the legal risks associated with the use of open source software in commercial products by crafting practical real-world-applicable open source software policies, identifying risks through diligence, and guiding both sellers and buyers through various transactions (including mergers, acquisitions, investments, and divestitures). Prior to this, he designed and developed patient data management systems, medical device software, and web applications for both startups and large multi-nationals. He holds a B.S. degree in computer science from Rochester Institute of Technology and a J.D. degree from Northeastern University School of Law.

Leave a Reply

Your email address will not be published. Required fields are marked *