Last month, FOSSA hosted leading open source licensing expert Heather Meeker for a webinar on OSS license compliance tools. Toward the end of our presentation, Heather fielded questions from attendees on several pressing issues related to license compliance.
The questions covered a range of topics, such as:
- Triggers for distribution
- SBOM export formats
- The AGPL
- Containers and license compliance
In this blog, we’ll highlight notable parts of the Q and A session. To access the complete Q and A, along with Heather’s insights on OSS license compliance tools, please reference our on-demand webinar: The Lawyer’s Guide to OSS License Compliance Tools.
About Heather Meeker: Heather is one of the world’s foremost legal experts on open source software licensing and compliance. She’s authored the go-to book on the topic, Open Source for Business, and is a General Partner at OSS Capital.
At the end of the day, what are the real risks of not complying with OSS license terms? I know the answer depends on the license involved, but it seems quite difficult to locate cases, case law, or otherwise where a customer was really dinged for non-compliance.
Meeker: This is an interesting question, and one that comes up all the time. And, I actually recently published a guest blog with FOSSA related to it.
It’s correct that there is almost no case law, but that doesn’t tell the full story. When you ask this kind of question, you’re looking at open source as a traditional IP risk, which is the way it has generally been viewed. It’s not wrong to view it that way. But I think open source needs to be considered more as an ESG kind of risk.
That’s because the kinds of risks that result from open source non-compliance tend not to be lawsuits. There is a fair amount of informal enforcement, and it’s almost always done privately, so you wouldn’t hear about it. The lawsuits are absolutely the tip of the iceberg, even more so than in other forms of IP, like patents and so forth.
But also there are additional consequences of non-compliance. These include loss of reputation, difficulty recruiting, problems in employee relations with engineers, and just generally not being considered a good citizen in the community. If you don’t care about open source compliance and your employees know that you don’t, that reputation is going to spread very fast, and it’s going to prevent some people from working for you.
Now, how do you measure that? It’s very difficult. And it’s similar to an ESG type of risk like a privacy problem or doing business in ways that people think are not ethical. It results in a loss of reputation that is very difficult to quantify but often very serious.
Ultimately, there are real risks, they just don’t tend to be the kind that can be resolved with money in the way that lawsuits are. And, in a way, that makes them a little bit trickier to resolve.
What does distribution (in the software context) mean, exactly?
Meeker: Distribution is a right under U.S. copyright law, but it’s not actually defined.
The copyright act allows copyright owners to exclude others from doing enumerated things: copying, preparing derivative works, distributing, publicly performing, and publicly displaying. But that “distribute” right is actually not defined. If you want to define it, you have to look at the legislative history of the 1976 Copyright Act.
If you do that, in my opinion, it has two elements:
- A copy is being transferred
- The copy is transferred to someone else
What this means is that you have to actually deliver something — and it has to be delivered to someone outside your corporate organization. That’s why we say, for instance, in SaaS, most software isn’t distributed. However, in the case of software that executes client-side — and is used by customers outside of your organization — copies of that software are being transferred, and that would constitute distribution.
Now, there are many edge cases in modern computing having to do with cloud computing, private, public, and hybrid clouds, air-gapped systems, kiosks, and more. So, there are some situations where it’s unclear if the software is distributed. But, for most use cases, we have a pretty firm general understanding of whether the software is being distributed.
Another question that comes up when we discuss distribution is: If you hire engineers to do development for you, are you distributing software to them? I think the answer to that is mostly “no,” but there’s actually some controversy around it.
In the case of SaaS deployment, if the open source components were not distributed, do we really need to clear those to be compliant?
Meeker: You at least need to look at the network copyleft licenses like AGPL. Because even with SaaS, you could have source code sharing requirements under a license like AGPL. And it’s not just AGPL, by the way — there’s a list of about a dozen of those network copyleft licenses, though AGPL is by far the most common one.
When requesting an SBOM from a vendor, is there a standard format that should be requested?
Meeker: There is a standard format called SPDX. It’s an XML format, and it’s a very simple format. It lists a component along with a standard identifier for the license, like a code. Some customers will actually insist on getting SBOM information through SPDX. But even if they don’t, it’s a good way to aggregate information because it’s a standardized format. It’s not terribly difficult to use, either. SPDX is probably the gold standard.
Typically, with your larger clients, who in the organization owns the day-to-day of OSS license compliance policy development and enforcement? Legal, R&D, or others?
Meeker: Open source compliance should really be owned by engineering. This is because the engineers who are putting together a product are continuously making decisions about their software bill of materials. They’re making decisions about security, and code quality, and maintainability, and so forth, and licensing is only one of those elements.
What compliance tools do is tell engineering that they are free to make decisions on using open source components — within certain licensing guidelines. The point of compliance tooling is to free engineers to do what they want to do on a technical level without causing legal compliance problems.
Ideally, your day-to-day compliance workflows should be designed so legal teams are only brought in to handle outliers. The lawyer should not be controlling this process. They should be your counselors when you have an issue that needs to be looked at. When you view compliance that way, it’s usually much more successful.
Ultimately, it’s important that legal does not become a bottleneck to engineering development because then your compliance process will probably fall apart. Part of this also relates to the usability of your organization’s license compliance tooling. I have honestly had clients that bought compliance tools and never used them. The reason they never used those tools is that the tools were not very usable. User-friendliness is huge. You need to make it easy for engineers to use the tools. If you don’t, your compliance process will never get off the ground.
You’ve noted that engineering should lead the open source compliance function. But the impact of non-compliance potentially falls on the legal department — problems in M&A, breach of open source software warranties, and so forth. Given that dynamic, do you have any suggestions on how to convince engineering of the need for an OSS compliance program beyond the bare minimum of checking for security risks from open source components?
Meeker: I ran into this just the other day, where an engineering team had not followed policy and included an open source component that was dual-licensed, meaning it was available under AGPL and a commercial license. And, given the way they used it, they could not comply with AGPL, because it was integrated with their proprietary code.
For dual-licensed products, this is a common issue. The good news is that it can be solved with money because dual licensing means the licensor is willing to grant you an alternative license.
What you need to communicate to the engineering organization is that the cost of resolving the licensing issue goes against their budget. It doesn’t go against some kind of general overhead budget — the issue was created because of the way the product was engineered. Likewise, if you integrate something that’s, say, under GPL, and it’s not dual-licensed and you can’t comply with GPL, then the re-engineering work to replace that will go against the engineering budget, too.
So, I think the way to set up the right incentives is to emphasize that mistakes in compliance are going to come out of their budget and their timeline. It should not be that you’re just not going to solve the problem, because that’s wrong and also irresponsible. And, the fix needs to come out of the budget of the gatekeeper for avoiding problems.
Do you believe there is an actionable difference between dynamic and static linking with regard to GPL?
Meeker: It’s not so much whether I believe it. It’s whether the Free Software Foundation (FSF) believes it. And they believe there is no difference. In other words, if you build an executable with GPL code, everything in that executable needs to be GPL.
Now, if you go back about 15 or 20 years, you had lawyers saying that dynamically linked code wasn’t covered by GPL. And, while that’s an interesting legal argument, it’s not industry practice.
So, the question isn’t really about what the law is — I actually believe there’s a lot of support for the notion that dynamically linked code isn’t included. But that’s not the practice that the industry at large has adopted. The industry at large has adopted the rule enunciated by the FSF, which is that everything in a GPL-licensed executable needs to be GPL or GPL-compatible, and you can’t put proprietary code in it.
Where this really comes to roost most of the time is in the Linux kernel, which is basically a monolithic executable process. And so the rule that comes from that is no proprietary DLLs (dynamically linked libraries) in the kernel space.
Should we choose a commercially licensed tool to manage open source license compliance? Or, should we use an open source tool?
Meeker: It depends on how you plan to use the tool. One of the main open source tools for license compliance management is FOSSology. This is a great tool, and it’s free, but it does have limited functionality. I often see companies use open source tools when they’re starting the audit process and want to take a first pass. So, while they’re in procurement for a commercial tool, they want to find the really obvious problems, and they use an open source tool to do it.
For context, the way FOSSology works is that it goes through source code and finds copyright and license notices. So it’s not comparing against outside ground truth at all. It’s engineered in a completely different way from most commercial tools. It doesn’t do what the commercial tools do, but it does what it does very nicely, and it is a community tool. So, it’s a nice resource, particularly if you’re doing a first pass.
If you find an open source tool that has all the functionality you need, that’s great, but it’s also unlikely because tools are very difficult and expensive to develop and maintain. So, honestly, open source applications that are robust in that way are generally rare, including for compliance processes.
Do you think the OpenChain ISO standard is sufficient for real-world compliance? Many consider it too lightweight.
Meeker: The people who developed OpenChain did an absolutely fantastic job. It’s one of the most professional, thoughtful projects out there. So I have to give kudos to them.
But I would say that it is considered kind of a baseline standard. I know that what they wanted to do was create something that was not difficult to comply with, because if they set the bar too high, people would not use it. So there's a lot you can do in addition to OpenChain.
What I tell people is if you want to show your customers that you are being compliant, you adopt OpenChain. Because it is a signal that you care and you’re doing the work. Some customers will demand much more from you than it requires, and they'll demand more from you than the open source license requires, and those are business issues and community issues. But I think OpenChain was intended as a baseline, responsible standard.
We now use more Docker containers, where there’s a long list of open source components. Do we really need to clear all these layers, or is the application layer more than enough? Do you have any suggestions to handle these components?
Meeker: I would say always get your container from a reliable source. Docker containers have been a fantastic technical development, but they were an open source license compliance nightmare, at least initially. Once you have the container, you can’t really tell what’s in it, and, usually, the containers did not have proper license notices.
So, what I suggest to my clients is either to build the containers on your own so you know what’s in them or get them from a source that you’re willing to rely on from a commercial point of view. And that source should provide you with all the proper license notices and access to source code. I’m sure that’s not the answer people want to hear, but you can’t just ignore compliance because of containers. Containers actually introduce a tremendous amount of information that you have to process. So, you either rely on someone else to process that information, or you do it in a homegrown way.
What are some of the issues that could arise in a custom Linux development scenario?
Meeker: For custom Linux, you need to be very careful about ensuring that everything you are putting in the kernel space is GPL or GPL-compatible. And I’ll highlight one modal case just to illustrate how problems arise.
You’re writing custom operating system code, and you’re trying to solve a problem. So, you go on Code Project and find a great piece of code that would solve your problem. And you put it in your product. Well, now you have a problem because the code there is under a license that’s not GPL-compatible. That’s what I refer to as a cut-and-paste error. Those are the biggest problems you have with Linux development.
In a way, Linux development is easy from a compliance standpoint because everything in the kernel space has to be GPL — don’t spend time arguing that it shouldn’t be, because it’s not worthwhile. But you do have to clear everything that’s going into your custom development as compatible with GPL.
