Open source license compliance, the TL;DR version

It’s easier than you think 🍷 and you (probably) don’t even need a lawyer 💸

December 29, 2020

Open source license compliance, the TL;DR version

What you will get here

This article will provide you with a realistic, pragmatic approach and a set of tools to work with open source—just like you’re probably already doing today—but with a stronger backbone and an arsenal of answers when your legal department calls you about ”WTF no one told them you developers use other people’s code” 😅 and” how are we even supposed to sell our software now”? Sound vaguely familiar? If it does, in 10 minutes you’ll walk away with some rules of thumb, a bit of tooling, and a solid policy that you can mold into your own if needed.

Being a TL;DR article, we will however avoid some of the more complicated parts of distribution/redistribution/bundling, because we’ll attempt instead to navigate around those issues.

Note: Being the author of this article, I represent only myself. I am not a lawyer so don’t see anything here as strictly legal advice. However, being a professional in IT and software development, this is a question I’ve dealt with many times, recently with the help of a legal expert. My own expertise is primarily technical; the perspective I represent is therefore from my own background and experience based on what I’ve gathered and learned. Always verify any claims and plans with your own legal representation!

⚠️ Your situation will affect what you can (and should) do ⚠️

Your exact situation is of course going to affect what licenses are possible to use and to what extent, and also what your obligations are. For this article I will assume that you are either a freelancer or someone working for a company, creating proprietary software and that you today use open-source libraries in your 9–5. I will further assume that you don’t make any changes at all to actual dependencies, thus only consuming them and not adding to them (can make a big difference for certain license types).

Let’s get this show on the road!

Open source confusion and dilemmas

Open source is fantastic, but I’ll be the first to say that its ideology and “laws” are not understood very well in the broader population. Software has become a major economic player, and software is nowadays a key component in practically every industry there is. But as software grows and gets interwoven in so many places, we must remind ourselves that there are more than only purely development-related responsibilities to take care of. One of these auxiliary concerns is the legal aspect of software, most often materialized through its license.

Some things you might have heard could include:

“Why are licenses so scary and confusing?” “Everybody is using open source, right, so can’t harm to use a package or a thousand, right?” “Open source is always free…?” “If we can commercialize someone else’s software, can’t they do the same with ours?”

Take a moment to read up on the actual definition of Open Source, it’s definitely worth a few minutes of your life!

You’ll perhaps have noted that the first three criteria, while sounding liberal and open-spirited, can actually become problematic when seen with certain lenses:

1. Free Redistribution
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

2. Source Code
The program must include source code, and must allow distribution in source code as well as compiled form. […]

3. Derived Works
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

— Source: The Open Source Definition (Annotated)

In a corporate or business context, you can imagine phrases like “The license shall not restrict any party from selling or giving away the software” causing mayhem and despair. The horror!

The software industry—and particularly open-source software, which is what we are discussing—happens to host a large number of licenses. Some are short, and some are fairly long. Some are very basic, and others aren’t exactly leisurely reading. Keeping up with the specificities and detail-level minutiae of each of them is daunting.

One way of seeing the function of licenses is that they all have their own respective ways to interpret the general definition cited above. The good thing is that licenses can be generalized as belonging to one of only a few, well-known, established camps.

Permissive licenses

Permissive standard licenses, like MIT, ISC, Apache 2.0, and BSD varieties
Non-standard permissive licenses, like Creative Commons, WTFPL, Unlicense, public domain (not recognized by all countries and jurisdictions)

Copyleft licenses

Weak copyleft, like APSL, CDDL, and CPL
Strong copyleft, like GPL, LGPL, and OSL
AGPL or similar, which also includes software that is “networked”

Note: There is also the category of unlicensed software, when there simply is no license. Sadly, this makes it very hard to claim any rights or obligations, even if software can sometimes legitimately be released under this flag to be free for all.

Let’s be super clear here. In essence—which you will have understood if you read the annotated guide to what open source means—it is indeed OK (in a general sense) to use an open source bit of code, monetize it, put it in in your work, build something new on it, modify it and so on. The exact nature of change, how you can call it your own, and your obligations to that privilege are the big differences between licenses.

Snyk has a more detailed overview here. Wikipedia has a wide, higher-level overview of the above licenses (and many more!) complete with how they compare to each other across several areas.

There’s also the compact and easy-to-scan Choose A License that goes through some of the most common ones:

Along the way, if you need to look up a license and read about it in plain English, look no further than tl;drLegal:

Recommendations for your approach to open source

#1: Prefer permissive licenses

Typically, what you want to watch out for are copyleft licenses (like the GPL varieties), which are also mockingly called “viral licenses” as they will typically force you to release any new code under that specific GPL license too. This means that sublicensing will be hard.

Sublicensing allows somebody to relicense all or part of the licensed software, for example, to use BSD-licensed code in a closed-source commercial application.

— Source: openmod

There is a lot to read up on and unpack when it comes to GPL. I advise you to read more (there are some references at the bottom that touch on this) if you are going to use GPL-licensed dependencies in your work. I’m not spitting on GPL in any way—it was formulated the way it is to keep software free—but for your potentially closed-source project you’ll want to think it over. GPL is used in many big open-source projects that need to stay free. It’s a good choice if you are ideologically motivated, for sure.

#2: Only use OSI-approved licenses

You also want to stick to Open Source Initiative-approved licenses, which will disqualify (among others) Creative Commons. That also significantly narrows down the list of licenses you have to know anything about.

#3: Honor the license’s obligations

Licenses tend to require some type of obligation on your end. With the policy I will propose (and using the common MIT license as an example), the most common obligations you will need to fulfill are:

Include copyright
Include license

These are usually contained in the same file, in most open source projects.

You can include the license text in your source file. If you do, and if you distribute your software as source code only, as some OSS do, the license text is automatically visible and right there with the MIT-licensed code. But if you distribute binaries, the license text (typically) gets compiled away, therefore you are no longer fulfilling the single condition in the license. What you need to do is include the license with your binary distributions, maybe as a text file, or embedded in the program’s about dialog. For most distribution channels, there’s some way of including the source code license(s). For an Android example, look at Settings > About > Legal Information > Open source licenses and enjoy.

— Source: What is the point of including the MIT copyright text if you use someone’s code licensed under MIT?

“OK, so I have to attribute people for their work?”

This can be done in a lot of ways. Some examples coming up…

Applications

In Google Chrome, for example, you can go to chrome://credits to see the following list of licenses Chrome uses:

Kind of neat. Anecdotally I’ve seen this in other software as well. As long as it’s publicly available and not hidden, per se, then it seems to tick the box.

Games

While I couldn’t find a visual example, it’s not uncommon that during a video games’ boot sequence or ending credits open source libraries are listed with their license.

Web sites/applications

Front-end apps (like client-side single-page applications) need to be built with their license file, as far as I understand things. There does not seem to be clear consensus on if the actual license text has to be “burned into” the JS bundle—which would seriously harm performance, and the web in general! 🤦‍♀ For now, it should be enough to just build and keep the license file and maybe have it accessible on the server. Following the long quote you read a minute ago, you might want to/have to include license info inside of the actual application similar to the Chrome example (if one would consider both the SPA and the browser as “binaries”).

For server-side applications it’s actually easier since the application code only ever renders/sends back a result to the user, in which case the user never has direct access to the source code itself. Ergo: No license file (or similar) needed for that case.

Selling your work (consultancy, transfer of ownership, or similar)

Generate the license file as in the previous Web example, and fulfill any other obligations you may have.

If possible, avoid bundling dependencies with your coded deliverable (that is, the source code that you are selling). This is me being paranoid, but I’d rather be safe than sorry. Actually that makes sense for certain runtimes like Node, in which it’s the task of npm install to actually (dynamically) get (“link”) the packages with your source code.

Recommended (generalized) open source policy

I was drafting an own proposal before I found the approach used by clothing retailer Zalando. Since their policy is both published online (it’s actually even open-source!) and can be easily linked to (and, to be frank, it’s a lot more mature than my mad scribblings) I proceeded to scrap my own plans and recommend their policy for adoption at my place of employment.

Zalando’s approach makes sense, is concise, it’s easy to follow and should be legally vetted and thus safe to use. The policy summary reads:

* Any dependency with a permissive license can be used
* For internal projects, Permissive, Strong and Weak Copyleft licensed code can be used
* For open source projects, Strong Copyleft licensed code cannot be used
* Make sure to investigate the specific terms of the weak copyleft licenses
* You cannot use AGPL or variants thereof licensed code anywhere
* You cannot use Commons Clause licensed code anywhere
* You cannot use unlicensed code anywhere
—Source: Zalando Open Source

Read the link for details, it’s Good Stuff®.

You’ll note the difference they make between how to deal with a strictly internal product and anything that gets in the hands of the public. They give a bit more leeway if it’s not public—and therefore can’t really harm you, nor can it “harm” the open source dependency—but Zalando does keep a restrictive and safe tone in the normal day-to-day operations.

“What about developer dependencies?”

My understanding is that — if we are discussing a case in which you have a public-facing web application or similar — any developer dependencies should not be taken into account for the policy. Unless it’s actually redistributed to a user, it’s out of scope.
Here are two threads that discuss the topic.

Should I credit indirect depended package in my open source credit notice too?

Should I give attribution for transitive dev-dependencies?

Examples of useful tooling

There’s a lot of good tools out there to help you script and automate common actions you may need to do with licenses. The tools listed here are suitable for a Node/JavaScript scenario.

Some good ways to use tools like these would be as part of a post-install script, inside of your continuous integration pipeline, or even in a pre-commit Git hook. Under all circumstances you will want to be proactive and have early indication when a package is not OK to use.

“No webpack stuff?”, you ask. Friend, there’s going to come a small bit on Webpack later in the article, don’t panic! 😄

License-compatibility-checker

“Check npm dependencies’ package.json for license compatibility (aka compliance check) with the current project based on spdx notation and naming conventions.”

Checks that your own license remains compatible with those of dependencies.

tldrlegal

“The easiest way to find out if your JavaScript project meets its dependencies’ licensing requirements. tldrlegal is a Node.js command-line tool that checks your dependencies for license requirements using a legal resource called tldrlegal.com which provides plain English software license interpretations.”

This package helps you take action on any license obligations you might have. Very helpful!

legally

“Discover the license of npm packages that you are using in an easy way.”

Good when you need to list all license resources (README, LICENSE, and package.json) and verify parity between them, or just dump a list of dependencies to your lawyer.

“Analyzes installed packages allowing to verify compliance with allowed licenses.”

Check if you have any non-compliant licenses among your dependencies.

Creating the license file

One of the common obligations will be generating that license file which has been mentioned several times already. You’ll want to keep a generated license file together with your own source code. For the love of God, don’t create it manually! 😄

Webpack 4 and earlier

If you are on Webpack 4 or earlier, Microsoft’s license-checker-webpack-plugin does the job of collecting your licenses and ensuring compliance if you give it a set of rules. See the below example for an implementation:

Webpack 5

Webpack 5 has built-in, automatic support for license file generation via its TerserWebpackPlugin. Zero configuration!

Other bundlers, tools, languages…

The point is similar regardless of your programming language. There’s for example rollup-plugin-license for Rollup, and I am fairly sure your language of choice— if it’s not Node—will have similar packages as those above, since the question of licenses is not tied to any given language.

Time to put a license on your work?

For your open-source project or “spare-time thingy”

You are probably just alright using the MIT license:

For proprietary or in-house work

Obviously—just to be clear here—if you are creating proprietary or in-house work, then it should be under regular copyright. In effect, as long as your dependencies are “safe” as per above, then you’ll just add your name or company name to your own license file to formalize the display of ownership. Nothing fancy or too hard. A Stack Overflow-given example looks like this:

/* Copyright (C) YoYoDyne Systems, Inc - All Rights Reserved
* Unauthorized copying of this file, via any medium is strictly prohibited
* Proprietary and confidential
* Written by Elmer Fudd <efudd@yoyodyne.com>, September 1943
*/