Using open-source code in commercial projects
Introduction
Open-source code is now an indispensable practice in commercial software and SaaS development. Software teams have long recognized that deploying with open-source accelerates innovation, reduces costs, and builds on widely vetted projects. However, the rights granted by these licenses are not unconditional; they impose critical obligations and restrictions that differ from license to license, sometimes in subtle but important ways. It is imperative that project leadership fully understand and manage these requirements to prevent reputational harm, preserve enterprise value, and safeguard intellectual property.
This guide surveys the most common open-source licenses—Apache 2.0, MIT, and the GPL family—with a practical focus on each license’s commercial impact, compliance obligations and key differences.
Two families of open source: permissive vs. copyleft
Open-source licenses generally fall into two main categories, each carrying distinct business implications.
Permissive licenses (e.g., Apache 2.0, MIT and BSD) are business-friendly and have minimal compliance overhead. They allow broad use, modification, and redistribution, including incorporation into proprietary products.
Copyleft licenses (e.g., GPL, LGPL and AGPL) follow a “share-alike” licensing model. They leverage the licensor’s exclusive rights to require that derivative works be licensed under the same (or compatible) terms. This reciprocal effect preserves openness for the copyleft-licensed project as it evolves, but can conflict with closed-source business models.
Sidebar: Software licensing fundamentals
All software licensing, including open-source, sits on the foundation of copyright. When a developer creates software—a “work of authorship”—the original elements are automatically protected by copyright. This legally enforceable protection provides a software author with the exclusive rights to copy, modify, and distribute their code.
Through a software license, the author decides how others may use, adapt, and distribute the copyrighted software. One way to view a commercial, closed-source or proprietary software license is as a tool for overriding copyright’s default restrictions in exchange for fees or other consideration. Open-source licenses use this same framework to guarantee broad sharing, subject to specific conditions.
Beyond copyright, patent law may cover novel and non-obvious software processes. Obtaining software patents is challenging in the United States after Alice Corp. v. CLS Bank (2014), which requires more than implementing an abstract idea on a computer to obtain a software patent.
In addition to a breach of contract action, failing to comply with an open-source license can trigger copyright infringement claims . A claim of infringement raises the risk of court injunctions and statutory damages, going beyond the remedies typically available in a simple contract dispute.
A closer look at permissive licenses
For most proprietary or commercial projects, permissive licenses are preferable to copyleft.
Apache License 2.0. Widely used by projects like Kubernetes and TensorFlow, the Apache 2.0 License is flexible and includes an explicit patent license. When distributing their project, developers using Apache 2.0 code will need to include the license text and copyright notices; preserve attribution notices (often maintained in a NOTICE file if one exists); and mark files that are changed from the source. The license does not grant rights to use the original project’s trademarks or names for endorsement without permission.
MIT and BSD (3-Clause). These licenses are short and simple. Compliance typically means preserving the original copyright notice and license text. Neither license includes an explicit patent grant, which developers in litigious or patent-heavy sectors may view as creating increased IP risk in comparison to an Apache 2.0-licensed project. The BSD 3-Clause license additionally has a non-endorsement clause that prohibits using contributor names to promote derivative products without their prior written permission.
Navigating copyleft licenses
Copyleft requires careful handling in commercial contexts because use can trigger obligations to disclose source code if that code is part of a project that is derivative of the copyleft-licensed project. As a result, open-source compliance often becomes a key focus in IP diligence for tech investments and acquisitions.
GPL. Used by many flagship projects (e.g., the Linux kernel), the General Public License (GPL) requires that if GPL-licensed code is combined with proprietary code to create a single derivative work, the distributed product must be licensed under the GPL and accompanied by source code.
But what counts as a “derivative work”? U.S. law defines it as a work “recast, transformed, or adapted.” However, applying this abstract standard to a real-life software project can be murky. While directly modifying GPL-licensed source is almost certainly a derivative work—and code that merely connects to GPL licensed software through a static API call is likely not—many cases sit in the middle. One example is “linking,” where GPL libraries are run in the same process as the proprietary code. The Free Software Foundation (which authors the GPL) takes the firm position that “linking” by itself creates a derivative work. While courts have not squarely adopted or rejected that view, the uncertainty can itself create a large problem situations like financing or acquisition diligence. The cloud of IP uncertainty can matter more than a strong but inconclusive legal argument.
The “SaaS loophole.” GPL obligations are triggered by distribution. If GPL code runs only on servers for a SaaS product (users interact over a network but do not receive a copy), that use is generally not “distribution” for GPL purposes. Companies often use GPL components in back-end services without a release obligation—though distribution of client apps, containers, or appliances changes the analysis.
AGPL. The Affero General Public License (AGPL) closes the SaaS loophole by requiring that users who interact with the AGPL-licensed program over a network be offered the complete corresponding source of that program. Because this can force disclosure of server-side code, many companies restrict AGPL usage in proprietary products altogether, even if copies of the software are not being distributed to customers.
LGPL. The Lesser General Public License (LGPL) is specifically structured to permit the use of open-source libraries with proprietary software. Under the LGPL, an application that merely links to the library is not considered a derivative work of that library, allowing the application’s source code to remain proprietary. Compliance hinges on two key obligations: (1) the LGPL-licensed library must be kept separate and dynamically linked, and (2) end-users must be provided the means to modify or replace the library and relink it to the main application. If the LGPL library code itself is modified, those specific modifications must be released in source code form under the terms of the LGPL.
Comparative snapshot
| License | Type | Source disclosure when modified? | Must Use Same License? | Explicit Patent Grant? | Key compliance points |
|---|---|---|---|---|---|
| Apache 2.0 | Permissive | No | No | Yes | Preserve copyright & license text; mark modified files. |
| MIT | Permissive | No | No | No | Preserve copyright & license text. |
| BSD (3-Clause) | Permissive | No | No | No | Preserve copyright & license text; do not imply endorsement by authors. |
| GPLv3 | Strong copyleft | Yes, upon distribution | Yes | Yes | Provide full corresponding source for distributed derivatives under GPLv3. Contains “SaaS loophole” |
| LGPLv3 | Weak copyleft | Yes, for the library/modified parts | Yes | Yes | Allow users to link to the LGPL library without being a derivative work |
| AGPLv3 | Strong copyleft | Yes, for distributed or network use | Yes | Yes | Provide full corresponding source for distributed or served derivatives. |
Open-source risks and compliance practices
Minimize exposure from open source with these practical risk checks and compliance actions.
Key risks:
- License non-compliance. Failing to meet license conditions (especially under copyleft) can require ceasing distribution or releasing source, and can expose the company to infringement claims
- Security vulnerabilities. Untracked dependencies can expose users if patches aren’t applied and without technical support options by the code author
- Code origin uncertainty. Code from unknown sources or that is purportedly open source may include undisclosed proprietary or copyleft code, creating hidden IP risk
- No warranties. Most open-source licenses disclaim warranties and limit liabilities
Compliance best practices:
- Adopt an open-source policy. Define permitted, restricted, and prohibited licenses
- Detailed Software Bill of Materials (SBOM). Maintain an accurate component inventory
- Educate teams. Teach license basics and the company policy
- Use AGPL cautiously; use GPL/LGPL selectively. AGPL’s network-use disclosure is generally incompatible with closed-source SaaS. GPL/LGPL components may be workable if used carefully and in ways that avoid full copyleft triggers
Conclusion
Open-source obligations vary dramatically by license. With a robust compliance program and clear architectural choices, companies can leverage the power of open source while protecting IP. When stakes are high, involve legal counsel experienced in open-source licensing.
At Replogle Legal Group, we help Illinois and New York businesses negotiate complex deals, build strategic partnerships and protect innovation. Schedule your free consultation today using the online calendar at the link below or contact Ryan Replogle by phone or email.