Posted by Phil Odence on June 21, 2017
To the extent that tech companies manage open source risks, their primary focus tends to be on reciprocal licenses and the GPL in particular. As I’ve discussed earlier, the potential risks of open source are broader than just license compliance. Additionally, there are other licenses to consider beyond the GPL. Even permissive licenses deserve a little respect.
A company distributing software rationally prioritizes GNU General Public License (GPL) to the top of the license review list. It’s an extremely popular license and the one that has been the subject of the most legal actions by a long shot. However, it’s a mistake to ignore permissive licenses.
Below are examples of three permissive licenses worthy of your particular attention. More broadly, however, bear in mind that generally permissive licenses come with obligations. Almost all require “attribution,” that is, including the copyright with the software. The BSD 2-Clause License Simplified, for example, makes it very clear that usage requires attribution. It’s not heavy lifting, but organizations need to manage it.
Removing copyright information from anything is certainly problematic (at least under US law). Title 17 of the United States code Section 1202 explicitly forbids removal of copyright information. Practically, the downside risk may not be that high, but Chapter 12 goes on to talk about civil remedies, statutory damages, and criminal offenses and penalties, all of which make this non-lawyer uncomfortable.
JSON, a very popular component for data interchange, is licensed under the JSON license. It is clearly permissive, save for the addition of one short clause: The Software will be used for Good, not Evil. And, capitals notwithstanding, Good and Evil are not defined terms. Therein lies the problem. Permitted use is at best ambiguous. Some might argue, for example, that this would preclude use of software by the US federal government these days (kidding). It’s sufficiently ambiguous that the Apache Foundation won’t include software, thus licensed, in its projects.
And then there’s the WTFPL license. It says, you can do what the…heck you want to. Lawyers I know would argue it is absolutely the most permissive license there is. That seems to be the intent of the author — read the About page and judge for yourself. What could be less problematic? Well, problematic is in the eyes of the beholder. Google does not like it, that’s for sure, because there’s no warranty disclaimer and (in their view) the rights grant is “very vague.” (Note, they don’t like the Beerware license either.) So, for a company being acquired by or doing business with Google (or other companies with a similar view), yes, the WTFPL is problematic.
Using open source provides huge benefits. And permissively licensed components are designed to be consumed and re-used. None of this is meant in any way to discourage. Just understand, managing your developers’ use of open source requires a little attention even when it comes to permissive licenses.
Get the latest Software Integrity news, thought leadership, and more.