What are Open Source Licenses?

Open source licenses are legal agreements that define how software can be used, modified, and distributed. They grant specific permissions to users, ensuring that the source code is accessible and can be freely shared. While engineering teams once relied primarily on proprietary code, open source now comprises more than 90% of the components of modern applications.

The whole idea behind the Free and Open movements is basically giving it as a gift to everyone out there. There are some terms, usually a small request to give you some credit (usually a "hey, it's from me" kind of thing), but the whole point is to share the goodness.  This Open Source Definitiongoes onto more detail on what it all entails.

Exceptions

I Can Restrict It, Right? Right??

You can if you prefer, but one of the main advantages of open source code is its visibility, which makes it easier to troubleshoot problems and to understand better how something works when the documentation is either lacking or incorrect.

Depending on the type of open source license, you may even be allowed to modify the original source code to tailor it to your needs or fix any issues you find. The license will determine whether this is possible, and under what terms. For example, you may be required to make any modifications publicly available.

What you can't do is put on restrictions like "no commercial use" and still label your project as open-source. As the copyright holder, you've got the power to limit any use of your software or keep it all to yourself. It's your call. However, the Open Source movement is all about spreading the love without too many strings attached. You can put some rules on your software, sure, but if you go overboard, it's hard to call it genuinely open-source. Share the code, embrace the freedom!

I Discovered a project labeled as open-source, but it imposes limitations on commercial usage.

If you stumble upon a project claiming to be open-source while restricting commercial use, they're not playing by the rules—whether intentionally or not. Feel free to point them to this info. Some folks mistakenly use "open source" interchangeably with "source-available", but according to the OG open-source movement, there's a nuance. True open source means no heavy restrictions on how the software is used. Keep it free, keep it open!

That said there is a third option that is gaining traction—open-core service, combining open and closed sources characteristics.

Open-core

Open core adopts a distinct approach. This relatively new model exposes core functionalities to the public, encouraging collaboration, while reserving advanced features behind a paywall. It represents a hybrid model, enhancing accessibility while ensuring a sustainable business framework.
You can read further on it here Open source vs open core what is the difference

Types

There are over 200 open source licenses available, but most open source software falls under a handful of commonly used licenses. These licenses can be broadly categorized into two primary types: copyleft and permissive licenses.

• Copyleft: Copyleft licenses - require that any modifications or derivative works of the original open source code inherit the same license terms. This ensures that subsequent versions of the software also remain open source. Examples of popular copyleft licenses include the GNU General Public License (GPL) and the Affero General Public License (AGPL).

  • Copyleft licenses have lower usage:
  • The GPL family of licenses, including GPL-2, GPL-3, AGPL-3, and LGPL-3, only make up around 5% of the overall license usage.
  • This may be due to the restrictions imposed by copyleft licenses on the distribution of derived works.

• Permissive: Permissive licenses - provide more freedom for reuse, modification, and distribution of the software. They allow developers to incorporate the open source code into their own projects without requiring the resulting software to be open source. Examples of permissive licenses include the MIT License and the Apache License

• Permissive licenses are commonly used:

  • The most common permissive license in open source projects is the MIT license.
  • Apache 2.0 and BSD-3 licenses are also widely used, making up about 70% of the projects in the Libraries.io dataset.

But Can I Have 2 Licenses 🤔

You have the option to adopt a dual-license approach, a common model where your software is open-source under a copyleft license. While anyone can use it freely, the copyleft aspect can make commercial use more challenging. Simultaneously, you can offer a closed-source license for more freedom, selling these licenses to those wanting commercial usage rights. It's a win-win scenario for both parties. For example a dual license between CC0 and Apache-2.0 would work really well. CC0 effectively waives all copyright and related rights, including attribution. However, CC0 is less suitable for software, which is why the Apache fallback is recommended, despite some attached conditions.

However like previously mentioned another approach is open core, where essential features are open-source, fostering collaboration, while advanced features as paid add-ons.

To Clarify Open Source vs. Proprietary Software

Open source software (OSS) and proprietary software are two distinct types of software with key differences. Here are the main differences between open source and proprietary software:

1. Development and Licensing:

• Open source software is distributed with its source code, allowing users to freely inspect, modify, and distribute the code.
• Proprietary software is owned by the individual or company that published it and does not provide access to the source code.

2. Cost:

• Open source software is generally free to use and modify, although there may be costs associated with web hosting or server setup.
• Proprietary software requires companies to purchase a license, often using a subscription model known as Software as a Service (SaaS).

3. Updates and Maintenance:

• Open source software is often community-maintained, with periodic updates and patches.
• Proprietary software companies release regular updates with new features and bug fixes.

4. Flexibility:

• Open source software provides users with the freedom to use or modify the code as needed.
• Proprietary software is less flexible and often comes with restrictions on modification and distribution.

5. Ownership and Support:

• Open source software is developed and maintained by a community of contributors.
• Proprietary software is developed and maintained by the company or group that published it.

6. Intellectual Property Protections:

• Open source software typically has limited intellectual property protections.
• Proprietary software offers full intellectual property protections.

7. Examples:

• Examples of open source software include Android, Linux, and Firefox.
• Examples of proprietary software include Microsoft Office, Adobe Photoshop, and Apple macOS.

Now onto the Licenses 🎢

With over 200 licenses available, let's focus on the ones you're likely to encounter or use in your projects. If you don't find the specific one you're looking for here, I recommend checking the Open Source Initiative's license list for a comprehensive search.

1. Academic Free License v3.0 (AFL-3.0):

   • Type: Permissive
   • Pros: A permissive open-source license that allows you to modify and distribute the code as long as you attribute the original work and share your changes under the same license.
   • Cons: Less popular than some other licenses.

2. Apache License 2.0 (Apache-2.0):

   • Type: Permissive
   • Pros: Well-known, permissive license with clear attribution and notice requirements.
   • Cons: Requires including a copy of the license and notices in distribution.

3. Boost Software License 1.0 (BSL-1.0):

   • Type: Permissive
   • Pros: Permissive license with simple terms allowing modification.
   • Cons: Requires including the license in distribution.

4. BSD 2-clause "Simplified" license (BSD-2-Clause):

   • Type: Permissive
   • Pros: Extremely permissive license with simple terms.
   • Cons: Requires retaining the original copyright notice.

5. BSD 3-clause "New" or "Revised" license (BSD-3-Clause):

   • Type: Permissive
   • Pros: Permissive license with an additional clause for advertising use.
   • Cons: May be restrictive for some use cases.

6. BSD 3-clause Clear license (BSD-3-Clause-Clear):

   • Type: Permissive
   • Pros: Provides clarity and simplicity, similar to the 3-clause BSD.
   • Cons: May not be as widely recognized.

7. BSD 4-clause "Original" or "Old" license (BSD-4-Clause):

   • Type: Permissive
   • Pros: Permissive license with an endorsement clause.
   • Cons: Endorsement clause may limit usage.

8. BSD Zero-Clause license (0BSD):

   • Type: Permissive
   • Pros: Extremely permissive, no restrictions.
   • Cons: May not be well-known, uncommon.

9. Creative Commons license family (CC):

   • Type: Permissive (varies by specific CC license)
   • Pros: Offers various licenses for creative works with different restrictions.
   • Cons: Primarily designed for creative content, not software.

10. Creative Commons Zero v1.0 Universal (CC0-1.0):

    • Type: Permissive
    • Pros: Maximizes freedom, dedicates work to the public domain.
    • Cons: Not suitable for all software, may not be widely accepted.

11. Creative Commons Attribution 4.0 (CC-BY-4.0):

    • Type: Permissive
    • Pros: Attribution-based license, flexible for creative works.
    • Cons: May not be suitable for software, requires attribution.

12. Creative Commons Attribution ShareAlike 4.0 (CC-BY-SA-4.0):

    • Type: Permissive (with a share-alike requirement)
    • Pros: Encourages shared modifications with attribution.
    • Cons: May be restrictive for some software projects.

13. Do What The F*ck You Want To Public License (WTFPL):

    • Type: Permissive
    • Pros: Extremely permissive with no restrictions.
    • Cons: Not widely recognized.

14. Educational Community License v2.0 (ECL-2.0):

    • Type: Permissive
    • Pros: Designed for educational software, allows modification.
    • Cons: May not be well-known outside educational contexts.

15. Eclipse Public License 1.0 (EPL-1.0):

    • Type: Copyleft
    • Pros: Copyleft license encouraging contribution back to the community.
    • Cons: Requires derivative works to be licensed under EPL.

16. Eclipse Public License 2.0 (EPL-2.0):

    • Type: Copyleft
    • Pros: Updated version of EPL with similar copyleft requirements.
    • Cons: Derivative works must be EPL-licensed.
    • Basically:
    • Good - Similar to EPL-1.0, updated version.
    • Bad - Derivative works must be EPL-licensed.

17. European Union Public License 1.1 (EUPL-1.1):

    • Type: Copyleft but interoperable (non viral) and compatible with other licenses including GPL, AGPL, LGPL, EPL, MPL.
    • Pros: Originally designed for EU projects, open-source.
    • Cons: May not be known globally.
    • Basically:
    • Good - Covers remote "communication to the public" (online distribution), widely used in EU, promoted in the 27 Member States according to the 2024 Interoperable Europe Act, available in 23 languages, open-source (OSI and FSF approved).
    • Bad - May not be known globally.

18. GNU Affero General Public License v3.0 (AGPL-3.0):

    • Type: Copyleft
    • Pros: Strong copyleft license ensuring open access to modified code in network services.
    • Cons: May be too restrictive for some projects.

19. GNU General Public License family (GPL):

    • Type: Copyleft
    • Pros: Strong copyleft license promoting open-source community.
    • Cons: Requires derivative works to be GPL-licensed.

20. GNU Lesser General Public License family (LGPL):

    • Type: Copyleft (with limited copyleft for libraries)
    • Pros: A family of copyleft licenses, with different versions (2.1 and 3.0) that allow linking with non-GPL-compatible code.
    • Cons: Limited copyleft for libraries, not ideal for some projects.

21. GNU Lesser General Public License v2.1 (LGPL-2.1):

    • Type: Copyleft (with limited copyleft for libraries)
    • Pros: Allows linking with non-GPL-compatible code.
    • Cons: Less permissive for libraries than some other licenses.

22. GNU Lesser General Public License v3.0 (LGPL-3.0):

    • Type: Copyleft (with limited copyleft for libraries)
    • Pros: Updated version of LGPL with similar terms.
    • Cons: Limited copyleft for libraries.

23. ISC (ISC):

    • Type: Permissive
    • Pros: A permissive open-source license that allows almost unrestricted use, modification, and distribution.
    • Cons: May not be widely recognized.

24. LaTeX Project Public License v1.3c (LPPL-1.3c):

    • Type: Permissive
    • Pros: Permissive for LaTeX packages.
    • Cons: Primarily for LaTeX-related work.

25. Microsoft Public License (MS-PL):

    • Type: Permissive
    • Pros: Permissive open-source license from Microsoft.
    • Cons: Not recognized by all organizations.

26. MIT (MIT):

    • Type: Permissive
    • Pros: Highly permissive, widely recognized.
    • Cons: No significant drawbacks for most cases.

27. Mozilla Public License 2.0 (MPL-2.0):

    • Type: Permissive
    • Pros: Allows modification and distribution with source code.
    • Cons: Requires sharing changes to the code.

28. Open Software License 3.0 (OSL-3.0):

    • Type: Permissive
    • Pros: Promotes open-source and specifies distribution terms.
    • Cons: Requires sharing modified code.

29. PostgreSQL License (PostgreSQL):

    • Type: Permissive
    • Pros: Permissive license for PostgreSQL.
    • Cons: Primarily for PostgreSQL-related projects.

30. SIL Open Font License 1.1 (OFL-1.1):

    • Type: Permissive
    • Pros: Allows use, modification, and distribution of fonts.
    • Cons: Designed for fonts, not software.

31. University of Illinois/NCSA Open Source License (NCSA):

    • Type: Permissive
    • Pros: Permissive, designed for open-source software.
    • Cons: May not be widely known.

32. The Unlicense (Unlicense):

    • Type: Permissive
    • Pros: A license that essentially dedicates code to the public domain, allowing almost unrestricted use, modification, and distribution.
    • Cons: Not recognized by all organizations.

33. zLib License (Zlib):

    • Type: Permissive
    • Pros: Permissive, minimal restrictions.
    • Cons: May not be as well-known as other licenses.

Recommended

1. MIT License (MIT): This is one of the most permissive licenses. It's recommended for projects that want to maximize the freedom for users and contributors. It's simple, widely recognized, and used in many popular open-source projects.

2. Apache License 2.0 (Apache-2.0): It's a permissive license with clear terms. It's well-regarded for larger projects and those involving collaboration with corporations. It requires proper attribution and notice but provides legal protection.

3. GNU General Public License (GPL): If you want to ensure that derivative works of your project remain open source, GPL is a strong copyleft license. The GPL family includes GPL-2.0 and GPL-3.0, with the latter being the more modern and widely used version.

4. GNU Lesser General Public License (LGPL): LGPL is ideal for libraries and allows linking with non-GPL-compatible code. It ensures that modifications to the library are open source, but it doesn't extend the copyleft to applications using the library.

5. Mozilla Public License 2.0 (MPL-2.0): This license strikes a balance between strong copyleft and permissiveness. It's suitable for projects that want to encourage open-source contributions while allowing some proprietary use.

6. GNU Affero General Public License v3.0 (AGPL-3.0) ✨: AGPL is like the GPL but explicitly covers network-based software. It's recommended for projects that run on servers and want to ensure that any modifications to the code are shared. I actually recommend this blog for further reading on why its good - Why the MIT licensed is much more used than GPL-3

7. Creative Commons Attribution 4.0 (CC-BY-4.0): This is ideal for creative works like documentation or media files. It requires attribution and is flexible for non-software projects.

8. Unlicense (The Unlicense): If you want to put your code into the public domain, the Unlicense is recommended. It's incredibly permissive, allowing almost unrestricted use and modification.

Extra: Adding a License to You Repo on GitHub

I don't believe I can do it better than the GitHub docs on this one but a quick run down is:

1. Go to your repository.
2. Click on "Add File" and "Create new file" Button.
3. Type the file name as License.txt or License.md in the input box next to your repository name, a drop down button appears towards right side.
4. Choose the type of license of your choice.
5. Click "Review and Submit" button at the right side.
6. Choose "Commit directly to the main branch."
7. Click "Commit new file" button at the bottom (Green button)

That was quite a bit! I hope you found the information you were looking for. Thanks for reading, and catch you in the next blog! 🙌

Sources

• https://snyk.io/learn/agpl-license/
• https://gustavopinto.medium.com/why-the-mit-license-is-much-more-used-then-gpl-3-2b3fa4271d6b
• https://snyk.io/learn/open-source-licenses/
• https://snyk.io/learn/open-source-licenses/
• https://blog.sonatype.com/open-source-software-license-categories-explained
• https://www.quora.com/What-is-the-difference-between-a-proprietary-license-an-open-source-license
• https://www.heavybit.com/library/article/open-source-vs-proprietary
• https://www.nexcess.net/blog/open-source-vs-proprietary/
• https://snyk.io/learn/open-source-licenses/
• https://opensource.stackexchange.com/questions/9805/can-i-license-my-project-with-an-open-source-license-but-disallow-commercial-use
• https://www.citizenlab.co/blog/open-source/whats-the-difference-opensource-opencore/
• https://www.techtarget.com/searchitoperations/tip/Open-core-vs-open-source-Whats-the-difference
• https://en.wikipedia.org/wiki/Source-available_software?useskin=vector
• https://opensource.org/licenses/