Open source software is software with publicly available source code that is licensed to allow use, inspection, modification, and distribution by anyone. Source code is the human-readable instructions that tell a computer what to do. Source code is written in a programming language such as Python, Java, or C++.

An open source license is an intellectual property license and legal agreement that grants users certain rights to use, inspect, distribute, and modify the software.

Traditional copyright law generally restricts the use of copyrighted works without the permission of the copyright holder, while open source licenses outline uses for the software that are permitted by the copyright holder. Unless you never want another person to use or collaborate on your project, you should always license your code.

In this Article

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.

Copyright, Trademark, Patents & Licenses

Trademark

A trademark can be any word, phrase, symbol, design, or combination of these things that identifies an organization’s goods or services.

Copyright

A copyright in software grants the software owner the exclusive right to reproduce, distribute, and prepare derivative works of the software files.

Sample copyright notices

Copyright [year repository becomes public] The Johns Hopkins University

While the inclusion of a copyright notice is not required, it is common practice and provides a few benefits. The copyright notice informs the public of the owner of the work, which is commonly the author or the author’s employer.

The copyright owner has published the source code and other works stored in this repository for informational purposes only. The copyright owner grants no license to reproduce, prepare derivative works

Use if you are planning to make your code repository public, but do not wish to add an open source license.

General copyright laws, policies and procedures

Learn more about who holds copyright for your work

Patents

A patent in software grants the software owner the exclusive right to make, use, sell, and import products and processes that provide the software functionality. Some open source licenses grant users the right to exercise the software owner’s patent rights.

Explicit patent grants in open source licenses

Some open source licenses explicitly grant patent rights to anyone who receives the software. This means that anyone who uses, modifies, or distributes the software is also granted a license to the patents that cover the software. Examples of open source licenses with explicit patent grants include the Apache v2.0, GPL 3.0, and Eclipse 2.0 licenses.

Implied patent grants in open source licenses

Some open source licenses do not explicitly mention patents, but they have been interpreted by some commentators to implicitly grant patent rights based on broader legal principles. Open source licenses that do not have explicit patent grants include the MIT and BSD-3 and GPL 2.0 licenses.

Licenses

An open source license is an intellectual property license and legal agreement that grants users certain rights to use, inspect, distribute, and modify software. Organizations may refer to open-source software as inbound/in-licensed meaning open-source licensed software brought into the organization, or outbound/out-licensed meaning open-source software created by the organization and used by others.

Legal guidance for trademarks, copyrights, patents, and licenses

Case Study

A simplified explanation of how these protections apply to code created or used by a real-world organization.

  • Nintendo holds a trademark for the name Nintendo SwitchTM and the logo used for one of its video game consoles.
  • Nintendo holds the copyright for any source code they develop to run the Nintendo SwitchTM operating system or Nintendo-developed games.
  • Nintendo holds a patent for the controller used with the Nintendo SwitchTM. The controller combines elements of hardware and code into an invention with novel and practical utility.
  • Nintendo in-licenses code from other creators for use with the Nintendo SwitchTM, including open source code. Nintendo out-licenses its intellectual property, such as trademarked and copyrighted logos and characters for use on t-shirts, toys, and other merchandise.

Open Source Hardware

According to the Open Source Hardware Association, Open Source Hardware (OSHW) is a term for tangible artifacts — machines, devices, or other physical things — whose design has been released to the public in such a way that anyone can make, modify, distribute, and use those things.

Hardware is different from software in that physical resources must always be committed for the creation of physical goods. Accordingly, persons or companies producing items (“products”) under an OSHW license have an obligation to make it clear that such products are not manufactured, sold, warrantied, or otherwise sanctioned by the original designer and also not to make use of any trademarks owned by the original designer.

The current best practice recommendation is to use different licenses for hardware, software, and any project documentation. The European Organization for Nuclear Research (CERN) maintains a set of open hardware licenses for projects interested in both permissive and reciprocal sharing.

Licensing OSHW Projects

Learn More

If you need assistance choosing the right license for your project, reach out to the Open Source Programs Office (ospo@jhu.edu) and we can talk through the options.

  • Choose a License. “Choose an Open Source License.” Accessed September 29, 2023. https://choosealicense.com/.
  • “Disseminating Your Open Work.” Accessed December 7, 2023. https://openr.it/best-practices/disseminating.
  • “FSF Licensing & Compliance Team — Free Software Foundation — Working Together for Free Software.” Accessed December 7, 2023. https://www.fsf.org/licensing/.
  • Morin, Andrew, Jennifer Urban, and Piotr Sliz. “A Quick Guide to Software Licensing for the Scientist-Programmer.” PLOS Computational Biology 8, no. 7 (July 26, 2012): e1002598. https://doi.org/10.1371/journal.pcbi.1002598.
  • Open Source Initiative. “OSI Approved Licenses,” September 16, 2022. https://opensource.org/licenses/.
  • Skaife, David. “A Short Guide to Open Source Licenses.” Nationwide Technology (blog), September 16, 2021. https://medium.com/nationwide-technology/a-short-guide-to-open-source-licenses-cf5b1c329edd.