Who Owns Your Packages?

Introduction

Software Package Managers (NuGet, Maven, Bower, npm, etc.) are a pretty established concept, and there are a lot of reasons why organizations would want a private repository. SimpleTalk's Taking NuGet to the Enterprise identifies a lot of these reasons in detail, but licensing is often the most overlooked, and one of the biggest gotchas.

First, the obvious: software is copyrighted material. When authors create software, they own its copyright (unless they put it in the Public Domain, which is rare), and that means they decide how others can use it through licensing. This is where License Agreements comes in: they spell out restrictions for using software.

License Agreements are legally-binding contracts, and when you use or otherwise incorporate a freely-available package into your applications, you are agreeing to a contract with the author of that package. But it's not necessarily you personally; if you're building this software for someone else (such as your employer), you are agreeing to a contract on their behalf.

Since anyone who owns a copyright can decide how they want others to use their property, there are a tremendous number of different license agreements out there. Including our own BuildMaster Licensing Agreement, which, by the way, we keep under 300 words and in plain English.

To keep things simpler, most free and open source packages are licensed using one, of hundreds, of pre-written, templated agreements. Some of these templates are well-documented by the Open Source Initiative, some are based on one of these well-documented licenses, like the BSD, and others are just... different. Like the WTFPL or the beerware agreement. A quick look at Nuget.org,npmjs.com, etc., and you'll find all types.

Copyleft Licensing

Although all licenses put some restrictions on how you can use a package, some licenses are considered Copyleft. The most famous of these is the GNU General Public License (or GPL), which requires that any software that using a GPL package must also be licensed as GPL, and make its source code freely available.

By using a freely available package, you are legally binding your company to its specific licensing agreement.

No one is exempt from inadvertently binding themselves to an agreement. Right now, there is a continuing lawsuit against VMWare, and in the past even Cisco had run-ins with GPL violations. Sony even went so far as to recreate software functionality to avoid the GPL license.

Avoiding License Headaches

One of the key features of a private repository like ProGet (or Nexus, Artifactory, etc.) is to be able to filter or approve freely-available packages. It's through this feature that you can avoid being stung by license agreements in packages.

There are three approaches you can use to accomplish this.

Manually approve each package

This is pretty straight forward, someone qualified (i.e. legal or governance) reads each and every package agreement before developers may use it, and then approve that package for use. The obvious downside of this is that it will take a massive amount of time, and thus will effectively encourage developers not to use packages.

Automatically scan each package's license agreement

Most packages have a license agreement URL that points to the license you're agreeing to. Sona Nexus can actually download the license agremeent and heuristicly scan it to see if its terms and conditions meet pre-determined requirements.

This sounds promising: by bringing in automation, it doesn't matter how many different license types you subscribe to because they've been vetted to meet your requirements. Of course, relying on a machine to read, and then automatically bind your company to an agremeent is problematic.

A great example of this is the RubbishSoft License agreement (or the RSGPL). It's a fun document, and I wish I could tell you to read it but if you did, you would be in violation of the RSGLP! The license is clearly (comically so) NOT a GPL license. However, if you check Nuget.org for the package LongGuid you'll find that Sonatype has classified it as a GPL license.

This license, in fact, is nearly the complete opposite of GPL, yet is worded similarly enough that the heuristic algorithm thinks it's actually GPL! Turns out, a simple "not" in a sentence completely changes its meaning.

Restrict Packages by License URL

This is the best of both worlds. Many of the most common license agreements (MIT, GPL, etc) use the same license URL, because if you're using a pre-written license, it makes sense to use their license page. So a range of specific agreements can be approved, and URLs logged as safe to use.

This approach is used by both ProGet and Artifactory.

In Conclusion

Regardless of the approach you take to filtering licenses, it's still important to carefully read and know the exact provisions of different license types. This will keep you and your development organization safe from inadvertently accepting the RSGPL.