The Unpleasant Surprises of OSS License Changes and How to Avoid Them

Three weeks ago a popular JavaScript tool Lerna underwent dramatic turmoil.  One of the original founders and maintainers of the Lerna project suggested changing the license from the ordinary MIT to “MIT with personal exceptions” in effort to prevent certain software companies, including Microsoft, Amazon, Apple, LinkedIn, Walmart, Target, Tesla, Xerox, Dell, and others, from using Lerna. Other maintainers initially approved this suggestion, and the change was implemented. The good news is that the change was eventually reverted.

Reasons aside, that change created a severe FUD among Lerna users. Some raised their concerns; while others demanded to remove their employer from the blacklist; it was even suggested to stop using Lerna. A number of contributors even demanded removing their contributions from the code, and, of course, someone forked the project altogether. This real-life incident is a good example of this kind of “surprise” you don’t want to experience, and how you could have easily been alerted about it in real-time.

So, why panic?

One could argue that the license change would only apply from that point forward? Couldn’t Dell or Xerox just stick to the current version and avoid using the software with the jeopardizing license? Can’t they lock the dependency version? Well, it all comes down to, did they know they needed to do it. That’s not always the case. The Lerna debacle got lots of publicity, and developers at those companies probably heard about it and locked the dependencies, but what if they hadn’t?

While all of the industry has realized by now that blindly using the latest version is dangerous and should be avoided, most of the developers in the JavaScript world still use the flexible minor and patch version. Let’s take a look a the package-lock.json descriptor of the Lerna project itself (or almost any other software project using npm). Most of the dependencies are declared using the caret range, to automatically select of the latest minor and patch version.

Why should you care?

Now you can see the problem, can’t you? If any of the blacklisted companies missed the news, they were going to violate the terms of the license. Checking the license while selecting your required library and then using ranges to stay up-to-date with bug fixes and minor releases is merely not enough.

How can you protect yourself?

The only way to be on top of the bug fixes and minor versions and to catch license changes or scan vulnerabilities introduced in those new releases is by continuously scanning your entire dependency graph during your builds. Tools like JFrog Xray, provide continuous security and artifact analysis and lets you define policies (like “only known and accept listed licenses. No security vulnerabilities above “trivial” are allowed in artifacts and all the transitive dependencies tree) and then enforce those policies for every artifact uploaded to your Artifact repository during every build.

Once you have that system in place, you can sleep soundly. When the next sneaky license change occurs, the CI pipeline promotion will fail, and you’ll be able to examine your options – switch to the fork, find an alternative, push the maintainers to revert the change (as what happened with Lerna). You are in control.

Xray takes you a step further and lets you generate license compliance reports for all your software at a click of a button.

So, check out JFrog Xray today and don’t let sneaky license changes expose you to dire legal consequences.