License Agreements: Who Really Owns Your Packages?
License Agreements: Who Really Owns Your Packages?
Avoid GPL violations when licensing your product with these tips.
Join the DZone community and get the full member experience.Join For Free
Jumpstart your Angular applications with Indigo.Design, a unified platform for visual design, UX prototyping, code generation, and app development.
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.
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.
1. 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.
2. 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.
3. 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.
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 inadvertantly accepting the RSGPL.
Published at DZone with permission of Scott Reece . See the original article here.
Opinions expressed by DZone contributors are their own.