Frequently asked questions about licensing open source software.

  • What is open source software?

    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++.

    Examples of open source software include the Linux operating system, the Firefox Web browser, and the WordPress content management system.

    Examples of proprietary (closed-source) software include the Windows operating system, the Safari Web Browser, and the Adobe creative suite.

  • What is an open source license?

    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 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.

  • What does it mean to use an open source license?

    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.

  • Does Johns Hopkins require a specific open source license?

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

  • My project isn’t very big. Do I even need a license for my code?

    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.

  • I’m using a Creative Commons license for my data. Can I use the same license for my code?

    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.

  • If I add a license, do I also need a copyright notice?

    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

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

  • I would like to make my code public, but not open source - what do I do?

    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.

  • What is the relationship among trademarks, copyrights, patents, and licenses?

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

    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. 

    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.

    Concepts like trademarks, copyrights, licenses, and patents are complex, and JHTV remains the best resource at Hopkins for specific legal guidance. However, here’s 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 Switch™ 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 Switch™ operating system or Nintendo-developed games.

    Nintendo holds a patent for the controller used with the Nintendo Switch™. 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 Switch™, 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.

  • What are implicit and explicit patent grants?

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

  • Can I create my own open source license?

    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.

  • What is open source hardware?

    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:

  • Can I use the same open source license for hardware and software?

    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.

  • Which open source license should I choose for my software project?

    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:

    • 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
    • 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: 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.

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

    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.

    • 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 ( 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.

  • I’ve chosen a license. Now what?

    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 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.
  • I’m still not sure which license to choose.

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

  • I want to learn more!

    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.

    “Disseminating Your Open Work.” Accessed December 7, 2023.

    “FSF Licensing & Compliance Team — Free Software Foundation — Working Together for Free Software.” Accessed December 7, 2023.

    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.

    Open Source Initiative. “OSI Approved Licenses,” September 16, 2022.

    Skaife, David. “A Short Guide to Open Source Licenses.” Nationwide Technology (blog), September 16, 2021.