You can use open source software for commercial purposes. Every license approved by the Open Source Initiative must permit business use, so the question is never whether commercial use is allowed but which obligations you take on when you ship, host, or modify the code.1Open Source Initiative. The Open Source Definition Those obligations vary sharply between license families, and getting them wrong exposes you to copyright infringement claims, not just contract disputes.
Why Commercial Use Is Always Permitted
The Open Source Definition sets ten criteria a license must meet to be called open source. Criterion 6 is the one that matters here: the license “must not restrict anyone from making use of the program in a specific field of endeavor,” and business use is named as an example that cannot be blocked.1Open Source Initiative. The Open Source Definition
One boundary worth naming, because it trips up teams that assume anything on GitHub is fair game: licenses that forbid commercial use are not open source under this standard, whatever a project’s README claims. Creative Commons NonCommercial variants and various “source-available” licenses fall into a different category and carry their own restrictions. If you plan to use the code in a paid product, confirm the license is on the OSI’s approved list before you build on it.2Open Source Initiative. OSI Approved Licenses
Permissive Licenses and What You Owe
Permissive licenses give you the widest latitude. You can use, modify, and redistribute the code inside a proprietary product with minimal strings attached.3Open Source Programs Office – JHU OSPO. Choose a License The most common are the MIT License, the Apache License 2.0, and the BSD family (typically the 2-clause and 3-clause variants).
Your main obligation is attribution. Keep the original copyright notice and license text with any copy you distribute. Under the MIT License, that is essentially the whole requirement: the copyright notice and permission text travel with the software, and you can combine it with proprietary code without a licensing conflict.4MIT Technology Licensing Office. Exploring the MIT Open Source License: A Comprehensive Guide You are not required to release your own source.
The Apache 2.0 Patent Grant
Apache 2.0 adds something the MIT and BSD licenses do not: an explicit patent grant. Every contributor automatically licenses any of their patent claims that would be infringed by their contribution, giving you a royalty-free right to make, use, sell, and distribute the work. That reduces the risk of a contributor later asserting a patent against a product built on the code they helped write.
The grant has a retaliation clause. If you sue anyone claiming the licensed software infringes one of your patents, you lose the patent rights the license granted. The purpose is to keep contributors from being punished for participating while still discouraging patent aggression inside the community.
Copyleft Licenses and the Share-Alike Trade-Off
Copyleft licenses also permit commercial use, but they attach a condition: any work you distribute that incorporates the code must itself be released under the same or a compatible license. The Free Software Foundation describes copyleft as ensuring that anyone who redistributes the software passes along the freedom to copy and change it.5GNU Project – Free Software Foundation. What is Copyleft? For a commercial product, that can mean releasing source you would rather keep proprietary.
GPL and the Distribution Trigger
The GNU General Public License is the most widely used copyleft license. When you distribute a product that incorporates GPL-licensed code, you must make the complete source of the combined work available to recipients under the GPL’s terms. Under GPLv2, you can either ship the source with the binary or provide a written offer, valid for at least three years, to supply the source to anyone who asks.
The trigger is distribution. If you only run modified GPL code inside your own organization and never ship it outside, the source-code obligation does not apply.6GNU Project – Free Software Foundation. Frequently Asked Questions about the GNU Licenses That single point drives a lot of practical decisions about where GPL code can safely live in a commercial architecture.
LGPL and How You Link Matters
The GNU Lesser General Public License was designed for libraries that developers link into larger applications. If your proprietary application dynamically links to an LGPL library, loading it at runtime rather than compiling it in, you generally avoid triggering copyleft on your own code. You still need to provide the library’s source and let users swap in a modified version.
Static linking is where teams get caught. When you compile the LGPL library directly into your binary, you must provide enough information for a user to relink your application against a modified version of that library, typically the object files and build scripts. This is possible while keeping your own source proprietary, but it is significantly more work and a common source of compliance failures.
AGPL and Cloud Services
The Affero General Public License closes a gap in the standard GPL. Because GPL obligations trigger on distribution, a company can modify GPL code, run it on its own servers to power a web service, and never release the source, since the software is never actually distributed to users.6GNU Project – Free Software Foundation. Frequently Asked Questions about the GNU Licenses
Section 13 of the AGPL removes that option. If you modify AGPL-licensed software and let users interact with it remotely over a network, you must offer those users access to the corresponding source code at no charge.7GitHub. GNU Affero General Public License Version 3 Many companies treat AGPL components as off-limits for commercial SaaS work precisely because integrating one could force disclosure of the server-side codebase around it.
License Compatibility When You Mix Components
A commercial application almost always pulls in code from many open source projects, and those projects will not all use the same license. When two licenses impose conflicting requirements, combining them in a single distributed work can be legally impossible. This is the compatibility problem, and it catches experienced teams.
Permissive licenses are the easiest to work with. The MIT License and the Modified BSD License are compatible with every version of the GPL, so MIT-licensed code can be folded into a GPL project and distributed under the GPL without conflict.8GNU Project – Free Software Foundation. Various Licenses and Comments about Them The harder cases involve mixing copyleft licenses or combining certain permissive licenses with older GPL versions:
- Apache 2.0 with GPLv3 is compatible; you can combine Apache-licensed code into a GPLv3 project.
- Apache 2.0 with GPLv2 is incompatible. The Apache License’s patent termination and indemnification provisions have no equivalent in GPLv2, creating a conflict.
- GPLv2 and GPLv3 are incompatible on their own. Most GPLv2 software includes an “or later version” clause, which lets you upgrade the code to GPLv3 and combine it with other GPLv3 code.
- AGPL and GPLv3 can coexist as separate modules in a single project, even though the licenses are not interchangeable.
Check the license of every component in your dependency tree before adding a new package. An incompatible transitive dependency buried three levels deep creates the same legal exposure as one you chose directly.
Compliance Obligations That Apply Across Licenses
A few requirements come up in nearly every open source license:
- Retain copyright notices. Do not strip out copyright headers from files you incorporate. This is the most universal requirement.
- Include the license text with any software that uses the component. For permissive licenses, this is often the entire obligation.
- Provide attribution where required, whether in documentation, an “About” screen, or both. Keeping all original notices intact is a safe baseline.
- Offer source code when you distribute software that incorporates copyleft-licensed code.
These obligations are simple in isolation.9The Linux Foundation. Open Source License Best Practices – Quick Reference Guide The difficulty is scale. A commercial product with hundreds of open source dependencies turns tracking what you owe into a logistics problem.
What Happens If You Violate a License
Open source licenses are enforceable, and violations can produce copyright infringement claims, breach of contract claims, or both.
A French court awarded over €500,000 in compensatory damages and €150,000 in additional moral damages against Orange S.A. for modifying, using, and distributing GPL-licensed software without complying with the license’s attribution and source code requirements. In the United States, the court in Artifex Software v. Hancom denied the defendant’s motion to dismiss both breach of contract and copyright infringement claims arising from alleged GPL violations, allowing the case to proceed.10Justia Dockets. Artifex Software, Inc. v. Hancom, Inc.
Money damages are only part of the risk. If a court terminates your license for non-compliance, continued use becomes unlicensed copying, which is straightforward copyright infringement. An injunction at that point could force you to pull a product from the market until you either comply or rewrite the infringing components. Under U.S. copyright law, statutory damages for willful infringement can reach $150,000 per work infringed, without any proof of actual financial harm.
Software Warranties and Liability
Almost every open source license includes a disclaimer stating the software is provided “as is,” with no warranty of merchantability, fitness for a particular purpose, or non-infringement. If the code has a bug that corrupts customer data or crashes your production system, the original developers owe you nothing.
Liability clauses typically extend that further, stating contributors are not liable for any damages arising from the software’s use, including lost profits, business interruption, or data loss, even if they were warned such damage was possible. As a commercial user, you bear the full cost of any problems. Budget for your own testing, monitoring, and incident response rather than expecting recourse upstream.
Commercial Models Built on Open Source
Some companies do not just use open source software but build their revenue around it. Two approaches are common.
In dual licensing, the same codebase is released under both a copyleft license, usually GPL, and a separate commercial license. Users who want to avoid copyleft obligations pay for the commercial license, which typically bundles warranties, indemnification, and support. This model requires the company to own or control the copyright to the entire codebase, which is why dual-licensed projects often require Contributor License Agreements from every contributor.11Google CLA. Google Individual Contributor License Agreement
In an open core model, the company maintains a free open source core product, often under a permissive license, and sells proprietary add-on features separately. Enterprise features like advanced security controls, analytics, or priority support live in the paid tier. Unlike dual licensing, this only requires copyright control over the proprietary add-ons rather than the whole community-contributed core.
A third arrangement worth flagging is the Business Source License, which restricts production use for a set period, typically until the fourth anniversary of release or a specific change date, after which the code automatically converts to an open source license like GPLv2.12MariaDB. Adopting and Developing BSL Software BSL is not open source during that initial period. If you encounter BSL-licensed software, read the Additional Use Grant carefully to see how much production use is allowed without a commercial license.
If You Contribute Back: Contributor License Agreements
If you plan to contribute code to an open source project rather than only consume it, you may be asked to sign a Contributor License Agreement. A CLA grants the maintainer broad rights to your contributions, typically a perpetual, worldwide, royalty-free copyright and patent license covering the right to reproduce, modify, sublicense, and distribute your code.11Google CLA. Google Individual Contributor License Agreement
CLAs exist because the maintainer needs clear intellectual property rights to license the project confidently, particularly under a dual-licensing model. Before signing one on behalf of your company, get employer approval. Most CLAs require you to represent that you have legal authority to grant the license and that your employer has either waived its rights or signed a separate corporate CLA.
Building a Practical Compliance Workflow
For any company using more than a handful of open source components, ad hoc license checking will not scale. A structured workflow pays for itself the first time it catches an incompatible dependency before shipping.
The core elements: maintain a Software Bill of Materials that inventories every component, its version, and its license; review new dependencies before they enter the codebase; and set clear policies about which license categories are approved for which use cases, whether internal tools, distributed products, or SaaS. Federal agencies procuring software already require SBOMs aligned with CISA guidance, and enterprise customers are beginning to expect them in procurement as well.13CMS Information Security and Privacy Program. New Cybersecurity Guidance from CISA for Software Bill of Materials (SBOM)
Software Composition Analysis tools automate much of the work by scanning your codebase, identifying open source components, and flagging both license conflicts and known security vulnerabilities. For a formal framework, the OpenChain ISO/IEC 5230 standard defines what a complete open source compliance program looks like: documented policies, defined roles, procedures for identifying and tracking components, and a process for producing compliance artifacts like attribution notices and source code offers.14OpenChain. Adopt OpenChain ISO/IEC 5230 Even without pursuing certification, the checklist works as a diagnostic for gaps in your current process.