Open-Source in Software Products: How to Use Without Legal Risks
Almost every modern software product contains open-source components. For businesses, this means access to mature technologies; for lawyers, it is a separate area of risk management.
Despite faster development and reduced costs, it is a mistake to view open-source as software without legal restrictions. On the contrary, the use of open-source code is always governed by a license that sets specific conditions for use, modification, and distribution. Failure to comply with these conditions may lead to legal disputes.
For example, in the United States case Jacobsen v. Katzer (Federal Circuit, 2008), the court confirmed that open-source license terms are legally binding, and their violation may constitute copyright infringement. In Germany, in the series of cases Welte v. D-Link, initiated by Harald Welte, courts repeatedly upheld the enforceability of GPL requirements and ordered cessation of distribution in case of license violations.
How to identify an open-source license
1) Check the repository
The first step is to review the hosting platform (e.g., GitHub), where the license type is usually displayed.
2) Check the LICENSE file
The main source of legal information is the LICENSE, COPYING, or similar file in the root directory of the project. It contains the legally binding license text.
3) Review project metadata
License information may also appear in configuration or build files such as package.json (JavaScript), pyproject.toml or setup.py (Python). However, these are secondary sources; the license text itself prevails.
4) Check licensing history
It is important to determine whether the license has changed over time and which version applies to the specific component being used.
Types of open-source licenses:
- Open-source licenses are generally divided into two groups:
- permissive licenses
- copyleft licenses
- Copyleft licenses can further be classified into weak copyleft and strong copyleft.
- Permissive licenses - minimal restrictions
- Examples: MIT License, BSD License (2-Clause, 3-Clause), Apache License 2.0, ISC License.
These licenses allow use, modification, and distribution with minimal restrictions. Typically, the only obligations are preserving the license text and copyright notices.
From a business perspective, permissive licenses pose the lowest legal risk and rarely conflict with commercial models.
Weak copyleft licenses - limited restrictions
| Examples: LGPL, MPL 2.0, Eclipse Public License. |
Copyleft licenses (both weak and strong) may impose obligations such as:
- disclosure of source code
- redistribution under the same license
- restrictions on proprietary use in certain cases
- Weak copyleft licenses apply these requirements only to the licensed component or its modifications, not necessarily to the entire product
For example, with LGPL libraries used via dynamic linking, a commercial application may remain closed-source, while modifications to the LGPL component itself must be released under the same license. MPL 2.0 is even more granular, applying copyleft obligations mainly at the file level.
Strong copyleft licenses - “viral” licenses
|
Examples: GPL v2, GPL v3, AGPL v3. |
These licenses may require that derivative works be distributed under the same license, potentially affecting the entire product. This is the so-called “viral effect”: under certain integration models, use of GPL components may trigger an obligation to disclose the source code of the entire software product. AGPL extends these requirements to network use cases, including SaaS models.
Therefore, both weak and strong copyleft licenses require careful legal analysis before use.
How to minimize risks when using copyleft components
1) Isolate the component from the main product
For example, run it as a separate service with a defined interface, reducing the risk of the entire system being treated as a derivative work.
2) Avoid modifying copyleft components
Using components in their original form usually reduces compliance obligations.
3) Check for dual licensing options
Many projects offer dual licensing (copyleft + commercial or permissive option). In some cases, purchasing a commercial license is more cost-effective than managing compliance risks.
4) Consider alternatives
Before adopting a copyleft component, evaluate whether equivalent permissively licensed alternatives (MIT, Apache 2.0, BSD, etc.) exist.
Practical recommendations for Open-Source compliance
1) Open-source inventory
Companies should maintain an up-to-date register of all open-source components, including:
component name
- license and version
- usage type
- repository link
- compliance status
2) Regular audits
Periodic review of dependencies and licenses is essential, especially when updating or adding new tools.
Open-source is a critical part of modern software development, but its use requires the same structured approach as intellectual property, data protection, or cybersecurity management.
The key goal for businesses is not to avoid open-source, but to build a transparent license management system. Maintaining a component register, conducting regular audits, and ensuring compliance allows companies to benefit from open-source while minimizing legal risks.
| The REVERA team advises IT companies on open-source usage, license audits, and the implementation of Open-Source Compliance processes. We are ready to help assess licensing risks and develop effective risk management strategies. |
Write to our lawyer to learn more details
Contact a lawyer
