The Open Source Compliance as an IP Risk Management Issue

Introduction

What is open-source software, exactly?

Open-source software (OSS) is software where the source code of the actual instructions that make the program work is made available to the public. Anyone can look at it, use it, modify it, and in most cases, distribute it. The deals look and sound so naïve and easy that however it would become a big risk if you did not manage it and lead to misconception.

Open-source software is not free from legal obligations.

Open-source software has licenses, which are legal documents for that software, which tells you what is allowed to do with the software and what conditions you must follow; failure to possess those conditions is not just negligence, it can be treated as copyright infringement.

When you download a software, you are technically entering into a legal agreement in person, known as the terms and conditions of that particular software, whose code was written by the developers or organization. You never signed anything, but by using the software, you accepted the terms.

Navigating OSS Licenses

Not all open-source licenses are the same, the rules vary quite a bit depending on which license applies at a broad level, there are two Routes :-

Permissive Licenses : More reliable though licenses like MIT and Apache 2.0 fall in this category. They let you use, modify, and even include the code in commercial, proprietary software. The main obligation is simple, you must keep the original copyright notice and credit the authors when you share or distribute the software. Apache 2.0 also requires you to mention any significant changes made. For companies, working with these licenses is relatively direct. Until you keep the attribution notices intact and include the license text when distributing, you are generally fine.

Copyleft Licenses : A known example is the GNU General Public License (GPL), which is based on the fundamental principle that if you take open-source code, alter it, and share the result, your altered version must likewise be made available as open-source under the same license.

Importantly, a limitation for firms developing proprietary software is that if they incorporate GPL-licensed code into their product and distribute it, they might be obligated to publish their entire codebase as open source, which entails leaving code that constitutes their company's essential competitive line. The crisp variant such as AGPL (Affero GPL). furtherly even if you do not distribute the software but make it available over a network (like a SaaS product), the same disclosure obligation kicks in.

The type of license determines your obligations, mixing up permissive and copyleft code, or failing to identify which license applies to a given component, is where most compliance problems begin.

The Compliance Challenge

Here is a picture of how open-source compliance issues typically develop in a real company -

A developer needs to build a feature quickly. They find a useful open-source library on GitHub and then they check that it works, they add it to the codebase, nobody looks at the license.

This happens dozens or hundreds of times across a development team. Over months and years, the product ends up with a huge number of open-source components, some with permissive licenses, some with copyleft licenses, and some with licenses that are incompatible with each other. The company has no real inventory of what is inside its software. Nobody knows the components of company licenses and software licensing, their requirements, and the three conditions:-

Lawsuit - A copyright owner finds that their GPL-licensed code is embedded in your product, yet you have not provided your source code as mandated, leading them to file a suit for copyright violation.

Acquisition - A buyer’s legal team conducts due diligence on your product, finding multiple license infringements and undisclosed dependencies, resulting in a delayed deal, renegotiation or conciliation, or complete failure.

Compliance verification or client specification - The government body or major corporate client mandates that you prove your software adheres to all relevant licenses. You are unable to generate the documentation.

Each of the three situations is genuine and occurs in businesses of all scales.

IP meets Open Source

Open-source compliance is fundamentally an IP issue : When a developer writes code, copyright law automatically gives them rights over that code. They own it, even if they choose to share it with the world for free. When they release it under an open-source license, they are granting you permission to use it, but only on certain conditions. If you violate those conditions, the permission is gone. You no longer have the legal right to use, copy, or distribute that code. At that point, you are doing so without authorization, which is copyright infringement.

In the important judicial landmark in U.S. case of Jacobsen v. Katzer (2008), referred as "Model Train Case." that software developer Robert Jacobsen had distributed software under an open-source licence that required users to provide attribution and make the source code available, other party used the software without complying with these licence conditions.

Lawsuit - A holder of copyright discovers that their GPL licensed code is incorporated in your product, but you haven't supplied your source code as required, prompting them to initiate a lawsuit for copyright infringement.·

Acquisition - during a purchaser's legal team performs due diligence on your product, uncovering several licensing violations and unreported dependencies, leading to an extended transaction, negotiations, or dispute.

Compliance checking or client requirements and the regulatory authority or client requires you to demonstrate that your software complies with all applicable licenses.

What's really in your software?

One of the biggest practical challenges in open-source compliance is that modern software is incredibly layered. Adding one open-source library to your product can lead to a chain of transitive dependencies, where each library pulls in more, resulting in components you didn't choose, but which end up in your product anyway, each carrying its own licence that may conflict with your own product's licence terms.

Experts in compliance refer to this issue as license proliferation, which stems from the large number of open-source licenses, making it difficult to ascertain which rules apply to each component and whether they are compatible. Some licenses work fine together. Others create direct conflicts that cannot be resolved without removing one of the components.

More Companies utilize a practical solution in the form of Software Bill of Materials (SBoM), which is mainly a comprehensive, documented list of every software component in a product, along with the applicable licence for each one. Think of it as an ingredient list for your software. You need it to know what you are actually shipping, what obligations it carries, and whether you are meeting them.

Open-Source in Merger & Acquisitions Transactions

If you are a lawyer working in corporate transactions of mergers, acquisitions, investments open-source compliance deserves a dedicated place on your due diligence checklist. The value of a technology company acquisition often hinges on its software product, but if that product incorporates undisclosed open-source components with copyleft licences, the buyer may face significant issues.

The target company may be required to release proprietary source code to comply with GPL obligations it has been ignoring.

Licenses may have already been violated, creating exposure to lawsuits from open-source copyright holders.

Components may be nearing end-of-life, meaning no more security updates, which creates a separate but related risk.

These are not hypothetical concerns. Compliance issues found during technology due diligence are a known cause of deal complications. A company that cannot produce a clean, accurate license inventory is a company with an IP problem and acquiring that problem is acquiring the liability that comes with it.

Buyers should anticipate a SBOM and a licence compliance audit as standard elements of the software-focused due diligence process, and sellers should make ongoing compliance programmes to guarantee these documents are easily accessible when needed.

The Patent Angle

Copyright is not the only IP dimension here. Patents matter too, though the relationship with open-source software is different and more complicated.

Some open-source licenses include what are called patent grants provisions where the contributors grant users a license to any patents that cover the software. Apache 2.0 does this explicitly, which is one reason it is preferred by many corporate users over licenses that do not include such protection.

However, the broader patent risk in open-source software is significant, a piece of widely used open-source code may, without anyone realizing it, implement a method that someone has patented, the developers who contributed the code were not aware of the patent. The users of the code were not either. However, the patent still exists, and the patent holder can bring a claim. This risk is especially hard to manage because you cannot simply read the source code and determine whether it infringes a patent. Patents cover methods and processes, not just literal text. A technical expert and legal analysis are often required.

Large companies manage this risk partly through building patent portfolios of their own so that if they are sued over a patent, they can often counter-sue or negotiate a cross-license. Smaller companies and community-led open-source projects have far less ability to defend themselves this way, which is why patent risk remains one of the harder problems in this in regard.

The Compliance Blueprint

So, what should companies actually do? - A solid open-source compliance program boils down to four key things:

1. Know what’s in your codebase.

You can’t manage what you can’t see. Use Software Composition Analysis (SCA) tools to scan your entire project including all the hidden nested and transitive dependencies so you have a complete inventory of every open-source component you’re using.

2. Understand your license obligations.

Before you enter into any agreement, go through each component’s license carefully. Figure out exactly what it requires: attribution notices, source code disclosure, preserving license texts, etc. Then clearly document what you need to do to stay compliant.

3. Check for license compatibility.

When you’re mixing components with different licenses, make sure they actually play well together and that they’re also compatible with the license you want to use for your own product. Incompatible licenses can create serious legal headaches later.

4. Keep the records.

By documenting every possible aspect and maintaining a proper Software Bill of Materials (SBOM), track which licenses apply, how you’re meeting the requirements, and when was the last review. These records are your best defense if you ever face a legal claim or need to pass due diligence.

Use Contributor License Agreements (CLAs) - If your company runs or contributes to open-source projects, these contracts and agreements clarify who owns the contributions or equity, under what terms they are licensed, and how they can be used. reduces disputes and provides rights with clear documentations.

Train your people – Developers need to understand the basics of open-source licensing, they should know the difference between permissive and copyleft licenses, and they should know to flag a new dependency for review before it enters the codebase with legal and compliance teams has to be trained to understand the technical side well enough to ask the right questions.

Review regularly - Compliance is not a one-time task, Licenses, dependencies, and legal requirements change, our compliance program needs to be a living process, not a document you file and forget.

Enforcement & Business Impact

Open-source license compliance is not merely a matter of good ethics, it is actively enforced. Organizations like the Free Software Foundation (FSF) actively enforce GPL violations and handle dozens of cases each year. Other copyright holders also bring their own private enforcement actions. In some jurisdictions, courts have even issued injunctions forcing companies to completely stop distributing their products until they achieve full compliance.

The risk is very real Open-source compliance enforcement is an active and growing area of law. Companies that treat it as an afterthought can face lawsuits, court-ordered injunctions, serious reputational damage, and expensive remediation efforts — sometimes requiring them to rip out non-compliant code and rebuild significant parts of their product from scratch.

Conclusion

Open-source software has made technology more modern and advanced. our smartphones, cloud infrastructure and machine learning whose websites we use every day almost for every use. Its one of the great achievements of global achievement, built by people who, for the most part, contribute in good faith with the genuine intention of sharing knowledge and enabling others to build upon their work.

The license terms they attach to their contributions are important and certifies as use it freely, with respective conditions. Meeting those conditions is not some annoying bureaucratic checkbox. It is a legal and ethical obligation that comes with participating in the open-source ecosystem. For developers, it’s a matter of good coding and process discipline. For legal teams, it’s an important intellectual property risk management issue that touches contracts, litigation, mergers and acquisitions, and regulatory compliance.

For both fields open-source compliance deserves a real seat at the table, not as a one-time checkbox, but as an ongoing, integrated part of how the organization operates.

Author: Nishtha Thakur, in case of any queries please contact/write back to us via email to chhavi@khuranaandkhurana.com or at  Khurana & Khurana, Advocates and IP Attorney.

References

1. Copyright Act 1957 (India). (1957). Act No. 14 of 1957.

2. Patents Act 1970 (India). (1970). Act No. 39 of 1970.

3. McConnell, D. (2026, January 25). Open source license compliance: Risks, requirements, and best practices. Finite State. https://finitestate.io/blog/open-source-license-compliance.

4. Unpacking open source compliance. "OpenLogic by Perforce. https://www.openlogic.com/blog/open-source-compliance-overview".

5. Sohn, D. (2026, May 27). Open source software compliance and risk management strategies. SJKP Law Firm LLP. https://www.daeryunlaw.com/us/insights/open-source-software-compliance-in-nyc

6. Contrast Security - "Understanding the risks of open-source software. https://www.contrastsecurity.com/whitepaper/understanding-the-risks-of-open-source-software

7. National Cyber Security Centre (UK) (2024), Open source software best practices and supply chain risk management. https://assets.publishing.service.gov.uk/media/661ff8b83771f5b3ee757fc5/Open_Source_Software_Best_Practices_and_Supply_Chain_Risk_Management.pdf

8. Harutyunyan, N., Bauer, A., & Riehle, D. (2019). Getting started with open source governance and compliance in companies. Proceedings of the 15th International Symposium on Open Collaboration, Article 13. Association for Computing Machinery. https://doi.org/10.1145/3306446.3340815

9. Nedelkovski, B. (2025). Open source software and intellectual property [Research paper]. University of Library Studies and Information Technologies, Sofia. https://www.researchgate.net/publication/390825515_OPEN_SOURCE_SOFTWARE_AND_INTELLECTUAL_PROPERTY

10. Välimäki, M., & Oksanen, V. (2004). How to manage IPR infringement risks in open source development [Research paper]. Helsinki University of Technology. https://www.researchgate.net/publication/228986317_How_to_Manage_IPR_Infringement_Risks_in_Open_Source_Development

11. The SCO Group, Inc. v. International Business Machines Corporation, No. 16-4040 (10th Cir. 2017).

12. Jacobsen v. Katzer, No. 2009-1234 (N.D. Cal. Feb. 16, 2010).