Types of open source licenses

There are many different open source software licenses. Some licenses are “copyleft” or “reciprocal,” and require users to release any modifications made to the software under the same license. Examples include the GPL and AGPL licenses. Some licenses are “permissive,” and allow significant freedom to use the software for a variety of purposes, including within commercial products. Examples include the Apache, BSD, and MIT licenses.

Open source licenses are reviewed and approved by the Open Source Initiative, a standards body that maintains the Open Source Definition and Approved Licenses. The Free Software Foundation also has useful information about open source licenses, especially in the context of license compatibility.

Other intellectual property licenses you may be familiar with, such as Creative Commons (CC), are not appropriate for software. It’s fine to use more than one license for a project; i.e. a CC license for data and content, and a software-specific license for related code.

Choosing a License

Johns Hopkins University does not require the use of a specific open source license. Creators should choose the license that best fits the needs of their project and community.

Copyleft/Reciprocal Licenses

Choose a copyleft or reciprocal license for the protection it offers against proprietary software development.

If one of these sounds like you, you might choose a copyleft license:

  • I want to develop an open-source business around my software
  • My project will mostly be used by for-profit organizations
  • I don’t want people using my code in proprietary applications
  • I want to build a sustainable community

With a copyleft license any derivative works of your code must also be released under the same license, ensuring that your contributions to the open-source community remain freely available and accessible. This prevents companies from taking advantage of your work and incorporating it into proprietary software without giving back to the community. By choosing a copyleft license, you can safeguard the integrity and sustainability of the open-source ecosystem.

For copyleft/reciprocal licenses, the OSPO recommends the GPLv2 because it’s widely used and understood, making it easy to find resources and support.

Permissive Licenses

Choose a permissive license to foster wider adoption and collaboration.

If one of these sounds like you, you might choose a permissive license:

  • I’d like as many people as possible to use my software
  • I work in open science, and want people to be able to reproduce my research results
  • I want everyone to be able to use my code with no restrictions
  • My project has an outside funder, such as NASA, that requires permissive licensing when no other restrictions exist
  • I want to build a sustainable community

Permissive licenses do not impose restrictions on derivative works, allowing companies and individuals to incorporate your code into their proprietary projects without requiring them to release their own code under the same license.

This broader reach can significantly increase the impact of your work and fuel innovation in the software development community. Additionally, permissive licenses typically simplify the process of sharing and contributing to the code, encouraging more active participation from developers worldwide. By opting for a permissive license, you can democratize access to your code and maximize its potential to benefit the broader software ecosystem.

The most commonly used permissive licenses are MIT, BSD-3-clause, and Apache-2.0. The Apache-2.0 license includes an explicit patent grant, and the MIT and BSD-3-clause licenses do not.

Existing Community

When your project is related to an existing open source community

According to the website Choose a License, if you’re contributing to or extending an existing project, it’s almost always easiest to continue using that project’s license.

To find its license, look for a file called LICENSE or COPYING, and skim the project’s README. If you can’t find a license, ask the maintainers. Depending on the original project’s license, using the same license might be a requirement, not just the easiest thing to do. (See the “same license” condition of some licenses.) Some communities have strong preferences for particular licenses. If you want to participate in one of these, it will be easier to use their preferred license, even if you’re starting a brand new project with no existing dependencies.

Other Use Cases

  • My project is related to technology for which patents have been filed
  • My project is related to technology licensed by JHU to an outside company

Please contact Johns Hopkins Technology Ventures to discuss your options. Publishing source code under an open source license can negatively affect the exclusivity to certain intellectual property rights and may breach JHU’s obligations under existing license agreements.

Adding a License to Your Repository

Once you’ve chosen a license, the next step is to make sure that everyone looking at your code repository knows which license you chose.

  1. Create a license file named LICENSE or LICENSE.md and place it in the root directory of your repository.
  2. Copy and paste the license text into your LICENSE file.
  3. Commit the new file to your repository and push the changes.