You can use open source code for profit. Every license that meets the Open Source Definition allows commercial use, redistribution, and sale, with no restriction on who uses the software or for what purpose.1Open Source Initiative. The Open Source Definition What changes from one license to the next is the price of admission: some let you fold the code into a closed-source product and sell it with almost no obligations, while others require you to release your own source code when you distribute the finished work. Picking the wrong license category for your business model is where companies get into expensive trouble.
Permissive Licenses Are the Easiest Path
Permissive licenses impose the fewest conditions. The MIT License, the BSD licenses, and the Apache License 2.0 all let you take the code, modify it, bundle it into a proprietary product, and sell that product without releasing your own source. This is why permissive-licensed libraries sit under most commercial software shipping today.
The MIT License grants permission “to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software.” The only requirement is that you include the original copyright notice and license text in all copies or substantial portions of the software.2Open Source Initiative. The MIT License In practice, that means dropping the notice into a third-party licenses file shipped with your product.
The 3-Clause BSD License works similarly but adds one restriction: you cannot use the names of the original contributors to endorse or promote your product without their written permission.3Open Source Initiative. The 3-Clause BSD License That matters if you are marketing a product built on a well-known project and want to reference it by name in sales materials.
The Apache License 2.0 asks for a little more. When you redistribute, you must give recipients a copy of the license, keep existing copyright and attribution notices intact, and flag any files you modified with a prominent notice describing your changes.4Choose a License. Apache License 2.0 These are still light obligations, and none of the permissive licenses force you to reveal your proprietary code.
Copyleft Licenses Let You Profit With Conditions
Copyleft licenses also allow commercial use, but they require you to share your changes on the same terms. If you modify copyleft-licensed code and distribute the result, the whole combined work generally has to carry the same open source license. That single rule reshapes commercial strategy.
The GPL and Distribution
The GNU General Public License version 3 is the most widely used strong copyleft license. Section 5 states that if you distribute a modified version, “you must license the entire work, as a whole, under this License to anyone who comes into possession of a copy.”5GNU. GNU General Public License v3.0 If your proprietary application incorporates GPL code and you ship it, distributing that application could require you to release the entire thing under the GPL.
Whether a given piece of your code counts as “derived from” the GPL component is not always obvious. Programs that communicate through standard mechanisms like network sockets or command-line arguments are more likely to be treated as independent works. Code that shares data structures, function calls, or memory with the GPL component is more likely to be considered a derivative work.6ifrOSS. When Does Independently Developed Software Have to Be Licensed Under the GPL The uncertainty is why companies treat GPL code carefully.
One point that trips people up: using GPL software internally within your company is not distribution. The copyleft obligations only kick in when you transfer copies to someone outside your organization. But that boundary is narrower than you might expect. Handing a copy to a partner company, a contractor, or a subsidiary under a different corporate entity can count as distribution and trigger the full GPL requirements.
The LGPL for Libraries
The GNU Lesser General Public License is written for code libraries. It allows proprietary software to link with an LGPL-licensed library without the copyleft obligation spreading to the proprietary code, provided you follow certain technical rules. The LGPL gives you two main compliance paths for combined works: provide the source of the LGPL library along with enough information for the user to relink the application, or use dynamic linking so the user’s system loads the LGPL library at runtime.7GNU. GNU Lesser General Public License v3.0 Dynamic linking is the easier path because it naturally separates the LGPL library from your proprietary code. Static linking is legal but creates more compliance overhead, so most commercial developers default to dynamic.
The SaaS Question and the AGPL
Here is the single most commercially important detail. The GPL’s copyleft requirements are triggered by distribution, not by use. If you run GPL-licensed software on your own servers and let customers reach it through a browser or an API, you are using the software, not distributing it. No copies change hands, so the source-sharing requirements never activate. That is why major cloud providers can build services on GPL code without releasing their modifications.
The GNU Affero General Public License version 3 was written to close this gap. Section 13 adds a network-interaction clause: if you modify AGPL-licensed code and let users interact with it remotely over a network, you must offer those users a way to download the corresponding source code at no charge.8GNU. GNU Affero General Public License v3.0 The requirement only applies to modified versions; running unmodified AGPL software as a hosted service does not trigger Section 13.
For anyone building a SaaS product, the GPL/AGPL split matters. GPL-licensed components can often sit on the server side without compliance concerns. AGPL-licensed components demand the same source transparency whether you distribute the software or host it. Many commercial SaaS shops flag AGPL code for legal review before it enters any codebase.
What You Have to Ship With Your Product
A few obligations show up in almost every open source license. Getting these right is the baseline for any commercial use.
- Preserve copyright notices. Do not strip copyright headers from source files you incorporate, and keep the notice attached to any fragment you copy.2Open Source Initiative. The MIT License
- Include the license text. Ship a copy of each open source license that applies to components in your product. For Apache 2.0, that means both the LICENSE file and any NOTICE file that came with the component.9Apache Software Foundation. Assembling LICENSE and NOTICE Files
- Note your modifications. Some licenses, Apache 2.0 among them, require you to mark files you changed with a prominent notice.4Choose a License. Apache License 2.0
- Pass through the warranty disclaimer. Open source licenses universally disclaim warranties and limit the original developers’ liability, and that disclaimer has to reach your end users.2Open Source Initiative. The MIT License
For products that bundle dozens or hundreds of components, tracking these by hand is impractical. Most companies maintain a Software Bill of Materials, an inventory of every open source component in the product along with its license and version. Automated scanning tools compare your codebase against known packages and flag license conflicts or missing attributions before release.
What Violating a License Actually Costs
Violation is not a gray area. If you fail to comply with the terms, the license terminates, and you lose the right to copy, modify, or distribute the software. Continued use after that is copyright infringement.5GNU. GNU General Public License v3.0
GPLv3 includes a cure provision. If you receive notice of a violation for the first time from a particular copyright holder, you get 30 days to fix the problem, and if you come into compliance within that window your license is automatically reinstated. The grace period only applies once per copyright holder, and only to GPLv3. Older licenses and other copyleft licenses may not be as forgiving.
Enforcement is real. In 2024, a Paris court ordered Orange to pay over €900,000 in damages for modifying and distributing GPL-licensed software without providing the corresponding source code. That judgment included €150,000 in moral damages, an unusually large award for an open source case. In a separate 2024 case, a German court ruled against AVM for distributing incomplete source code that lacked the build scripts needed for compilation. Organizations like the Software Freedom Conservancy and the Free Software Foundation actively monitor GPL compliance and pursue violators, typically starting with a private demand letter before escalating.
How Companies Actually Make Money From Open Source
Several business models have proven out, and each one is shaped by the license type sitting underneath it.
- Proprietary products built on open source. Use permissive-licensed code as a foundation, add your proprietary features on top, and sell the closed-source result. This describes much of the commercial software industry.
- Dual licensing. Release your software under both a copyleft license and a separate commercial license. Users comfortable with the copyleft terms use the open source version for free; users who want to embed your code in proprietary products without triggering copyleft obligations pay for the commercial license. This only works when you own the copyright to the entire codebase. MySQL pioneered the approach with the GPL alongside a paid commercial option.
- Support and services. Give the software away under an open source license and sell professional support, training, consulting, or managed hosting around it. The software is free; expertise in running it at scale is not.
- Open core. Release a functional core as open source, then sell proprietary extensions, plugins, or enterprise features that build on it. The open version drives adoption; the paid features drive revenue.
- Hosted SaaS. Run open source software on your own infrastructure and charge for access. Standard GPL does not require source disclosure for hosted services, which makes this model especially attractive for GPL-licensed code. AGPL-licensed code requires more care.
Trademarks Are a Separate Question
Open source licenses govern the code. They do not automatically grant you the right to use a project’s name, logo, or branding. Trademarks sit under a separate legal regime, and most well-known projects enforce theirs. You may have every right to fork a project’s code and sell a product based on it, and still land in a trademark dispute if you call the product by the original project’s name. If your commercial product is built on a recognizable open source project, check whether the project publishes trademark usage guidelines before referencing its name in your marketing.