GPL-3: Hidden Danger in Your Code
by Lauren Camacci, on Aug 5, 2020 8:33:36 AM
We've all done the glassy-eyed speed-scroll to the end of a license agreement and clicked "I accept" without even reading it. It's hard not to! Written in legalese and tedious to read, they're destined for the quick skim. But just because you didn't read the license doesn't get you out of following the terms. Who has the time or resources to deal with the mess of noncompliance? Nobody.
Below, we discuss what the GPL-3 license is and some of its real-life consequences, and the misconception that it won't impact your organization, because you don't "distribute" software ("we just provide SaaS"). With a tool like ProGet, keeping these unwanted licenses out of your code is both easy and automated.
GPL-3: Good Cause, Tough License
As GNU's quick guide to the GPL-3 license explains, the license focuses on free software remaining free. The problem that bites companies on the behind, however, is the requirement that code built with GPL-3-licensed packages must open-source that code.
For any company with proprietary information in their code, this is a nightmare. You might be in an industry where open-sourcing your code is impossible or even illegal. It's a non-starter for most organizations.
Accidentally developing with packages that include licenses and then failing to open-source can get your organization into legal trouble. The noted Artifex v. Hancom decision was an example of a real company paying out real damages for violating the terms of the GPL-3 license. No employee wants their organization to go to court over their code.
Your SaaS Offering Isn't Safe
A common assumption is that offering Software as a Service (SaaS) means that the GPL nightmare won't apply to your organization, because you're not "distributing" the software. But this isn't quite true.
And you know that when you "distribute" software that uses GPL-3-licensed libraries, you need to open-source all of that code. And other licenses, like AGPL-3, are even more strict.
ProGet's License Detection and Blocking Lets You Skip the Headache
ProGet's License Detection and Blocking automatically spots and alerts you to those sneaky licenses, letting you configure a rule to block (or allow) certain license types.
By default, ProGet detects and flags licenses present in package metadata, based on SPDX identifier. It also flags packages missing a clear SPDX identifier as having an "unknown license." This way, the human user is alerted to what needs their attention.
But more than just detecting, ProGet also lets you configure license blocking rules, at both individual feed level and at the global (all-ProGet) level. This means that an administrator can instruct ProGet to automatically reject licenses unacceptable for development.
Configuring this feature to meet your organizational needs automates a tedious manual process and frees your personnel to focus on developing, rather than combing through metadata searching for licenses.
Try it Yourself
License Detection & Blocking are configurable in all versions of ProGet, but in ProGet Free, the blocker will not actually work. If you'd like to try this feature for yourself, you can start a 30-day free trial of ProGet Basic at MyInedo. Check out our YouTube demo of this feature to see how easy to configure and effective license detection and blocking is and how much time and risk it can save your organization.