I'm an avid supporter of Open Source software; I maintain multiple projects, contribute to others, and sponsor developers across numerous projects I use or care about. However, there has been a recent trend in license changes with open source software that create a unique and real risk to companies and development teams that could go unnoticed and result in a catastrophic impact on organizations. Let's explore how we select, integrate, and manage the usage of third-party solutions.
Acquiring New Libraries
When we first look to import a library, NPM, NuGet, or otherwise, it is generally understood that we need to review the product and the license terms associated with the product and ensure that we have met all compliance requirements of utilizing the software. This is just good business and something that you should be doing before you use anything to ensure you do not bring in something that will get you in trouble.
NuGet makes this easy in the package explorer, allowing you to navigate to the license file for any particular project quickly. For NPM, several tools may be utilized to locate this information.
The Risk - License Change at Update
My biggest concern with library license changes is the risk introduced to consumers when the update is a previously vetted project that changes the license. When updating packages, license changes are NOT presented to you in NPM or NuGet, so it is easy to accidentally consume an update that would change your liability. Suppose you update packages to the latest version without manually checking all release notes and license files. In that case, you may inadvertently adopt a version of a product now bound by a different licensing scheme.
This situation would happen today to users of a popular library in the .NET ecosystem. Versions before a set number are open source, and permissive usage is allowed. Versions after a set point of the same package require a per-developer license for all users for anything that isn't open source or personal project development. Although you only know this if you manually review the notes, you are LEGALLY bound by the license change, even if you didn't do what you should have done.
Mitigating the Risk
I strongly advocate that all development teams implement a strategy for managing package updates. This strategy should involve reviewing the changes, reviewing the licenses, and, at minimum, understanding whether your liability has changed regarding the consumption of the new version.
I hope that at some point in the future, NPM, NuGet, and otherwise can help call attention to these critical changes, but at this time, it falls on the developers, and the risk is real, so please do be careful with your projects. You don't want to be that company that gets caught using a product outside of the license.
Supporting Open Source Is Key
I would be remiss if I didn't acknowledge that I fully understand WHY a maintainer may move the license model of their project. They have the right to do so, and managing open-source software is a thankless job. If you are a user of an open-source project, try to support the project in whatever way you can. From testing and contributions to sponsorship or otherwise, anything helps keep open source viable and sustainable, with the ultimate goal that an open source project with permissive licenses can remain open if there is support to help keep it moving forward.