Open source license compliance isn’t glamorous. It has little to do with cranking out code. It’s a messy, nuanced undertaking that is in no way amenable to a simple technical fix. But it’s something we ignore at our peril.
Any open source user – or community – that fails to take software license compliance seriously is risking serious harm. It’s worth reminding ourselves why that is, and what we can do about it.
Two Kinds of “Free”
The trouble starts with the notion that open source software is “free.” True, it doesn’t cost money to acquire. But “free” here doesn’t mean free of obligations, or consequences, when you use it. It means free under the terms of the license.
Every piece of open source software — small or large — carries with it a license that tells you how you can use it, and where you can use it, in a compliant way. These licenses differ from each other, granting specific rights and obligations, and you automatically inherit them when you use that particular piece of software. These are rights and obligations that you may, or for all kinds of reasons may not, want to inherit. And you inherit those obligations whether you know you are using that piece of software or not. “I didn’t know” isn’t a valid excuse or reason for noncompliance.
For one thing, licenses come with stipulations related to use. Let’s say you’re planning to use a library issued under the GNU Lesser General Public License. That’s generally allowable. But if you link statically against this license, there are additional requirements that you need to fulfill in order to be compliant with it. Those may or may not be requirements you find acceptable.
It’s not just how you will be using software governed by an open source license that matters. You might be comfortable shipping a product that relies on software issued under a GNU Affero General Public License (AGPL). But if your customers use that product to provide a web interface to their customers, they will likely be responsible for AGPL compliance too. So they need to know what licensing you are committing them to.
Moreover, even when you are comfortable with the requirements accompanying a particular piece of open source code, you are typically pulling in a host of open source sub-components that could have been issued under different licenses that would then place you under a different set of obligations. At the bare minimum, your use of those sub-components requires acknowledgement, but it will also have implications for the reliability, security, and legality of whatever it is you are using that software to do.
Unfortunately, we have come to build applications in ways that deliberately obscures this uncomfortable reality. Modern app development is designed to make it easy to get complex things done, which it does by hiding all the dependencies that you are actually pulling into your system.
The Risks of Non-Compliance
But what’s the worst that can happen if you fail to acknowledge or conform to the license requirements attached to a piece of “free” open source software?
Most obviously, there are legal ramifications to ignoring the obligations you have effectively agreed to abide by, and that anyone using your software takes on. At the very least, it creates a potential legal attack surface for anyone looking to cause you competitive harm. Beyond that, non-compliance can impact project timelines, drive expensive do-overs, and cause reputational damage.
There are also very real security risks to pulling in software unknowingly. By definition, if you don’t know what technologies underpin the solutions you are building, you can inadvertently pull in software with security flaws that you’re not aware of.
Even if the technology is reliable, your ignorance is dangerous. You might assume, for example, that the libraries you are using don’t listen to the network and that you therefore don’t need to do a network analysis. But if one of the libraries you’re pulling in actually does listen to the network, you will have misjudged your risk profile and failed to protect your software in response.
What to Think About When You Think About Compliance
There are three basic questions you need to ask to avoid issues with software license compliance:
- What open source components am I ingesting and incorporating into my software? This includes confirming that the software you are using really is open source. If you aren’t sure, the open source community has established a body of work that defines what valid open source licenses are.
- What specific licenses are attached to the code that I am using and what do they require me to do? This extends beyond the “top level” open source software that you are working with. You need to think all the way down your dependency tree to understand all of the terms and conditions that you are accepting.
- Can I be compliant with those terms in a way that doesn’t harm the rest of my objectives for that software? You are clearly at risk if you are out of compliance, but being in compliance might also be problematic for the use case you have planned for the software.
But We Can Automate This, Right?
It’s tempting to think this can be solved with some kind of script or tool. Unfortunately, that’s just not the case.
You can certainly use tooling and automation to help you discover what licenses you are subject to, but then you need to understand the implications and consequences of those licenses, as well as the context in which the software you’re building will be used either upstream or downstream. How do you intend it to be used? And what are all the other ways in which people might conceivably decide to use it after you have shared it freely with the world?
Your answers here are going to be matters of nuance and interpretation. That makes it imperative to get a human brain involved, inspecting the licenses, imagining uses, and weighing possible scenarios that extend beyond the technical into social, legal, and commercial realms.
The Right Way to Approach Open Source License Compliance
If this sounds like messy, unglamorous work, it is. But that doesn’t make the work of license compliance any less important. So what’s the best way to approach it? For anyone working on open source in a corporate setting there are three dimensions to think about here:
Legal: Most immediately, developers need to know whether or not they are in compliance and what that compliance (or non-compliance) requires them to do. To that end, companies contributing to open source software can ensure their legal teams have relevant expertise in open source licensing. If their internal lawyers don’t have that expertise, they should be prepared to bring in help from the outside as needed.
Process: In the longer term, someone needs to own compliance. Call it “open source usage,” or “engineering excellence,” but it should be someone’s job to build and maintain the escalation paths for resolving compliance issues arising from any contributions to open source within the organization. Even though open source technologies invite ignorance by “just making things work,” they are in reality highly complex systems and need to be treated as such.
Culture: at the most basic level, organizations working with open source software need to nurture developer cultures that care about compliance. They need to create the expectation – and requirement – that people take responsibility for every component that they are pulling into their products.
No one needs to reinvent the wheel here. If you are starting from scratch, the Linux Foundation’s TODO Group is an excellent starting point. Run by people who themselves manage open source programs, the group offers a variety of guides, meetings, and discussion channels dedicated to helping open source projects work effectively, including how to approach license compliance.
You can also check out this presentation by VMware’s Open Source Community Strategy lead Dawn Foster on other types of open source risk assessments (Dawn is a member of the TODO Group’s Steering Committee). If you are interested in learning more about open source risk beyond license compliance take a look at Dawn’s blog posts about risks related to leadership/governance, community, contributions, and license changes.
In Conclusion
What none of us can do is ignore the centrality of license compliance to the health of the open source ecosystem. Willful ignorance of the licensing terms we take on can (and typically will) come back to bite us in all kinds of unpleasant ways. Using, and then contributing to, open source software really is a fantastic deal for everyone involved, but only if we abide by the terms under which our fellow developers have generously shared their work.
