I’m going to start the blog with an example, but for that we’ll need to jump back to 2005. Security specialist Fortinet faced accusations of violating the GNU General Public License (GPL), bringing the challenges of open-source licensing into the spotlight.
A court injunction banned Fortinet from distributing its products until it complied with the GPL and the company agreed to a settlement. As part of the agreement, Fortinet provided the source code of the Linux kernel and other GPL-licensed components to anyone who requested it and amended its licensing terms to include the GPL’s requirements. Essentially making part of their product open source.
Although by sharing code freely, developers have created communities around software development, at the core is the challenge of keeping it free & open. And this is where the GNU General Public License (GPL) comes into it. But what makes the GPL so controversial, and how does it fit into the larger discussion about open-source software?
Let’s jump in.
What Is the GNU General Public License (GPL)?
The GPL, introduced by Richard Stallman in 1989 as part of the GNU Project. And in their own words…
“Free software means the users have the freedom to run, copy, distribute, study, change and improve the software… think of “free” as in “free speech,” not as in “free beer.”
Unlike licenses such as the MIT License or Apache License, the GPL imposes strict conditions to prevent control over any solutions created. Its defining feature is the "copyleft" principle, which means that anything created from GPL-licensed software should also be under the same license.
What are the pros & Cons of GPL Licensing?
The GPL is one of the open-source community’s legal tools. It’s all about keeping software free and making sure nobody restricts access to it. But as great as that sounds, it comes with its own set of challenges.
On the plus side, the GPL is fantastic for ensuring software freedom. This creates a level playing field where no one can take open-source work, make it better, and then slap a "proprietary" label on it. Another big win is collaboration. The GPL boosts community projects, it works the same as saying, “If you improve it, share it.”
But let’s not gloss over the flip side. For businesses, the GPL can be a double-edged sword. The most common complaint is that it’s restrictive. If you use GPL-licensed code, you’re obligated to open-source your own code if it’s considered derivative. For companies, that’s a non-starter. Nobody wants to accidentally share their trade secrets with the world.
Using GPL libraries in a closed-source product can be tricky. In some cases, it’s simpler to avoid GPL-licensed software altogether rather than risk the headache of compliance.
Auditing your software & external package licenses
The GPL's complexities are part of a broader issue. As a developer you need to get into the habit of auditing, understanding and managing the licenses of external packages used in your software.
License audits might not be exciting, but they can help you avoid headaches down the line. Using just one dependency with a restrictive license, like the GPL, could force you to open-source parts of your code you’d rather keep private. Then there’s the web of hidden dependencies to think about. When you bring in one package, it often pulls in others, each with its own license. Skipping an audit could mean missing something important buried in that tangle. Taking the time to check your licenses can save you a lot of issues before the project goes live.
How to conduct a license audit
Manual Checks
Let’s be honest here, manually reviewing the licenses of all dependencies in your project is theoretically possible but impractical. Large applications often rely on hundreds of libraries, each with its own set of dependencies. This makes manual audits time-consuming, error-prone, and unsustainable for long-term projects, unless you need to torture a new intern.
Automating the Audit Process
Luckily, for both you and interns, there are tools designed to streamline license audits. Because as always, someone has already found a solution to the problem. As I’m more familiar with Node.js, I’ll use that as the basis for the examples.
In Node.js, we have a few choices. Dependency managers like npm and Yarn speed things up for us. Yarn has the yarn licenses list command, this creates a report of all your dependencies. Running yarn licenses list will create something similar to this.
**
_yarn licenses v0.14.0
├─ abab@1.0.3
│ ├─ License: ISC
│ └─ URL: git+https://github.com/jsdom/abab.git
├─ abbrev@1.0.9
│ ├─ License: ISC
│ └─ URL: http://github.com/isaacs/abbrev-js
├─ acorn-globals@1.0.9
│ ├─ License: MIT
│ └─ URL: https://github.com/ForbesLindesay/acorn-globals.git
├─ acorn@2.7.0
│ ├─ License: MIT
│ └─ URL: https://github.com/ternjs/acorn.git
├─ align-text@0.1.4
│ ├─ License: MIT
│ └─ URL: git://github.com/jonschlinkert/align-text.git
├─ amdefine@1.0.0
│ ├─ License: BSD-3-Clause AND MIT
│ └─ URL: https://github.com/jrburke/amdefine.git
├─ ansi-escapes@1.4.0
│ ├─ License: MIT
│ └─ URL: https://github.com/sindresorhus/ansi-escapes.git
├─ ansi-regex@2.0.0
│ ├─ License: MIT
│ └─ URL: https://github.com/sindresorhus/ansi-regex.git
_
**
However, in some cases you might need to rely on third party tools. This is especially true If you’re using the npm package manager. Three examples here could be: license-checker, legally, npm-license-crawler.
How to use license checker for auditing licenses
If you need to use a third-party tool, license checker is a good choice & here's how you can get started. Start by running,
_**
npm install -g license-checker
mkdir foo
cd foo
npm install yui-lint
license-checker
**_
This will produce a detailed report of all the dependencies in your project, including their licenses. Each entry in the report provides information about the package name, version, license type, and repository URL. This is especially useful for identifying dependencies that may have restrictive licenses, such as those under the GNU General Public License (GPL).
If you’re managing a project with a large number of dependencies, you may want a summary of license types rather than a detailed breakdown. Here you can run --summary.
I would also go one step further and save the file as a BOM.txt to make it easier to reference later. Here you can just run: license-checker > BOM.txt
Why you should be taking a proactive approach
Checking for licenses can become a headache at time, so for fewer surprises down the line, consider adding License Checker to your CI/CD pipeline. It’s a simple step that keeps an eye on your dependencies and flags any problematic licenses early on. And it’s something I’ve implemented in my work at Inspeerity - Custom Software Development Company. That way, if an issue pops up, you can tackle it right away before it spirals into more issues.
When it comes to managing licenses, it’s all about being proactive. Start by making sure everyone on your team knows the basics about licenses, especially the tricky ones like the GPL with its "copyleft" rules. Clear policies go a long way.
Keeping good documentation helps, too. Maintain a Bill of Materials (BOM) for each project. This lets you track what licenses you’re working with and makes future audits easier. Pair that with automated license checks in your CI/CD pipeline, and you’ll have a solid system for catching issues early.
Conclusion
The GNU General Public License has been an important part of open source solutions , but it’s definitely not without its issues. “Copyleft” can make life tricky for businesses trying to stay competitive. The key to navigating this? Understanding how licenses like the GPL work and using smart tools and practices to manage them.
That’s where proactive license audits come in. Tools like License Checker can help you spot potential problems, keep your projects compliant, and make sure everything stays above board. Whether you’re all-in on open source or just trying to steer clear of legal headaches, make sure you stay on top of what licenses you are using.
Top comments (0)