Open source software is everywhere. It sits inside commercial products, enterprise platforms, consumer applications, and the internal tools your development team assembled last quarter. Most businesses use it without a second thought.
Open source is not free from legal obligation. Every component carries a licence, and every licence carries conditions. Use the wrong component, manage it the wrong way, or fail to track what your developers are pulling into your codebase, and you are not just taking on technical debt. You are taking on legal risk.
Here are the risks that matter.
Licensing Non-Compliance
This is the most direct legal risk, and it is more common than most businesses realise. Around 22% of open source components carry copyleft licences, the most well-known being the GNU General Public Licence (GPL). Copyleft licences come with a specific obligation: any software that incorporates or distributes a GPL-licensed component must itself be released under the same licence. For a commercial product, that can mean being legally compelled to open-source your proprietary code.
This is not a theoretical risk. Microsoft’s Hyper-V drivers serve as a real-world example: because GPL-licensed binaries were included in a binary repository shared externally, Microsoft was required to open-source those drivers. If it can happen to Microsoft, it can happen to your business. Without a formal policy governing which licences are acceptable and how components are used, your organisation may already be in breach without knowing it.
Intellectual Property Exposure
When developers have discretion over which open source components to adopt, and most do, they are making licensing decisions without necessarily understanding the IP implications. A component introduced for convenience may carry licence terms that conflict directly with your organisation’s proprietary interests or its distribution model.
Without a structured approval process, there is no checkpoint between a developer adding a dependency and that dependency creating an IP liability. The result is a codebase that cannot be audited, licences that cannot be enforced, and exposure that grows with every new release.
Incompatible Licence Selection
Not all open source licences are compatible with each other, and not all are compatible with commercial use. Using a component under a licence that conflicts with how your software will be used or distributed is one of the clearest routes to legal action from a rights holder.
Licence incompatibility is a known deal-breaker in open source adoption, yet it remains one of the most consistently overlooked risks. Businesses focus on functionality. Licences get treated as paperwork. By the time the incompatibility is identified, the component may already be embedded in a product that is in distribution.
Lack of Formal Policy as a Legal Vulnerability
Organisations without a formal open source policy are not simply disorganised. They are legally exposed. A formal policy typically covers which licences are approved for use, how components must be documented, and what approval is required before a new dependency is introduced. Without one, every decision is ad hoc, and ad hoc decisions create inconsistency, gaps, and liability.
Smaller organisations face a compounding problem. Larger businesses are more likely to have internal legal teams with familiarity in open source licensing. Smaller ones are not. The practical consequence is that the businesses with the least capacity to absorb legal risk are also the least equipped to manage it.
Developer Discretion Over Legal Oversight
In practice, open source licence management in many organisations falls to whoever takes an interest. In some cases, a single self-designated expert handles it informally, without organisational backing, training, or a defined process. That is not a compliance function. It is a single point of failure.
When licensing decisions rest on individual discretion rather than policy, new dependencies are added without scrutiny, obligations go untracked, and the organisation has no reliable picture of what it is actually running. Legal blind spots accumulate quietly until something forces them into the open, usually a claim or a distribution dispute.
Supply Chain Licence Propagation
Open source dependencies are rarely simple. Each library brings its own dependencies, and those bring more. An organisation may directly adopt a permissively licensed component and, several layers down in the dependency tree, unknowingly inherit a copyleft obligation attached to something it never consciously chose.
Without a Software Bill of Materials (SBOM) and continuous monitoring, these obligations are invisible. The organisation does not know they exist until it is in a position where they must be addressed, typically at the worst possible moment, such as before a product launch, acquisition, or distribution agreement.
Binary Repository and GPL Risk
Storing GPL-licensed software in a binary repository that is shared externally is not a safe workaround. It may trigger an obligation to open-source the entire repository. For a proprietary software vendor, that is not a theoretical inconvenience. It is a serious commercial and legal risk that could fundamentally alter the value of what you have built.
This is precisely what the Microsoft Hyper-V situation illustrates. The mechanism that creates the obligation, sharing externally, is routine for organisations that distribute software or share builds with clients, partners, or contractors. Many do not realise the GPL applies in these contexts.
Absence of Legal Counsel in Smaller Organisations
Larger organisations have legal teams. Smaller ones typically do not, or do not have legal counsel with specific expertise in open source licensing. Relying on internal legal resource for OSS licence management is not a universally applicable best practice. For most small and mid-sized businesses, it is not realistic at all.
That gap matters. Open source licensing is a specialist area. The obligations under GPL, LGPL, AGPL, Apache, and MIT licences are not interchangeable, and the consequences of getting them wrong are not minor. Without appropriate legal expertise in the process, organisations are making consequential decisions blind.
Open source software is not going away, and neither are the legal obligations that come with it. The businesses that manage this well are the ones that treat licensing as a legal matter from the start, not an afterthought.
At Blackmont Legal, we advise technology businesses and software teams on open source compliance, licence risk, IP protection, and policy development. Whether you are building a product, preparing for investment, or trying to understand what your current codebase actually commits you to, we can help you get clarity before it becomes a problem.
