Licensing FAQ

The rights to use, inspect, distribute, and modify code are granted by the open source license, a legal agreement.

There are many different open source licenses.

Some open source 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 open source licenses are “permissive,” and allow users to do almost anything they’d like, including using the software in 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.

An open source license is an intellectual property license and legal agreement that grants users certain rights to use, inspect, distribute, and modify software. These rights are typically broader than those granted by traditional copyright law, which generally restricts the use of copyrighted works without the permission of the copyright holder.

Open source licenses are often used to encourage collaboration and innovation in software development. By making the source code of software freely available, developers can work together to improve the software and create new derivative works.

No, Johns Hopkins University does not require the use of specific open source licenses

Unless you never want another person to use or collaborate on your project, you should always license your code. Copyright law in the United States automatically grants a copyright in your code as soon as you create it. This means that others will not be able to use, inspect, distribute, and modify your code without permission. Without a license, only the owner of the software would possess these rights.

By choosing an open source license, you can grant others the rights to use, inspect, distribute, and modify your code under certain conditions. This can help to promote collaboration and innovation.

From the Creative Commons FAQ (citation below):

“We recommend against using Creative Commons licenses for software. Instead, we strongly encourage you to use one of the very good software licenses which are already available. We recommend considering licenses listed as free by the Free Software Foundation and listed as “open source” by the Open Source Initiative.”

“Unlike software-specific licenses, CC licenses do not contain specific terms about the distribution of source code, which is often important to ensuring the free reuse and modifiability of software. Many software licenses also address patent rights, which are important to software but may not be applicable to other copyrightable works. Additionally, our licenses are currently not compatible with the major software licenses, so it would be difficult to integrate CC-licensed work with other free software. Existing software licenses were designed specifically for use with software and offer a similar set of rights to the Creative Commons licenses.”

“Frequently Asked Questions – Creative Commons.” Accessed November 15, 2023. https://creativecommons.org/faq/#can-i-apply-a-creative-commons-license-to-software.

Yes. The copyright notice informs the public of the owner of the work, which is commonly the author or the author’s employer. The U.S. Copyright Office provides circulars that explain copyright laws, policies, and procedures for a general audience; for example, Circular 3, Copyright Notice.

A sample copyright notice:

Copyright [year repository becomes public] The Johns Hopkins University

If you are planning to make your code repository public, but do not wish to add an open source license, please add the following to the above copyright notice:

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 based upon, distribute, perform, or display the works stored in this repository.  

Not sure who holds the copyright for your work? Review the Johns Hopkins Intellectual Property Policy or contact Johns Hopkins Technology Ventures.

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

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

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. 

All open source licenses grant users the right to practice the software owner’s copyrights. Some open source licenses grant users the right to practice 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.

It is technically possible to create your own license, but it is not advisable. New licenses bring legal complexities, compatibility issues, and maintenance burdens that are out of scope for most open source projects. There are many existing, vetted licenses to choose from, all of which have been carefully crafted, legally reviewed, and tested through widespread adoption.

From the Open Source Hardware Association (OSHWA):

“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 full open-source hardware definition is available via: https://www.oshwa.org/definition/.

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. 

The licenses can be found here, and an extensive FAQ on open hardware licensing in general here. Software related to open source hardware can be licensed under any OSI-approved license, and documentation can be shared under Creative Commons licenses.

It depends! Why do you want to apply an open source license to your project?

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

• My project has an outside funder that requires that any code produced be released with an open source 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

Copyleft/Reciprocal response: Choose a copyleft or reciprocal license for the protection it offers against proprietary software development. 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. A list of additional copyleft/reciprocal licenses with strong community use can be found here at Choose a License.

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
• I want to build a sustainable community

Permissive licenses: Choose a permissive license to foster wider adoption and collaboration. 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.

For permissive licenses, the OSPO recommends the MIT, BSD-2, or Apache licenses.

Other use cases:

• My project is related to an existing open source community

Existing community: “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.”

Choose a License. “Existing Projects and Communities.” Accessed November 21, 2023. https://choosealicense.com/community/.

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

Please contact JHTV (https://ventures.jhu.edu/) 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.

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. Follow the steps below, or search the documentation for your version control platform (e.g. GitHub, Bitbucket) for more detailed instructions.

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.

No problem! Get in touch with the Open Source Programs Office (ospo@jhu.edu) and we can talk through the options. 

The information in this FAQ came from a variety of helpful sources, including:

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.