Open source software is often seen as a “free solution” you can simply take and use. In reality, open source ≠ free and risk-free.
Yes, in most cases you don’t pay a license fee, and that can significantly reduce a project’s budget: you don’t have to build from scratch what already exists, or buy expensive commercial alternatives. But the “cost” of open source is often not money — it is the legal terms of use: attribution and notice requirements, distribution rules, restrictions on modifications, patent provisions, license compatibility, and other conditions.
The right way to evaluate open source components
So, when choosing open source software, the first thing to look at is how you plan to use the open source component.
An open source component should be evaluated not only as a “technical library,” but also as a set of terms of use that can affect the product and the business model. Before integrating an open source component into your product, it is important to review its license and the accompanying documentation.
The biggest mistake is to treat the license as a formality and read it only after integration (or not read it at all).
A practical approach is different:
- First, define how exactly the component will be used:
- Will you modify its source code?
- Will you deliver your product (that includes this component) to users/customers?
- Or will it run only as a service on your servers?
- Then verify whether the license terms and accompanying documentation actually fit that scenario.
This approach saves time and budget and reduces the risk of negative legal consequences.
A critical point: some licenses may require you to make available the source code of the changes you made to the open source component itself if you distribute the product (i.e., provide it to customers/users as files). For example, MPL 2.0 typically requires you to provide the source code of the modified files of the component; LGPL/GPL may impose broader requirements depending on how the component is integrated and how the product is distributed; and AGPL may require you to provide the code even when the product runs as an online service (via a website or API).
A common pitfall is that a company may think, “we don’t distribute anything because this is SaaS.” However, if you release a mobile app, a desktop client, or provide others with an SDK (Software Development Kit), you are already delivering program files outside your organization. And that often counts as “distribution” under open source licenses.
In that case, license obligations related to the open source component may apply, such as:
- Keep copyright notices in the code or documentation
- Add the license text to the product distribution or documentation
- Include NOTICE/attribution (if required by the license)
- Mark the modifications you made (e.g., in modified files or release notes)
- In some cases, provide the source code of modified parts to those who receive the product.
8 "Red flags" in open source licenses: critical terms to review
Once you have defined how you plan to use the component, the next step is to quickly “scan” the license for terms that most often create legal and business risks. Below are the typical “red flags” to check first in the license of an open source component.
1. Code disclosure: When must you share your changes?
The first thing to check in a license is whether it requires you to publish (disclose) the source code of the open source component or the modifications you made to that component.
This becomes critical when your product is delivered outside your organization as software/files (for example, a customer receives an installation package and installs your software on their own systems, or you provide an SDK), or when you simply do not intend to disclose the modifications you made. This is one of the most common areas where a conflict arises between license requirements and business expectations or agreements with your customers.
2. What counts and when do obligations trigger?
In the license, it is important to understand when obligations are triggered in connection with distributing an open source component: only when you deliver externally a product that includes this component (i.e., the customer/user receives the software files), or also when the component runs on your servers and users only access the functionality via a website or API. That is why you should look for definitions and wording such as “distribute / distribution,” “convey,” “provide,” “make available.”
In practice, this comes down to a simple question: does the customer/user receive software files (an application, installer, library, SDK/plugin), or do they only use the functionality through a website/API? The answer determines whether you must: include the license text and/or NOTICE, retain copyright notices, mark changes, and sometimes provide the source code of modified parts.
Most open source licenses (even “permissive” ones) require you to retain legal notices about authorship and the license. So check whether you must: keep copyright notices in files, add the license text to the distribution, include a NOTICE file/attributions, or add references in documentation. Examples where this is typical include MIT, BSD 2-Clause / BSD 3-Clause, ISC, and zlib.
A common pitfall is that these requirements may look minor, but they are exactly what teams most often fail during audits: the component may be used legally, yet missing NOTICE files or license texts in a release can still lead to a compliance violation.
3. Must you mark or document changes?
Some licenses require more than just attribution — they require you to clearly state that you changed the open source component. In the license text, this may appear as requirements such as “prominent notice,” “you changed the files,” “modified version,” or “state changes.” Examples where this requirement is typical include Apache 2.0 and zlib (which requires altered source versions to be plainly marked as such).
A common pitfall: if a company does not have the habit of documenting changes (for example, notes inside modified files, a CHANGELOG, or release notes), these requirements can be violated easily and unnoticed — even when the code itself is otherwise used legally.
4. Patent grants: What are the termination risks?
Some licenses include a patent license granted by contributors/licensors, but that patent license may terminate if you initiate patent litigation. That is why you should check whether the license contains wording such as “patent license,” “patent claims,” “patent litigation.”
This is common, for example, in Apache 2.0 (patent grant + termination upon a patent lawsuit) and MPL 2.0 (patent rights and termination in certain cases). Similar mechanisms can also appear in other licenses that include a patent grant.
A common pitfall: under these licenses, if a company initiates a lawsuit alleging that the use of the component or a contribution infringes a patent, this may automatically terminate the patent rights granted under the license — and then any further use of the component becomes legally risky.
5. Does the license cover trademarks and brand names?
An open source license usually does not grant permission to use brand names or identifiers — neither the name/logo of the component itself, nor the name/logo of the company or organization that develops or maintains it. That is why you should check whether the license includes wording such as “trademarks,” “trade names,” “service marks,” “product names.” This is stated explicitly, for example, in Apache 2.0, MPL 2.0 and a similar approach is typically relevant for permissive licenses such as BSD-3 Clause (you can use the code freely, but that does not automatically give you the right to use someone else’s brand or logos).
A common pitfall: you may be using the component legally, but a violation can happen when the team starts using someone else’s brand in marketing or creates the impression of “official partnership” or “official support.” Usually, only a neutral reference describing the origin of the component is allowed (for example, in documentation or the component’s NOTICE file).
6. Hidden restrictions: Are there limits on commercial use?
Besides the classic open source requirements, licenses and accompanying component documents (LICENSE/NOTICE/README) can sometimes contain additional terms that look unusual for open source but create real business limitations. This most often happens with less common licenses, or licenses created by commercial companies that distribute software to third parties as “open source” or source-available. Examples include SSPL (strict requirements for service/hosting use), BSL, Elastic License 2.0 or Confluent Community License (restrictions on offering as a service / commercial use), and Commons Clause (an extra layer of conditions that can restrict certain monetization models).
A separate red flag is “community” or “free” tiers that tie your right to use the software to commercial criteria — for example, limits on annual revenue, number of developers/employees, and requirements to provide supporting documentation (financial/corporate information) to prove eligibility. If you no longer meet the criteria, the license may require switching to a paid commercial license and/or terminating your right to use the component — which in practice can mean having to replace or remove the component if purchasing the license is not possible or not reasonable.
Why this is dangerous: these restrictions are often not only in the main license text, but also hidden in NOTICE, ADDITIONAL TERMS, or project documentation. They are easy to miss during integration, but later can force changes in how you commercialize, scale, or deliver the product — affecting monetization, allowed use cases, your ability to grow the team or the company, and even the delivery model (as an online service on your servers vs. software the customer installs in their own environment).
7. License violations: What are the consequences?
In the license text, it is important to check what happens if the terms are breached: whether the license terminates automatically (“termination”), whether there is a “cure period” — a time frame to fix the breach, and what the consequences are after termination.
Why this matters: in practice, even a “formal” mistake (not including the license text, missing NOTICE, not marking modifications) may mean that you lose the right to use the component. As a result, you may need to urgently: fix the distribution package, ship a release with the correct notices, or even replace the component. A separate risk is patent terms in some licenses: if a company initiates a patent dispute related to the component, this may automatically terminate the granted patent rights.
8. Compatibility: Can you combine with other licenses?
If your product includes several open source components, it is important to check whether their licenses are compatible with each other and whether a component’s license allows it to be used together with code under other licenses.
Sometimes compatibility is not only a “yes/no” question, but also a set of concrete requirements you must follow when combining components: add attributions/NOTICE, include the license text, preserve copyright notices, mark changes, and in some cases ensure the ability to replace/relink a library.
Pitfall: some “strong” copyleft licenses or licenses with additional terms can make the combination legally problematic — for example, if one license requires source code disclosure/distribution under certain terms, while another license prohibits that or imposes incompatible requirements.
Here are a few examples of licenses that have specific compatibility rules when combined with other open source components:
- MPL 2.0: you can combine it with other components, but MPL files must remain under MPL; upon distribution you must disclose the source code of the modified MPL files and include the license/notice.
- GPL (v2/v3): the combination may be incompatible if it results in a single product and other components/terms do not allow you to comply with GPL requirements (in particular, source code disclosure and licensing the relevant parts under GPL).
Conclusion
The right approach is simple: first define how you plan to use the open source component, then review its license and accompanying documentation, and only after that include the component in your product and ship the release. This helps reduce the risk of legal issues (for example, source code disclosure requirements, attribution, change notices, patent terms, or license compatibility), and helps avoid financial losses and unpleasant surprises at release time or during compliance reviews.
.png)
.svg){kind=logo}