--- title: "The Complete Guide to Open Source Licenses | FOSSA Learning Center" description: "Understand the different types of open source licenses, how to choose the right one for your project, and ensure compliance across your software supply chain." canonical_url: "https://fossa.com/learn/open-source-licenses/" markdown_url: "https://fossa.com/learn/open-source-licenses.md" language: "en" author: "FOSSA" organization: "FOSSA" --- # The Complete Guide to Open Source Licenses | FOSSA Learning Center > Understand the different types of open source licenses, how to choose the right one for your project, and ensure compliance across your software supply chain. ## The Complete Guide to Open Source Licenses Understand the different types of open source licenses, how to choose the right one for your project, and ensure compliance across your software supply chain. #### Contents #### Related Resources - [##### Software Composition Analysis Learn how SCA tools help manage open source license compliance](https://fossa.com/learn/software-composition-analysis.md) - [##### Developer's Guide to Open Source Licenses A practical guide to license selection for developers](https://fossa.com/learn/developers-guide-open-source-software-licenses.md) - [##### SBOM Compliance Requirements Understand how SBOMs support license compliance initiatives](https://fossa.com/learn/sbom-compliance-requirements.md) ### Introduction to Open Source Licensing Open source licenses form the legal foundation that enables collaborative software development on a global scale. These licenses grant specific permissions to users while establishing certain conditions for the use, modification, and distribution of software. Without these licenses, open source software as we know it wouldn't exist, as copyright law would otherwise prevent anyone from using the code without explicit permission. The open source licensing landscape has evolved significantly over the past four decades, with hundreds of licenses now available to suit various goals and philosophies. While this variety offers flexibility, it also creates complexity for developers, users, and organizations trying to navigate compliance requirements. At their core, all open source licenses share a common purpose: they grant users the freedom to use, study, modify, and share software. However, they differ significantly in the conditions they impose on these freedoms, particularly regarding how modifications can be distributed and whether the software can be incorporated into proprietary products. ##### The Open Source Definition The Open Source Initiative (OSI) maintains the official Open Source Definition, which outlines the ten criteria a license must meet to be considered truly "open source": 1. Free redistribution 2. Source code availability 3. Permission to create derivative works 4. Integrity of the author's source code 5. No discrimination against persons or groups 6. No discrimination against fields of endeavor 7. Distribution of license 8. License must not be specific to a product 9. License must not restrict other software 10. License must be technology-neutral #### Evolution of Open Source Licensing 1980s ##### Free Software Movement Richard Stallman launches the GNU Project and Free Software Foundation, defining the four freedoms of free software. 1989 ##### GPL Released The first GNU General Public License is published, introducing the concept of copyleft licensing. 1998 ##### Open Source Initiative OSI founded to promote the term 'open source' with a focus on practical benefits, publishing the Open Source Definition. 2004 ##### Popular Permissive Licenses Apache License 2.0 released with patent grants. MIT and BSD licenses gain popularity for their simplicity. 2007 ##### GPLv3 Released GPLv3 addresses patent rights, hardware restrictions (Tivoization), and license compatibility issues. 2012 ##### Explosion of GitHub GitHub's rise leads to widespread adoption of permissive licenses like MIT for new projects. 2018 ##### Open Source Dominance Open source becomes the default approach for software development, with over 90% of applications containing open source components. 2023 ##### AI-Era Licenses New licenses emerge addressing AI training data and usage rights, adapting open source principles to new challenges. ### Types of Open Source Licenses Open source licenses can be broadly categorized based on the level of restrictions they place on users and developers. The two primary categories are permissive and copyleft licenses, with several specialized licenses that don't fit neatly into either category. ##### Permissive Licenses Permissive licenses place minimal restrictions on how the software can be used, modified, and redistributed. They typically only require attribution to the original authors. These licenses are popular for libraries and frameworks intended for widespread adoption, as they allow integration into both open source and proprietary software. Common permissive licenses include: - **MIT License** \- One of the simplest and most popular permissive licenses, requiring only that the original copyright notice and permission notice be included in all copies or substantial portions of the software. - **Apache License 2.0** \- A more comprehensive permissive license that includes patent grants and requires documentation of changes, making it suitable for larger projects. - **BSD License Family** \- A group of similar permissive licenses with varying requirements, generally requiring attribution and disclaimers. ##### Copyleft Licenses Copyleft licenses ensure that derivative works remain open source by requiring that any modifications or extensions also be distributed under the same license terms. These licenses promote open source sustainability by preventing proprietary forks but may deter some commercial adoption. Common copyleft licenses include: - **GNU General Public License (GPL)** \- The archetypal strong copyleft license, requiring that any work that incorporates GPL code must itself be distributed under the GPL. - **GNU Lesser General Public License (LGPL)** \- A weak copyleft license designed for libraries, allowing linking from proprietary software without triggering copyleft requirements. - **Mozilla Public License (MPL)** \- A file-level copyleft license that allows mixing with proprietary code at the file level, providing a middle ground between permissive and strong copyleft licenses. - **GNU Affero General Public License (AGPL)** \- An extension of the GPL that addresses the "network loophole" by requiring source code provision even when software is only accessed over a network. ##### Special Purpose Licenses Beyond the permissive-copyleft spectrum, various specialized licenses address unique requirements or edge cases: - **Ethical Licenses** \- Emerging licenses that restrict use in ways that violate certain ethical principles (such as human rights violations). - **Network Licenses** \- Licenses specifically designed to address software deployed as a service over networks. - **Data and Content Licenses** \- Licenses like Creative Commons designed for non-software content, documentation, or data. - **Community Licenses** \- Licenses designed to benefit specific communities or prevent certain types of commercial exploitation. #### Comparison of License Types Licenses that place minimal restrictions on how others can use, modify, and redistribute the software. They typically only require attribution back to the original author. ##### Key Features - Few usage restrictions - Allow use in proprietary software - Simple compliance requirements - High license compatibility - Commercial-friendly - Attribution requirements ##### Pros - Maximum adoption potential - Business-friendly - Simple to understand and comply with - Easy integration with other software - Allows for commercial use without complex obligations ##### Cons - Limited protection against proprietary derivatives - Competitors can use code without sharing improvements - May result in less community contributions - Possible fragmentation of the code base [Read More: Deep Dive on the MIT License](https://fossa.com/blog/open-source-licenses-101-mit-license.md) ### Selecting the Right License Choosing an appropriate license for your project is a critical decision that affects everything from adoption rates to contribution models. When selecting a license, consider your project goals, target audience, and the existing ecosystem. ##### Key Factors to Consider - **Project Goals** \- What are you trying to achieve with your project? Do you want maximum adoption, ensure all derivatives remain open, support a business model, or something else? - **Community Norms** \- Different programming languages and communities have different licensing norms. For example, JavaScript projects commonly use MIT, while Java projects often use Apache 2.0. - **Dependency Compatibility** \- Ensure your license is compatible with the licenses of your dependencies, particularly if you're incorporating copyleft-licensed code. - **Business Considerations** \- If you have commercial aspirations, consider how different licenses might affect business models and potential commercial adoption. - **Patent Protection** \- Consider whether you need explicit patent protection, which is included in Apache 2.0 but not in simpler licenses like MIT. ##### License Selection Resources These tools can help you choose an appropriate license: - [Choose a License](https://choosealicense.com/) \- GitHub's simplified guide to license selection - [TLDRLegal](https://tldrlegal.com/) \- Plain-language summaries of license terms - [License Differentiator](https://oss-watch.ac.uk/apps/licdiff/) \- Interactive license comparison tool [Read More: How to Choose the Right Open Source License](https://fossa.com/blog/how-choose-right-open-source-license.md) ### License Compliance Essentials License compliance involves fulfilling all the requirements specified in the licenses of the open source components you use. As organizations increasingly rely on open source, managing compliance across hundreds or thousands of components becomes a significant challenge. ##### Common Compliance Requirements - **Attribution** \- Almost all licenses require some form of attribution, typically by preserving copyright notices and including the original license text. - **Source Code Provision** \- Copyleft licenses require making source code available to recipients of the software, sometimes including modifications. - **Change Documentation** \- Some licenses (like Apache 2.0) require documenting changes made to the original code. - **License Propagation** \- Copyleft licenses require that derivative works be distributed under the same or compatible license terms. - **Notices Preservation** \- Many licenses require preservation of specific notices or files (like NOTICE files in Apache 2.0). ##### Common Compliance Pitfalls Organizations frequently encounter these compliance challenges: - Missing or incomplete attribution notices - Failure to recognize copyleft requirements - Incompatible license combinations - Inadequate tracking of open source components - Lack of clear policies for developers - Failing to account for transitive dependencies ##### Building a Compliance Program An effective open source compliance program typically includes these elements: 1. **Open Source Policy** \- Clear guidelines for developers about which licenses are approved, restricted, or prohibited. 2. **Component Inventory** \- A comprehensive Software Bill of Materials (SBOM) tracking all open source components and their licenses. 3. **Automated Scanning** \- Tools that automatically identify open source components and their licenses in your codebase. 4. **License Validation** \- Processes to verify compliance with license terms before release. 5. **Attribution Generation** \- Automated tools to generate required attribution notices and documentation. 6. **Developer Education** \- Training programs to ensure developers understand license implications. [Read More: Open Source License Compliance Policies](https://fossa.com/blog/heather-meeker-open-source-license-compliance-policies.md) ### Emerging Trends in Open Source Licensing The open source licensing landscape continues to evolve in response to new technologies, business models, and community values. Several notable trends are shaping the future of open source licensing: ##### AI and Machine Learning Considerations Traditional open source licenses weren't designed with AI and machine learning in mind, creating new challenges: - **Training Data Rights** \- Questions about whether using open source code to train models constitutes "use" under various licenses. - **Model Output Licenses** \- Debate over whether AI-generated content based on open source training data inherits license obligations. - **New AI-Specific Licenses** \- Emerging licenses specifically designed to address AI training and usage rights. ##### Ethical and Restricted Licenses A growing movement toward licenses that restrict usage based on ethical considerations: - **Anti-Use Clauses** \- Restrictions against usage for purposes like surveillance, weapons development, or human rights violations. - **Fair Use Licenses** \- Licenses that differentiate between community and commercial usage, with additional requirements for the latter. - **Compatibility Challenges** \- Tension between ethical restrictions and traditional open source definitions, which discourage use restrictions. ##### Commercial Open Source Strategies Companies are developing new licensing approaches to balance open source benefits with commercial viability: - **Source Available Licenses** \- Licenses that make source code visible but restrict certain uses, particularly by cloud providers. - **Time-Delayed Licenses** \- Models where code is initially proprietary but becomes open source after a set period. - **Dual Licensing Evolution** \- Refined approaches to offering both open source and commercial licensing options. ##### The Open Source Definition Debate These emerging licenses are sparking debate about the Open Source Definition (OSD) itself. Some argue that the definition should evolve to accommodate ethical restrictions, while others maintain that use restrictions fundamentally contradict open source principles. Organizations like the OSI continue to evaluate whether new licenses meet the established criteria for being truly "open source." #### Frequently Asked Questions [Request a Demo: FOSSA's License Compliance Solution](https://fossa.com/request-demo) #### Ready to take the next step? Learn more about how FOSSA can help your organization [Learn About FOSSA](https://fossa.com/product/open-source-license-compliance) ## Frequently asked questions ### What happens if I don't include a license with my code? Without a license, your code is automatically protected under copyright law, which means nobody else can use, copy, distribute, or modify your work without your permission. This is often the opposite of what developers want when publishing their code. By not including a license, you're effectively telling others they have no permission to use your code, which can severely limit adoption and collaboration. ### What's the difference between permissive and copyleft licenses? Permissive licenses (like MIT, Apache, BSD) allow users to do almost anything with the code, including using it in proprietary software, with minimal requirements (typically just attribution). Copyleft licenses (like GPL, AGPL) require that any derivative works also be distributed under the same license terms, ensuring all derivatives remain open source. Essentially, permissive licenses prioritize adoption and flexibility, while copyleft licenses prioritize ensuring code remains free and open. ### How do I choose the right license for my project? Choosing the right license depends on your goals for the project. If maximum adoption is your priority, consider a permissive license like MIT or Apache 2.0. If ensuring all derivatives remain open source is important, consider a copyleft license like GPL. Also consider your target users (businesses may prefer permissive licenses), your existing dependencies (for license compatibility), and community norms in your programming language or domain. Many communities have de facto standard licenses that can be a good starting point. ### Can I change the license of my project later? Yes, but with important caveats. You can only change the license if (1) you own all the copyright to the code, or (2) you get permission from all contributors. Many projects use Contributor License Agreements (CLAs) to make future license changes possible. When changing from a permissive to a more restrictive license, you generally can't retroactively restrict what users can do with previously released versions under the old license. This is why many projects use CLAs or have clear contribution policies from the start. ### What license compatibility issues should I be aware of? License compatibility issues arise when combining code under different licenses. Generally, permissive licenses (MIT, Apache 2.0) are compatible with most other licenses. Copyleft licenses like GPL create more restrictions - code under GPL can only be combined with GPL-compatible licenses. The resulting combined work must be distributed under the GPL. Some licenses have explicit compatibility clauses. When building software that combines multiple components, it's important to verify that all licenses are compatible with your intended use and distribution model. ### How do licenses affect commercial use of open source software? Most open source licenses allow commercial use, but with varying requirements. Permissive licenses (MIT, Apache 2.0) allow nearly unrestricted commercial use with simple attribution requirements. Weak copyleft licenses (LGPL, MPL) allow linking with proprietary code but require modifications to the open source parts to remain open. Strong copyleft licenses (GPL, AGPL) require that any software that incorporates the code must also be distributed under the same license, potentially affecting your ability to maintain proprietary code. Commercial users should carefully evaluate license requirements, especially for copyleft licenses. ## Source Canonical page: https://fossa.com/learn/open-source-licenses/