Open source compliance for software vendors comes down to four requirements: build a complete software bill of materials (S-BOM), check which licenses are actually inside the components, meet the license obligations on delivery, and keep monitoring the components you ship for newly known security vulnerabilities.
Key Takeaways
- Anyone who passes software on to third parties becomes a distributor and is bound by the license terms of the open source components inside it, no matter whether the code came free of charge from GitHub.
- A software bill of materials (S-BOM) is already a purchasing requirement in many supply chains, and the EU Cyber Resilience Act is pushing it toward a regulatory obligation for software vendors.
- Every direct dependency in the build system hides an iceberg: for a single in-house module, ten direct dependencies often pull in a hundred more transitive ones.
- License metadata in package managers often does not match the actual license text, so the label on a package is no reliable legal basis.
- For discontinued software without a maintenance contract, the Cyber Resilience Act points toward vendors still having to report security vulnerabilities and fix them if needed, although much of this is not yet settled.
Open Source Doesn’t Mean Free for the Taking
Code on GitHub is not automatically open source, and that is where open source compliance begins. Only an open source license turns code into open source software. Without a license, the code is private property, and you may not use it without the rights holder’s consent.
Dirk Riehle, professor of open source software at the University of Erlangen, compares it to an apple tree in the neighbor’s garden: just because you can see an apple and reach it doesn’t make it yours. GitHub also hosts projects under proprietary licenses. Either way, you have to read what the owner allows.
None of this changes the bigger picture: open source software is usually good software, and it is almost everywhere. Between 80 and 95 percent of the software in a typical product today is open source. It is not a niche topic. It is the normal case in development.
Using Open Source Is Harmless, Distributing It Is Not
If you only use open source software yourself, you usually have no obligations. That is the most important reassurance for anyone who downloads a tool and runs it in-house. An open source license grants you the right to use and modify the software free of charge.
Obligations start the moment you pass the software on to third parties. At that point you become a distributor, and the license terms apply in full. A web server that sends JavaScript code to a browser already counts as passing it on.
This line between end user and distributor decides whether you need to read license texts closely. For software vendors the answer is clear: they are almost always distributors.
Permissive Licenses Ask for Attribution, Copyleft Asks for More
Open source licenses fall into two groups: those with a copyleft clause and those without. Which group a component belongs to determines how much work it takes to use it in your own product.
Permissive licenses such as the MIT license mainly require attribution. You have to state clearly whose code you are using, which means passing on the copyright notices and license texts. You don’t have to disclose your own source code, even if you modified the component.
Copyleft licenses from the GPL family require the opposite. If you build copyleft code into your product and distribute it, you also have to give recipients your own modifications under the same license. The inbound license must match the outbound license.
Riehle stays out of the moral debate about whether disclosure should be mandatory. His argument is pragmatic: the license expresses what the original developer wants.
“Many developers say, I don’t want to force my users to disclose their source code, so they pick a permissive license. And many say, I want to force the people who use my source code to disclose their own source code, so they pick a copyleft license.”
(Dirk Riehle)
Community and Commercial Open Source Follow Different Logic
Two very different motivations sit behind open source projects. If you want to understand why a project exists and how reliably it is maintained, you need to know which one you are dealing with.
Community open source is a joint effort. These days, the work is mostly done by paid employees on behalf of their employers, on components that everyone needs but that don’t set anyone apart from the competition. No company gains anything by carrying that work alone, so the cost is shared among several companies.
Commercial open source follows a business goal. Riehle distinguishes distributors such as SUSE, Univention and Red Hat from single-vendor companies that develop software themselves and release it under an open source license.
The classic example is MySQL, which later gave rise to MariaDB. The vendor made the database available for free as open source and sold a commercial license alongside it. As the rights holder, a company can license its software as often as it likes: the open source license is one, the commercial license is another.
In the open core model, parts of the software are free and individual features cost money. At MySQL, that was a clustering feature that only professional high-end users needed; for a private website the open source version was enough. Today the line often shifts to operations: self-hosting is free, the hosted web service is what you pay for.
What a Software Bill of Materials Is and Why Customers Ask for It
The software bill of materials, or S-BOM, lists every component built into a product. It is the central data structure for using open source safely.
In the build file, developers only see the first-level dependencies, the libraries whose interfaces they program against. Beneath them lies an iceberg. Those direct dependencies have dependencies of their own, and the result is a deep dependency graph.
The numbers are sobering: a single in-house module can have ten direct dependencies with a hundred more underneath. A good build system resolves this graph through package managers, otherwise you couldn’t produce a binary at all. Flatten the graph, and you have the bill of materials.
Today, that list is a purchasing requirement. Customers want to know what is inside the software before they even accept it. In the US, an executive order made delivering an S-BOM mandatory for anyone selling to federal departments. In the EU, the Cyber Resilience Act is heading in a similar direction.
Security Vulnerabilities Are Your Problem, Even If There’s a Vendor Behind Them
If you run software, you have to keep track of what is inside it yourself. The bill of materials only does its job if you keep checking it against newly disclosed vulnerabilities.
Riehle makes the point with a bank. If it runs a product with a vulnerable open source component, as in the Log4Shell case, and someone exploits the hole, it is the bank’s customer data that ends up on the black market. Pointing at the vendor won’t help at that point.
Fixing the problem does go back to the vendor. But in a real incident, you may have to shut the software down if it leaves the door wide open. That is why every end user has to monitor, not just produce.
How Fixes Travel Through the Supply Chain
Software supply chains work like physical ones: software is built into software, which is built into yet more software. When a security problem appears, responsibility works its way back up that chain.
One peculiarity reverses the direction. Ideally, vulnerabilities in open source components are only made public once a fix exists. So the corrected component is already available at the start of the chain before anyone hears about the problem.
From there, the fix has to flow forward. Every user has to update and pull the component from upstream. That quickly gets hard, because the corrected component may no longer be compatible with other dependencies. Across several steps down to the final commercial product, this can take a while.
Discontinued software makes it worse. Many companies run software without a maintenance contract. The Cyber Resilience Act suggests that vendors remain responsible even then: at least inform their customers, and repair if necessary, even when no license agreement is in place anymore. Much of this is not yet settled from a regulatory point of view.
Tools Help, but the Work Stays Manual
Software composition analysis, or SCA, is the category of tools that analyzes what has been built into a product. These tools determine the bill of materials and then monitor it.
Riehle mentions his own SCA Tool, available at scatool.com, as well as commercial vendors such as Black Duck, FOSSA and FossID. The tools were originally built for license checks, and they increasingly cover security as well. The market is moving because regulatory requirements from the EU and from Germany’s BSI keep growing.
There is still no simple solution. No software can look into a data center and produce a complete bill of materials on its own, least of all at the binary level. You first need an inventory of the software you run, often put together by hand, and then you have to work out the bill of materials for each piece of software.
The honest state of things: most companies still have nobody in charge of open source.
Why Metadata Causes the Trouble
What a component says on the label doesn’t have to match what is inside. This is where the biggest cleanup job lies, and AI doesn’t solve it.
A package manager can declare a component as MIT-licensed even though it contains GPL code, which is copyleft code, somewhere in the middle. That happens easily. License metadata is in very poor shape.
Then there is the security problem below the component level. If someone copied an algorithm with a known bug from a source like Stack Overflow into a library, the bug now sits in the middle of the code and is no longer recognized as that known bug. Where such bugs hide is almost impossible to tell until they become public for that specific component.
The industry is trying to fix these problems at the source. So far, every vendor has checked the same open source components and analyzed their licenses on its own, often hundreds or thousands of times in parallel. It would make more sense to do this once, in the open source project itself.
Initiatives from the Linux Foundation and the Eclipse Foundation are working on bringing this inventory back into the projects. The path has been chosen, but it will take many years.
Four Requirements Open Source Compliance Places on Every Vendor
Anyone who uses open source professionally needs four things under control. Riehle sums them up as the core of good open source governance.
| Requirement | What to do |
|---|---|
| Build the bill of materials | Generate the S-BOM with tools only, since customers now require it before they buy |
| Check licenses | Look inside the packages to see which licenses they really contain, beyond the label |
| Ensure governance | Don’t build in software whose license doesn’t fit your own business model |
| Meet license obligations | Generate correct legal notices on delivery, including for JavaScript code you ship |
Riehle sees a concrete risk in the last point. A website that delivers JavaScript code is distributing it and needs legal notices for it. Practically nobody provides them. That is why he expects a sizable wave of legal cease-and-desist letters at some point.
Frequently Asked Questions
Can I use code from GitHub if there’s no license attached?
No. Only an open-source license turns published code into open-source software. If there is no license, the code is private property that may not be used without the copyright holder’s consent. There are also projects on GitHub that are licensed as proprietary software. Dirk Riehle compares this to an apple in your neighbor’s yard: Just because it’s visible and within reach doesn’t mean it belongs to you.
Do licensing obligations apply even if open-source software is used only internally?
Generally, no. Anyone who uses and modifies open-source software exclusively for their own purposes generally has no obligations. The obligations only apply when the software is distributed to third parties, because that makes you a distributor. This line is crossed more easily than you might think: even a web server that delivers JavaScript code to a browser constitutes distribution.
Do I have to disclose my own source code if I modify an MIT-licensed library?
No. Permissive licenses like the MIT license primarily require attribution, that is, the inclusion of copyright notices and license texts. Your own source code remains closed, even if you modify the component. This is different with copyleft licenses from the GPL family: Anyone who incorporates such code and distributes the product must make their own modifications available under the same license.
How do companies make money from software they release under an open-source license?
As the rights holder, a company can license the same software as many times as it wants: once under an open-source license and once under a commercial license. MySQL, from which MariaDB later emerged, is the classic example. In the open-core model, individual features are subject to a fee; in the case of MySQL, for example, this includes a clustering feature for high-end users. Today, the distinction often lies in the mode of operation: self-hosting is free, while a hosted service is commercial.
How many third-party components are actually contained in a software product?
Significantly more than what is visible in the build file. There, a developer sees only the first-level dependencies, against whose interfaces they are programming. Beneath that lies a deep dependency graph: For a single proprietary module, ten direct dependencies are often accompanied by a hundred more. Overall, products consist of 80 to 95 percent open-source software.
Who bears responsibility if a security vulnerability in an embedded open-source component is exploited?
The operator bears the consequences, even if a vendor is behind the product. If a bank runs a product with a vulnerable component (such as in the case of Log4Shell), its customer data ends up on the black market, and pointing the finger at the vendor doesn’t help. While the fix is the vendor’s responsibility, in a worst-case scenario, the software must be shut down. That’s why every end user must monitor the situation themselves.
Can you rely on the license information in package managers?
No. A package’s label often does not match its actual contents: A component may be listed as MIT-licensed, even though it contains GPL-licensed code. The license metadata is considered extremely unreliable. That’s why verification requires looking inside the packages rather than trusting the declaration.
Do software composition analysis (SCA) tools generate the bill of materials (BOM) fully automatically?
No. No software can scan a data center and generate a complete bill of materials from it, certainly not at the binary level. First, an inventory of the software in use is required (often created manually), and then the bill of materials is determined for each software component. SCA tools subsequently identify and monitor these components; they were originally designed for license compliance but are increasingly covering security aspects as well.
