Subscribe
To the extent that tech companies manage their use of open source licenses and the associated 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.
Why include attribution?
Below are examples of three permissive licenses worthy of your particular attention. More broadly, however, bear in mind that in general, 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 U.S. 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 nonlawyer uncomfortable.
Ambiguity of the JSON license
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 U.S. federal government these days (kidding). JSON license limitations are sufficiently ambiguous that the Apache Foundation won’t include software thus licensed in its projects.
Facebook's use of the BSD license
Facebook licenses React, a popular JavaScript library for building UIs, under the BSD license. And in their GitHub repo, they say, “We provide an additional patent grant.” That’s great, but the grant also says your license will terminate if you are involved in any patent assertion against Facebook. Is this a problem? I guess not, if going after Facebook on a patent matter isn’t even a remote possibility. But who knows?
WTFPL license
And then there’s the WTFPL license. It says you can do whatever 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 reused. None of this is meant in any way to discourage. Just understand that managing your developers' use of open source requires a little attention even when it comes to permissive licenses.
READ NEXT: Top open source licenses and their legal risk categories
Continue Reading
