Should you care about the license? (TL;DR: yes!)

How Open-Source licenses apply to NPM dependencies and Full-Stack JavaScript development

6 min readOct 14, 2017

Checking package licenses with my great new tool ✨ https://github.com/delfrrr/npm-consider ✨

Disclaimer: I’m a developer, not a lawyer; this information is believed to be correct, but is not legal advice; if you think something is incorrect, please, write a comment and we will fix it together🔧

Should you care?

Before I was not concerned about license of npm package. I could check the license of immediate dependency but never checking 3rd party (transitional) dependencies.

🚓 And then I met guys from legal department 🚓

I now believe that developers should have a basic understanding of software licensing to have a constructive dialog with legal teams in their companies. This post collects a general knowledge about Open-Source licenses and how it applies to npm dependencies and Full-Stack JavaScript development in general.

Let’s figure out when you should start worrying about licenses.

When are license requirements triggered?

If you perform linking with open source libraries and then distribute resulting software, then your software needs to be compliant with the requirements of linked libraries.

Let’s look closer at linking and distribution applied to JavaScript apps.

Linking

Using 3rd party libraries normally means linking them:

If you bundle (i.e. with webpack) your code with open source packages it counts as static linking
If you use open source package in your Node.JS app (i.e. via require) or connect it to a web page via script tag, it is dynamic linking

Note: when building a bundle or running Node.JS app you perform the same type of linking with both immediate (listed in your package.json) and transitive (listed in 3rd party package.json) dependencies. Immediate and transitive dependencies licenses have the same effect on your software.

This was not intuitive for me before 🤔

Distribution

Just using open source libraries does not necessary trigger license requirements. Normally, license requirements are triggered when you distribute software:

Transferring software between employees of the same company is not a distribution
When users interact with your Node.JS app over network, it is not a distribution for most open source licenses; but it is a distribution for Network Protective licenses like AGPL
Putting JavaScript files on a public web server is a distribution

Which license is ok

Most of the open source licenses generally fall into one of these types:

Public Domain and Permissive licenses like MIT which allow you to do anything except sue the author
Copyleft or Protective licenses like GPL prevent linking (see above) with proprietary software; the edge case is Network Protective licenses like Affero GPLv3 which triggers by interaction over network;
In between of two above are Weakly Protective licenses like MPL which has less restriction for dynamic linking (until library is in its own file)

Let’s check common scenarios for a JavaScript developer:

You are making a web app

Most probably you bundle all your files, including libraries into one JS file and put it on a web server. You are performing static linking and distribution. It’s fine to use packages with Permissive licenses in a bundle.

If you need to use a package with Weakly Protective license like MPL you have options:

Load library from separate file (i.e. via script tag)
Apply compatible open source license to your bundle (but check comment below and talk to your legal team before)

If your bundle does not have ✨valuable intellectual property✨ then the second should be fine. I don’t believe competitors will benefit from your obfuscated code. But if the bundle does contain valuable intellectual property, then applying open source license is granting free usage of it.

You are making aNode.JS app

In this case, you normally connect libraries via a require() call. It’s a dynamic linking. It’s fine to use Permissive and even Weakly Protective licenses. Just make sure that packages stay in their own files with respective licenses.

If you are providing SaaS only and you are not distributing in any other way, you can use even packages with a Protective license. For many Protective licenses, network interaction is not a distribution. The exception is Network Protective licenses like Affero GPLv3

You are making an Open Source NPM package

Normally, you connect 3rd party dependencies via a package.json. To my best knowledge, listing dependency in package.json cannot be considered as linking. Linking will be performed by an app developer who will use your package on a build or run stage.

If you don’t want to confuse package users make sure that all dependencies (both immediate and transitive) have compatible licenses with your package license.

Typically dependency licenses should be more permissive or the same level of permissive as your package license.

For example, if your package has license Apache 2.0 you can use dependencies with MIT and BSD license. But you should not use dependency with MPL1.1 or LGPLv3 license, because they have stronger copyleft.

An arrow from box A to box B means that you *can* combine software with these licenses; the combined result effectively has the license of B, possibly with additions from A; image from work of David A. Wheeler

When you need to put bundles or 3rd party source into NPM package, do not forget to list 3rd party licenses and copyrights. Most of the open source licenses require author acknowledgment.

Also, it is a good practice to specify a valid SPDX expression in your package.json license. I believe this field must be mandatory for publishing on npm.org.

How you figure it out

Many teams start thinking about licenses when the software is ready to ship. I’ve been using ScanCode utility for this. It really goes to every folder of your project and trying to detect every license or copyright.

Screenshot from https://github.com/nexB/scancode-toolkit

You probably have to use this or similar tool before distributing your app. Make sure that you are checking enough and not too much:

install all your production dependencies before running the tool
make sure devDependencies are not checked by the tool; normally you do not distribute with your development dependencies;

Note: if you are, like me, looking into package licences after you integrated package into your app, you may find yourself in a difficult situation.

Running ScanCode just before deadline; image from https://giphy.com

How you figure it out before it’s too late

I was wondering, when is the best time to learn about package dependency licenses. For me, the normal flow of discovering packages is:

🔍 Google 👉 npm.org 👉 GitHub 👉 $ npm install

Unfortunately npm.org is not really addressing transitive dependencies. There are web tools like http://npm.anvaka.com/; but it doesn't fit my package discovery flow and I keep forgetting to use it. I thought that the best moment to learn about package dependencies is when you type $ npm install <pkg>

That was my thinking when I built a CLI tool called npm-consider which analyses package with all transitive dependencies before installing or even downloading it.

To save one command for you, it wraps $ npm install and has the same arguments. If you are fine with dependencies just choose Install and it will run npm install as usual. If you are concerned pick Details and see whole dependency tree: