Open source licenses govern how software can be used, modified, and distributed. Choosing the wrong license can inadvertently give away proprietary rights or create compliance nightmares. Using open source code without understanding license obligations exposes companies to legal risks. This guide demystifies popular licenses, explains compliance requirements, and helps you choose the right license for your projects or safely use others' open source code in commercial applications.
Permissive vs. Copyleft Licenses
Open source licenses fall into two broad categories with fundamentally different philosophies and requirements.
For more insights on this topic, see our guide on Software Architecture Patterns: Choose the Right Structure for Your Application.
Permissive licenses: These licenses allow maximum freedom to use, modify, and distribute code, including in proprietary applications. You can take permissively licensed code, modify it, and include it in closed-source commercial software with minimal restrictions. Examples include MIT, BSD, and Apache 2.0. These licenses typically require only attribution and inclusion of the license text.
Copyleft licenses: These licenses require that derivative works be distributed under the same license. If you modify GPL-licensed code and distribute the modified version, you must release your changes under the GPL as well. This "viral" quality ensures that improvements to open source software remain open source. GPL, AGPL, and MPL are copyleft licenses with varying strengths.
MIT License
The MIT License is the most popular permissive license, favored for its simplicity and flexibility.
What it allows: Commercial use, modification, distribution, and private use with minimal restrictions. You can use MIT-licensed code in proprietary software, modify it without releasing changes, and distribute in any form including compiled binaries.
Requirements: Include the original license and copyright notice in all copies or substantial portions of the software. That's it. No requirement to open-source your modifications or disclose use of the library.
Advantages: Maximum flexibility and minimal compliance burden. Works well for libraries intended for broad adoption including commercial use. Popular with startups and enterprises alike because it poses minimal legal risk.
When to choose it: If you want your project to be widely adopted without concern for whether improvements are contributed back. Ideal for libraries and frameworks where broad commercial adoption is more valuable than ensuring modifications remain open source.
Apache License 2.0
Apache 2.0 is similar to MIT but provides additional protections and patent grants.
What it allows: Like MIT, permits commercial use, modification, distribution, and private use. Explicitly grants patent licenses from contributors, providing extra protection against patent litigation.
Requirements: Include license and copyright notices, state significant changes, and include NOTICE files if present. More documentation requirements than MIT but still permissive regarding modifications.
Patent protection: Contributors automatically grant patent licenses for their contributions. If someone contributes code to your Apache-licensed project, they can't later sue you for patent infringement based on that code. This protection is valuable for enterprise software.
When to choose it: For projects where patent protection matters. Enterprise software, infrastructure tools, and projects with many contributors benefit from Apache 2.0's patent clauses. Preferred by many large tech companies for this reason.
GNU GPL (General Public License)
The GPL is the most popular copyleft license, ensuring that software and its derivatives remain free and open source.
What it allows: Use, modification, and distribution, but with strong copyleft requirements. If you distribute GPL software or modifications of it, you must provide source code under the GPL to recipients.
Requirements: Distribute source code with binaries (or offer to provide it). License derivative works under the GPL. Include license and copyright notices. State changes made to the original code. These requirements ensure recipients have the same freedoms you had.
Viral nature: The controversial aspect of GPL is its "viral" quality. If you incorporate GPL code into your application, the entire application becomes a derivative work requiring GPL licensing. This makes GPL unsuitable for proprietary commercial software that incorporates GPL libraries.
When to choose it: When you want to ensure modifications remain open source and benefit the community. Suitable for complete applications rather than libraries that others might incorporate into proprietary software. Many GNU tools and Linux itself use GPL.
GNU AGPL (Affero General Public License)
AGPL closes a perceived loophole in GPL regarding software as a service.
Network copyleft: Like GPL but adds a requirement that users interacting with modified software over a network (like accessing a web application) must be able to receive the source code. This prevents the SaaS loophole where companies modify GPL software, run it on servers, and never distribute it—thus never triggering GPL's source code requirements.
Impact on SaaS: If you modify AGPL software and offer it as a service, you must provide source code to your users. This makes AGPL unsuitable for commercial SaaS businesses using or modifying AGPL-licensed code unless they're willing to open-source their modifications.
When to choose it: For server software where you want to prevent commercial entities from building proprietary services on top of your code without contributing back. MongoDB originally used AGPL to encourage commercial users to purchase licenses rather than building competitive services.
Mozilla Public License (MPL)
MPL is a middle ground between permissive and strong copyleft licenses.
File-level copyleft: Modifications to MPL-licensed files must be released under MPL, but you can combine MPL code with proprietary code in the same project as long as they're in separate files. This "weak copyleft" allows MPL libraries to be used in proprietary software more easily than GPL.
When to choose it: When you want to ensure modifications to your code are contributed back but don't want to prevent commercial use entirely. Good compromise for libraries that want some copyleft protection without GPL's viral restrictions.
License Compatibility
Combining code under different licenses can create legal conflicts. Understanding compatibility prevents compliance violations.
Permissive license compatibility: MIT, BSD, and Apache-licensed code can generally be combined freely. You can use Apache-licensed libraries in MIT-licensed projects and vice versa. Just comply with each license's requirements (attribution for all, patent grant for Apache).
GPL compatibility: GPL is incompatible with proprietary licenses and many permissive licenses in certain combinations. You can use MIT or Apache code in GPL projects (the result is GPL-licensed). But you can't use GPL code in proprietary projects or incorporate it into Apache-licensed projects without GPL'ing the whole thing.
AGPL compatibility: AGPL is even more restrictive. Combining AGPL with GPL requires upgrading to AGPL. AGPL is incompatible with most commercial software licenses.
Compliance Best Practices
Using open source software requires compliance with license terms. Failures can result in lawsuits and forced open-sourcing of proprietary code.
Maintain a software bill of materials: Track all open source dependencies, their licenses, and versions. Tools like FOSSA, Black Duck, or WhiteSource automate scanning for open source usage. Know what licenses you're subject to before you ship products.
Automated license scanning: Integrate license checking into CI/CD pipelines. Fail builds if incompatible licenses are detected. This prevents accidental introduction of GPL code into proprietary products during development.
Include required notices: Bundle license files and copyright notices with distributions. For web applications, create an About or Licenses page listing open source components and their licenses. This satisfies attribution requirements for permissive licenses.
Review before distribution: The key trigger for most license obligations is distribution. Internal use of GPL software doesn't require source disclosure. But distributing binaries to customers or deploying AGPL as a service triggers obligations. Review compliance before each release.
Dual Licensing Strategies
Some projects offer code under multiple licenses, allowing different terms for different use cases.
How it works: The copyright holder can license the same code under multiple licenses simultaneously. Users choose which license to comply with. Common pattern is GPL plus a commercial license—users who can comply with GPL use it free, while companies wanting to include the code in proprietary products purchase commercial licenses.
Business model: Open core companies often dual-license. The core product is GPL or AGPL, encouraging open source adoption and community contributions. Enterprises that can't comply with copyleft requirements pay for proprietary licenses. This model funds development while keeping code open source.
Choosing a License for Your Project
Consider your goals, target users, and business model when selecting a license.
- Maximize adoption: Choose MIT or Apache 2.0. Permissive licenses remove barriers for commercial adoption. Startups building developer tools typically choose permissive licenses.
- Ensure improvements return: Choose GPL or AGPL. Copyleft licenses prevent proprietary forks that don't contribute back. Suitable when community contributions are core to the project's value.
- Protect patents: Choose Apache 2.0. Explicit patent grants protect contributors and users. Important for infrastructure software and projects with corporate contributors.
- Prevent SaaS profiteering: Choose AGPL. Forces cloud providers offering your software as a service to open-source modifications. Note this may reduce enterprise adoption.
Common Pitfalls
Avoid these mistakes that create legal exposure or limit project growth.
No license means no rights: Code without a license is copyrighted by default with no usage rights granted. Don't assume unlicensed code on GitHub is free to use. Always check for a LICENSE file or contact the author.
Ignoring transitive dependencies: Your direct dependencies may pull in other libraries with different licenses. A permissively licensed library might depend on a GPL library, making your project subject to GPL. Check the entire dependency tree.
Assuming GPL only applies to distribution: While GPL primarily triggers on distribution, AGPL triggers on network use. If you're running a web service with modified AGPL code, source disclosure applies even though you're not distributing binaries.
Related Reading
- Automated Testing Guide: Build Reliable Software with Comprehensive Test Coverage
- Monorepo vs Multirepo: Choosing Your Code Organization Strategy
- Technical Debt Management: Balance Speed and Code Quality
Need Help with Open Source Compliance?
Our team can audit your dependencies, ensure license compliance, and help choose the right license for your projects.
Get Compliance Help