When I started working in open source many years ago, I thought it would be the flavor of the month, but it just kept getting bigger and bigger.
Open source is no longer the exception. It’s becoming the rule. It used to be that IP lawyers were only focused on proprietary licensing and patent licensing. And, sure, we still do that. But I think we’ve gotten to the point where understanding open source licensing is a necessary skill set for intellectual property lawyers today.
That’s because, when you look at the tech landscape, an enormous part of both the culture and the footprint is open source, and the contribution margin of open source to all code in production is just getting larger. Essentially every digital product now has open source components. Open source has changed from a niche area to a necessity. Understanding at least the basics of open source license compliance is a core skill for IP lawyers.
One of the key elements of open source license compliance is what’s known as a notice requirement. This refers to documentation that describes the terms under which open source components have been made available to you and your product. Notices are often required to include entire copies of applicable licenses as well as acknowledgements of authors and contributors.
In this blog post, I’ll discuss the importance of open source license notices as well as how automation can help organizations address common challenges related to fulfilling notice requirements.
Watch On-Demand: Demystifying License Notices with Automation
Differences Between License Notices and Copyright Notices
A lot of people get confused about the difference between license notices and copyright notices. A copyright notice — and you see these everywhere — reads along the lines of: “Copyright 2020 Heather Meeker.” If I wrote something and wanted to put a copyright notice on it, that’s how I would do it.
In the law today, copyright notices don’t actually mean a lot. They’re useful and abundant, but they don’t have the legal meaning or carry the legal weight they used to years and years ago. So they tend to be afterthoughts from the point of view of the law. However, because they mention the author’s name or the copyright owner’s name, they serve as a kind of proxy for attribution. That’s very important to lots of people even though it’s not that important from a legal point of view. That’s the copyright notice: the statement with that word “copyright,” the copyright owner, and the year of publication.
A license notice is something quite different. It tells you the terms under which the copyright owner has made the material available to you. That’s obviously much longer than a simple copyright notice. You’ll even see that some licenses say if you redistribute the licensed material, you have to include both:
- The copyright notice
- A copy of the license terms
When you talk about doing notices, you’re mostly talking about license notices, and the copyright notices are often baked into them.
Why License Notices Are Important
For permissive open source licenses, the notice is really the only requirement. If you think about the social contract between the developer who wrote that code and you, the person using it, all the owner of the license asks is that you comply with the notice requirement. Even from a good-citizen point of view, outside of legal concerns, complying with the notice requirement is key.
The notice requirement is also part of the social contract for copyleft licenses, even though they have a lot of other requirements beyond just the notice. But here, you take on significant risk if you don’t do your notices properly because issues and violations are easy to discover and expose.
Notice compliance is the part of open source compliance that’s intellectually the most straightforward but the most complex from a pure process point of view. But you really owe it to yourself and your company to do it right and manage risk. And you also owe it to the community to fulfill expectations and abide by the intentions when the software was licensed as free and open.
Challenges in Assembling License Notices
First and foremost, assembling license notices can be difficult because there can be a lot of them. The sheer volume of open source packages that people use in products today is substantial, and it only continues to grow.
That’s because, as tech marches forward, it’s more and more common to engineer software in such a way that takes advantage of pre-written modules and third-party components. When my clients show me their bills of materials, it’s not unusual for it to include hundreds or even thousands of notices. Just that sheer number of notices means it’s very hard for humans to manage the notice process without automation.
Now, I should explain there are many different ways to go about delivering notices. They range from barely — to extremely — time-consuming. You might deliver multiple separate notice files instead of one big notice file, or you might deliver the notices within source code instead of within binaries.
If you’re building a product that has more than 20 or 30 notices in it, managing notices via human intervention becomes untenable very quickly. And, if you have anything that’s like a Linux system in a product — which many products do — you’re talking about hundreds and hundreds of notices just as the baseline of the operating system, not to mention everything that you’re including in application layers.
Plus, it’s not just creating the notice files in the first place, it’s updating them. This all is very hard to do.
Misconceptions About License Notices
One of the things I hear a lot is a belief that you don’t have to do notices for something that’s only a dependency. That’s incorrect! What matters is whether you are obligated to deliver the notice. And, in most open source licenses, that’s triggered by distribution.
The problem is that, when you use a certain open source component, it will often sweep in lots of other components — and you have to comply with the notice requirements for those, too. So those dependencies create an even bigger information problem than your original bill of materials.
The other topic that has caused a lot of confusion and consteneration — even though it’s wonderful from a tech point of view — is containers. When you pull software in via a container, that container usually has tons of open source software in it. And so you’re obligated to fulfill the obligations for everything in that container, if you’re distributing it.
Particularly in the early days of containerization, there was rampant non-compliance. People were pulling containers down off the web, and they didn’t have any open source notices for them at all. Then they put the open source components pulled from containers in their products and pushed them out the door, resulting in completely non-compliant software.
So the big misconception is that you only need to focus on whatever is on your primary bill of materials and not anything that’s embedded in your dependencies. You’re responsible for complying with the licenses for all the software you’re distributing, no matter who made the decision to integrate it.
Best Practices for Delivering Notices in Source Code
The best thing you can do, as far as notices go, is to deliver source code. When I tell clients this, they’re sometimes a little taken aback, because many open source licenses don’t require them to provide source code. But, in reality, when people use open source software, they use almost all of it completely unmodified from the upstream source, and in that case, there really shouldn’t be any business sensitivity around delivering the source code.
In those cases, the easiest approach is to deliver the source code upfront with your product. When you do that, the notices are baked in — the notice file is actually in the source code. For example, if you look in, say, a GitHub repository, normally the license file is a plaintext file in the top-level folder of the repository. So, if you make the whole repo available, then you’ve already delivered your notice files. Or, if you’re offering your product by download, you can say “click here” for the source code. And then you have fulfilled your requirements.
There are some cases where those options may not make sense. Let’s say you’re delivering the software with limited bandwidth or a slow connection. In that case, delivering the source code may take up a lot of room or time. Then there’s the classic problem with delivering notices in an IoT situation where your product does not have an actual user interface at all. There, you’ll need to have another route to deliver your notices with your product but outside of the UI.
That requires some extra compliance infrastructure to actually fulfill the required deliveries under the licenses.
How Automation Simplifies Compliance with Notice Requirements
You should always use automation if you can, even if you’re at a small company. License notices are usually an information problem, not a legal problem. Once you establish processes for compliance and for actually delivering the notices, then you’ve effectively removed most of your burden of dependence on lawyers. It’s just execution at that point.
This information problem expands quickly as your business grows. Even if you can handle your notices today with your 20 open source components, one day soon you will not be able to handle it manually anymore, for any number of reasons:
- Multiple SKUs
- Regular updates
- Products getting bigger
- More third-party components
- Acquisition of new teams and software
You need automation! If you’re not automating now, you're just in an interim stage before you use automation. It’s just a question of what tool you're going to pick.
There are a few things to consider when making your decision. Does the tool do the level of checking you need? There is a wide variety of tools out there. Some look for license notices and copyright notices but don’t find cut-and-paste errors or really check against ground truth at all.
On the other hand, a more sophisticated tool like FOSSA will actually not only automate the audit as part of your existing engineering and legal workflows, but also help you figure out if someone has made a mistake somewhere.
The second thing is usability. I can’t tell you how many times my clients have gone out, gotten a tool, and found it so difficult that they stopped using it. That’s a waste of money and time. When you go down that route, what you’re communicating to your engineers is that you don’t care about their time or their priorities. Keep in mind that, for engineers, compliance is kind of like paperwork. Having a bad experience can actually lead to even less compliance in your organization.
Ask yourself (and your stakeholders!): Does this tool do what I need it to do, and is it user-friendly enough to get the people I rely on to also do what I need them to do?
Watch On-Demand: Demystifying License Notices with Automation
FOSSA Editorial Team Note: Although the preceding content was written by a lawyer, it should not be considered legal advice. If you are seeking legal advice, we strongly recommend you speak directly with a lawyer.
