Open-Source Licenses Are Hiding in Your Product. Here’s When They Bite.
By Nadine Deeb, Esq. · Published July 13, 2026
Almost every software company is built partly on open-source code. Your engineers pull in libraries, frameworks, and packages to move faster — and most of the time, that is exactly the right call.
But open-source is not the same as free-to-use-however-you-want. Each package carries a license, and some of those licenses come with obligations that can affect how you use, modify, distribute, or make software available to users. Founders rarely think about this until an acquirer’s technical team scans the dependency tree during due diligence and starts asking questions. Here is what is actually in your product, and when it matters.
“Open Source” Does Not Mean “No Rules”
Open-source software is copyrighted work that the author has licensed for others to use, modify, copy, and distribute — but only on the terms in the license.
Those terms vary widely. Some licenses ask for almost nothing. Others require you to do specific things in return for the right to use the code. A few can require you to make corresponding source code available under the same terms, depending on how the licensed code is modified, combined, distributed, or made available over a network.
The practical problem is that these obligations often attach at the package level, without anyone at the company making a deliberate legal decision. A developer solving a problem at 2 a.m. adds a dependency. That dependency pulls in others. The license terms come along for the ride.
Multiply that across hundreds of packages and several years, and most startups genuinely do not know everything that is in their product or what those components require.
The Two Families of Licenses
Open-source licenses fall, roughly, into two groups. Understanding the difference is most of the battle.
Permissive Licenses
Permissive licenses — MIT, Apache 2.0, and BSD are common examples — usually allow use in proprietary, closed-source commercial products, provided the required copyright notices, license text, and disclaimers are preserved.
For most startups, permissive dependencies are lower-risk. They are not risk-free, because the notice obligations still matter, and the details vary by license. Apache 2.0, for example, includes an express patent license and additional notice-related requirements that are worth understanding.
But the basic point is simple: permissive licenses generally let you build commercial software without disclosing your own proprietary source code.
Copyleft Licenses
Copyleft licenses — including the GPL family and the AGPL — are where obligations can, depending on the facts, affect more than the third-party component itself.
The core idea of copyleft is reciprocity. If you modify, combine, distribute, or make covered code available in certain ways, you may have to make corresponding source code available under the same license. The concern for a commercial software company is that a copyleft obligation, triggered the wrong way, could affect code the company intended to keep proprietary.
Not all copyleft is equal. “Weak” copyleft licenses like the LGPL or MPL are generally more limited. MPL is commonly described as file-level copyleft, meaning the obligation is usually focused on files covered by the MPL and modifications to those files. LGPL obligations are generally focused on the covered library and preserving users’ ability to modify or replace it, rather than automatically converting the entire application to the same license.
“Strong” copyleft licenses like the GPL reach further. And the AGPL addresses a scenario the GPL does not: users interacting with covered software over a network. For a hosted software business, AGPL components in core or user-facing services deserve particular attention, even if the company never ships downloadable software.
When These Obligations Actually Bite
The obligations in a copyleft license are often triggered by distribution — in GPL terminology, conveying the software to someone else. For a company that ships installed software or a downloadable app, distribution is usually obvious.
For a pure SaaS company, the analysis can be less intuitive. Merely running GPL-covered software on your own servers may not, by itself, be the same as conveying copies to users. That distinction is one reason the AGPL matters: it can require source-code availability when users interact with covered software over a network, even if the company does not traditionally distribute downloadable software.
Because the analysis depends on the specific license, how the component is integrated, whether the component has been modified, and how the product reaches users, this is not something to resolve from a blog post.
The point here is narrower and more useful: the risk is real, it is component-specific, and it is worth knowing what is in your stack before someone else looks.
Why This Surfaces at the Worst Possible Time
Most founders never hear about open-source obligations during the ordinary course of building. They hear about them during due diligence — when a potential acquirer or investor runs an automated scan of the codebase and its dependencies and produces a report of every license in the product.
If that report turns up a strong-copyleft or AGPL component in a core or user-facing part of a proprietary SaaS product, it becomes a diligence issue. The buyer’s counsel wants to understand whether the company’s proprietary code is actually as proprietary as represented.
In the best case, it is a question answered with a quick explanation. In a worse case, it slows the deal, prompts a remediation demand, or affects price. Sometimes the remediation is simple. Sometimes it means replacing a component the product has quietly depended on for years.
None of that is where you want to be discovering your dependency tree for the first time: on a deadline, with a buyer waiting.
What Good Open-Source Hygiene Looks Like
You do not need to avoid open-source. That would be both impossible and unwise. You need to know what you are using and choose deliberately.
A few practices carry most of the value.
Keep an Inventory
Maintain a software bill of materials — a list of the open-source components in your product and their licenses. Modern tooling can generate this automatically, and it is increasingly something buyers expect to see.
This should include both direct dependencies and transitive dependencies: the packages your team selected, and the packages those packages pull in.
Have a Policy
Decide in advance which license types are acceptable in which parts of your product, so the decision is made once, thoughtfully, rather than repeatedly and by default.
Many companies allow permissive licenses freely, permit weak copyleft with care, and flag strong copyleft and AGPL for review before adoption.
Watch the Combination, Not Just the Component
The same library can carry different implications depending on how it is integrated, whether it has been modified, whether the product is distributed, and whether users interact with the covered software over a network.
When a component is important and its license is not clearly permissive, that is the moment to get a clear read rather than assume.
Preserve Notices
Even permissive licenses usually require keeping copyright notices, license text, and disclaimers. A simple, well-maintained attributions file handles much of this and is easier to keep current than to reconstruct under diligence pressure.
When to Bring in Counsel
Routine use of well-understood permissive libraries generally does not require a lawyer.
The situations worth a conversation are more specific: you have found copyleft or AGPL components in your core product; you are preparing for a fundraise or sale and want your open-source position clean before diligence; you are building on a component whose license you cannot confidently categorize; or you are combining open-source with proprietary code in a way you are not sure about.
In each of those situations, an early read is usually cheaper than a remediation demand mid-deal.
Accord & Shield Legal, PLLC works with technology and SaaS companies on intellectual-property and contract questions across Arizona, California, and Texas, including open-source usage and related license obligations. If you want your open-source position reviewed before your next diligence process, we can help you understand where you stand.
Frequently Asked Questions
Frequently Asked Questions
Generally yes, and nearly every software company does. The key is knowing which licenses apply to the components you use and how those components are integrated. Permissive licenses such as MIT, Apache 2.0, and BSD are typically lower-risk for commercial products if notice and license obligations are followed. Copyleft licenses, especially GPL-family licenses and the AGPL, can create source-code obligations depending on modification, distribution, network use, and how the code is combined, so they deserve closer review.
Permissive licenses usually require little more than preserving copyright, license, and disclaimer notices, and they generally allow use in closed-source commercial products. Copyleft licenses impose reciprocity obligations. If covered code is modified, combined, distributed, or — in the case of the AGPL — made available for network interaction in certain ways, corresponding source-code obligations may apply.
It depends on the specific license and how your product is built and delivered. Traditional GPL obligations are generally tied to conveying or distributing copies, so merely running GPL-covered software on your own servers for a hosted service may not trigger the same obligations. The AGPL addresses network use and can require source-code availability when users interact with covered software over a network. Because the analysis is fact-specific, AGPL components in a SaaS product should be reviewed carefully.
A software bill of materials, often called an SBOM, is an inventory of the software components used in a product, including open-source packages and their licenses. For a SaaS company, an SBOM helps the team understand what is in the product before an investor, buyer, or customer asks. It can also help identify notice obligations, higher-risk licenses, and components that may need review before a diligence process.
Yes. Permissive licenses are usually easier to work with than copyleft licenses, but they still have conditions. MIT and BSD-style licenses generally require preserving copyright notices, license text, and disclaimers. Apache 2.0 also includes patent-license provisions and notice-related requirements. These obligations are manageable, but they should not be ignored.
A startup should review its open-source usage before a financing, sale process, major enterprise customer review, or product launch involving important third-party components. It is especially worth reviewing if the company uses GPL, AGPL, LGPL, MPL, or any license the team cannot confidently categorize. It is much easier to address open-source issues before diligence than after a buyer or investor flags them.
No. This article is for general informational purposes only and is not legal advice. Reading it or contacting Accord & Shield Legal, PLLC does not create an attorney-client relationship. Open-source license obligations are fact-specific, and you should consult counsel about your particular product, codebase, and licensing posture.
Closing Note
Open-source is one of the reasons modern software companies can build so much, so quickly. It is not a liability to be feared — it is a resource to be used with a little awareness. The companies that run into trouble are almost never the ones that used open-source. They are the ones that never knew what they were using until someone else made them look.
This article is for general informational purposes only and is not legal advice. Reading it or contacting Accord & Shield Legal, PLLC does not create an attorney-client relationship. Open-source license obligations are fact-specific, and you should consult counsel about your particular product, codebase, and licensing posture.