October 13, 2026
The open source licenses a startup will meet most fall into a few families. Permissive licenses (MIT, Apache 2.0, BSD, ISC) let you use the code almost freely as long as you keep the notices. Copyleft licenses (MPL, LGPL, GPL, AGPL) require you to share source code in some circumstances, and AGPL is triggered by offering software over a network. Increasingly you’ll also see “source-available” licenses such as BSL and SSPL, which are not open source and restrict competing uses.
Key takeaways
There are hundreds of licenses, but in practice a small number cover most of the code in commercial software. The table below groups the ones you’ll see by family, with what each requires of you.
| License family | Examples | What you must do | Safe to use in a SaaS product? |
|---|---|---|---|
| Permissive | MIT, Apache 2.0, BSD 2-Clause and 3-Clause, ISC, Zlib | Keep the copyright and license notices. Apache 2.0 also requires a notice of changes and includes a patent license. | Yes |
| Public domain dedication | CC0, the Unlicense, 0BSD | Nothing, in most cases. | Yes |
| Weak copyleft | MPL 2.0, LGPL 2.1 and 3.0, EPL 1.0 and 2.0, CDDL | Share your changes to the licensed files or library itself. Your own code that uses it can stay proprietary. LGPL has specific rules on how you link to the library. | Yes, with care if you distribute |
| Strong copyleft | GPL 2.0 and 3.0 | If you distribute software that includes GPL code, the combined work must be released under the GPL with source code. | Usually yes, if the code only runs on your servers. Not if you ship it to customers. |
| Network copyleft | AGPL 3.0 | Same as GPL, and also triggered when users interact with the software over a network. | Risky. Avoid in your product without legal review. |
| Source-available (not open source) | Business Source License (BSL), SSPL, Elastic License 2.0, Functional Source License | Usually free for internal use, but you can’t offer the software as a competing hosted service. BSL and FSL convert to an open source license after a set period. | Depends on the license and your use |
Some licenses aren’t meant for code at all. Creative Commons Attribution 4.0 is common for text, images and documentation, and the SIL Open Font License covers fonts. Both allow commercial use with attribution.
Permissive licenses let anyone use, modify and distribute the code, including in closed-source commercial products. The main obligation is to keep the original copyright and license notices with the code. MIT is the most common and the simplest. Apache 2.0 adds an express patent license from contributors and a patent retaliation clause, which is why many companies prefer it. The BSD and ISC licenses are close cousins of MIT.
Copyleft licenses require that if you share software built on the licensed code, you share it under the same license, with source code. How far that reaches depends on the license.
Weak copyleft licenses (MPL, LGPL, EPL, and CDDL, which Sun Microsystems created for OpenSolaris) limit the obligation to the licensed component itself. If you modify an MPL file, you share that file, but your surrounding code can stay proprietary.
Strong copyleft (GPL) reaches the whole program that incorporates the code. The trigger is distribution: shipping software to customers, including on-premise installs, desktop and mobile apps, and code sent to the browser. Running GPL code only on your own servers generally isn’t distribution. AGPL closes that gap: if users interact with modified AGPL software over a network, you must offer them the source code. That is why most startups keep AGPL code out of their products unless they have reviewed the specific use.
Source-available licenses publish the code but restrict how you can use it, usually to stop cloud providers and competitors from offering the software as a hosted service. The Business Source License (BSL or BUSL) and the Functional Source License (FSL) allow most uses except competing ones and convert to an open source license after a set period. The Server Side Public License (SSPL) requires anyone offering the software as a service to release the source for their entire service stack. The Elastic License 2.0 prohibits offering the software as a managed service.
None of these are open source under the Open Source Initiative’s definition. Read the specific terms before building on them.
AI models come with their own licenses, and not all of them are open source. Some models are released under standard licenses such as Apache 2.0 or MIT. Others use custom licenses, such as Meta’s Llama community license or the RAIL family of licenses, which add acceptable-use restrictions, attribution requirements and, in some cases, limits on commercial use or on using outputs to train other models. Check the license for every model you build on, the same way you would for a code library. The law around AI and IP is new and likely to shift.
First, decide what you’re open sourcing. If code is a competitive advantage you want to keep proprietary, don’t open source it. Licensing something under the GPL doesn’t keep it proprietary.
If your goal is adoption, Apache 2.0 is the usual choice. It’s permissive, widely accepted by enterprise legal teams, and its patent license protects you and your users. MIT is fine if you want maximum simplicity. If you worry about a cloud provider hosting your project as a competing service, consider AGPL, often paired with a commercial license for customers who don’t want AGPL obligations (dual licensing), or a source-available license such as BSL or FSL. Make sure the company owns the code you’re releasing, and that every contributor has signed an invention assignment or a contributor agreement.
For how open source fits into your IP strategy and the risks of using it, see Open Source: What It Is and How It Works. For protecting the code you keep, see Should My Startup File a Copyright? If you’d like help reviewing the licenses in your codebase, contact us.
