OSS License Management

At ETH Zurich, researchers are free to chose among OSS licenses and pick the license that fits best to their project goals. Note that you must choose from the widely recognized OSS licenses that are approved by the external page Open Source Initiative (OSI) according to the Open Source Definition. These include popular options like the MIT License, Apache 2.0, and the GNU General Public License (GPL). Avoid creating custom licenses, as they can complicate compliance.

To choose the license that best aligns with your project's goals, we encourage you to make informed decisions by familiarizing yourself with the permissions and restrictions of the most common OSS licenses, summarized in our OSS license risk chart. In addition, the OSS license selection flowchart, is designed to help you navigate key differences among the popular OSS licenses and guide you step-by-step to find a compatible license.

For a summary of the permissions, conditions, and limitations of a more complete list of OSI-approved OSS licenses, please refer to external page Choose A License.

If you need further asisstance for choosing OSS licenses, please don't hesitate to contact us at

Permissive, strong copyleft, and weak copyleft licenses are three main categories of OSS licenses, each with different levels of freedom and obligations for users.

Permissive licenses (e.g., MIT, Apache 2.0, BSD) offer the most flexibility. They allow users to freely use, modify, and distribute the software with minimal restrictions. Modifications can be integrated into proprietary projects, and there is no requirement to release the modified source code.

Note that almost all permissive licenses require that the original copyright notice be retained if you modify the code or integrate/embed it into your own software. They also typically include a disclaimer of warranty, meaning the software is provided "as is" without any guarantees of performance or liability.

See also external page Wikipedia for more information about permissive licenses.

Strong copyleft licenses (e.g., GNU General Public License [GPL]) impose stricter conditions. If you distribute software that includes (or links to) code -- in its original or modified form -- that is distributed under a strong copyleft license, you must release your software under the same or a compatible copyleft license. This ensures that any derivative works remain open-source and that the openness continues in all distributed versions.

As a result, any software that includes a component licensed under a copyleft license, even if it's just a few lines within a large codebase, must make its entire source code available and provide users with the rights to modify and distribute it.

Weak copyleft licenses (e.g., GNU Lesser General Public License [LGPL], Mozilla Public License [MPL]) offer a middle ground between permissive and strong copyleft licenses. The term "weak copyleft" refers to licenses where not all derivative works are required to inherit the copyleft license. These licenses typically mandate that modifications to the licensed code itself must be made open under a compatible copyleft license, but they allow other code linked to the licensed code to be released under different licenses.

"Weak copyleft" licenses are often used for software libraries or packages, allowing other software to link to the library and be redistributed without requiring the linked software to adopt the same copyleft license. This enables software of any license type to be compiled and linked with weak copylefted libraries and redistributed without the need to re-license the entire project.

See also external page Wikipedia for more information about copyleft 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.

If one of the statements below sounds like you, you might choose a permissive license in the absence of contractual obligations or third-party rights:

• 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. Many government and industry partners may only be able to contribute to a project with a permissive rather than a strong copyleft license, when no other restrictions exist.
• I want to build a sustainable community.

The most commonly used permissive licenses are MIT, BSD 3 clause, and Apache 2.0. Note that the Apache 2.0 license has the additional requirement that grants a patent license to users but also terminate that license if a related patent litigation is initiated, while the MIT and BSD 3 clause licenses do not.

Choose a copyleft license to ensure that any derivative works remain open-source and that the openness continues in all distributed versions. 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. On the other hand, if you are interested in commercializing your software or collaborating with industry partners now or at some later point, choosing a copyleft license needs to be considered carefully.

If one of the statements below sounds like you, you might choose a copyleft license:

• I don’t want people using my code in proprietary applications.
• My project will mostly be used by for-profit organizations.
• My software is to be used as a linked library/package (use the "weak copyleft" licenses).
• I want to build a sustainable community.

Patent granting licenses are a type of OSS license that not only grant permission to use, modify, and distribute the software but also include an explicit patent license. This means that if the OSS implements a patented technology, the license allows users to freely use those patents without infringing the rights of the patent owner or the licensees. Thus, choosing a patent-granting license provides additional legal protection for users by preventing the patent owners from later suing them for patent infringement. Note that this protection only holds against patents owned or controlled by the OSS licensor (i.e. ETH Zurich). It does not protect users against patent claims owned by third parties. Typical OSS licenses with explicit patent grants include GPL 3.0, Apache 2.0 and Mozilla Public License (MPL). 

Unintended granting of patent rights owned by ETH Zurich via an OSS license may lead to a violation of contracted rights and might bring damages to a licensee of such patent rights. For example, a research group developed and patented a new technology to improve how robotic arms work. The patent also covers the software that makes this technology function. The university granted Company X the exclusive right to use this software through an exclusive licensing agreement. A few years later, researchers from the same group used the software to help build a control system for the full robot. They then shared this system publicly on GitHub under the open-source license Apache 2.0, which grants a free license to anyone who use the software contained in the control system. This could break the exclusive licensing agreement between the university and Company X. As a result, Company X might sue the university and the researchers for violating those rights. Therefore, if you are not sure about patent rights that might relate to your OSS, it is generally recommended to be cautious and use licenses that DO NOT explicit grant patent rights, such as the MIT, BSD 3-Clause Clear License, and GPL 2.0. If you still are interested in using a patent granting OSS license, please contact us at before using such license. 

License compatibility in OSS refers to the ability of combining software components that are licensed under different OSS licenses without creating conflicts between the terms of those licenses. Two OSS licenses are compatible if: 

• the terms of both licenses don't contradict each other when codes are used together in the same project or file; AND
• you can distribute the combined work under a license that satify both original licenses.

License compatibility is important because of: 

Legal Compliance:

Different OSS licenses impose various conditions on the use, modification, and redistribution of software. If you combine incompatible licenses, you may unintentionally violate the terms of one or more licenses, which can result in legal consequences or the requirement to remove certain code from your project.

Distribution Flexibility:

License compatibility affects how you can distribute your software. If you use incompatible licenses, you may be limited in how you can legally share or commercialize your software. For instance, using code with a GPL license alongside proprietary code can force you to open-source your proprietary code, which may not align with your business goals.

Community Contributions:

If your project uses a license that isn’t compatible with the licenses of widely used OSS components, it could discourage others from contributing or collaborating, limiting the growth of your project.

Open-source Ecosystem Health:

Complying with license compatibility ensures that you respect the rights of other developers and maintain the principles of the open-source community.

Examples of general license compatibility:

• Permissive + Permissive (e.g., MIT + Apache 2.0): Your combined work can be distributed under almost any license (including more restrictive ones like GPL), and you're not forced to use a specific license, as long as you preserve the original copyright notices and include original license texts. 
• Permissive + Copyleft (e.g., MIT + GPL): Your combined project must be distributed under the copyleft license (e.g., GPL). That means the whole project must be GPL or compatible licenses because the copyleft license has a “viral” or “share-alike” clause that pulls the whole combined work under its terms.
• Copyleft + Copyleft: Some copyleft licenses are mutually compatible, others are not. The most commonly used compatible copyleft licenses include:
  • GPLv2-or-later + LGPLv2.1 LGPL is a weaker copyleft license that is explicitly designed to be compatible with full GPL. You can license the combined work under GPLv2 (or later).
  • GPLv3 + Affero GPLv3 (AGPLv3) AGPLv3 is essentially GPLv3 plus a network-use clause. You can upgrade from GPLv3 to AGPLv3. The combined work must be licensed under AGPLv3.

Analyzing license compatibility for a specific OSS project requires a thorough understanding of the detailed license terms of each component. This process can be particularly challenging for large projects with hundreds of OSS/data licenses. Our OSS License Selection Flowchart offers step-by-step guide for beginners to choose a suitable and compatible license for simple OSS projects. For additional assistance with license selection and compatibility analysis, please feel free to contact us at .

Please contact us at , if you plan to implement dual-licensing for your project. 

Dual-licensing in OSS is when a project is released under two different licenses, typically combining an OSS license with a proprietary license. For example, a project could be offered under a copyleft OSS license (like GPL) and a proprietary license* for those who need more flexibility, such as industrial partners who do not want to open-source their modifications.

You might consider dual-licensing if:

• You want to encourage open-source contributions while also allowing a commercial path for users who cannot or do not want to comply with the OSS license’s terms (like sharing modifications).
• Your project has commercial value, and offering a proprietary license can generate revenue while still supporting the OSS community.
• You want to maintain control over how the software is used in closed-source environments while fostering open collaboration under an OSS model.

If you want to consider dual-licensing, here are key factors to keep in mind:

Owership of Copyright

To successfully implement dual-licensing, you must ensure that ETH Zurich has the exclusive use and exploitation rights (economic copyright) to all components of the software. If contributions come from external developers under an open-source license, you’ll need their explicit permission to dual-license their contributions under a different license. Such permission could be collected via the contributor license agreement. 

License Compatibility

If your software incorporates other open-source dependencies, you must ensure that the licenses of those components are compatible with dual-licensing. For instance, combining GPL-licensed software with non-GPL software may impose restrictions on your ability to offer the software under both an open-source and proprietary license.

* Please note that the Exploitation Guidelines (RSETHZ 440.4) authorizes its researchers to distribute the software they created as open source software. But for the proprietary licensing of the software in a dual-licensing setting, the software needs to be disclosed to ETH transfer – IP&L in writing using the “Software disclosure” form. Please refer to Licensing Software for more instructions.

Please contact us at , if you plan to relicense your project. 

Relicensing of OSS involves changing the license under which the software is distributed. It can be necessary or advantageous to address compatibility issues or align with exploitation goals. 

• Compatibility: If you want to integrate your OSS project with other software that is licensed differently, relicensing may be required to ensure compatibility between the licenses.
• Commercialization: If you plan to commercialize your OSS project or seek funding, you might need to change the license to one that aligns better with your business model or investment requirements.
• Project Evolution: As projects evolve, the initial license may no longer fit the project's needs. Relicensing can provide more flexibility or align with new goals.
• Legal Issues: If there are legal concerns or if the original license is found to have issues, relicensing can help address these problems.
• Community and Contributor Preferences: If the project community or contributors prefer a different license, relicensing might be considered to better reflect the project's goals and the contributors' wishes.

Eligibility for relicensing

Only the copyright owner(s) of the software, or someone who has permission from all other copyright holders, can legally relicense their work. Therefore, similar to dual licensing, only if ETH Zürich has the exclusive use and exploitation rights (economic copyright) to all components of the software, or if any external contributors have assigned copyright to ETH Zurich (e.g., via Contributor License Agreements), the project maybe relicenced under another OSS license or even a proprietary license. Please contact us if you want to relicense your project. 

Important considerations 

• Relicensing does not rewrite history. Once code is released under a given license (e.g. MIT or GPLv2), that version remains available under those terms, even after you change the license for future versions.
• License compatibility. 
  • Permissive → Copyleft or Proprietary. If your entire project is originally licensed under MIT, BSD, etc., which means all components are licensed under permissive or compatible licenses, you can relicense your entire project to GPL, LGPL, Apache, or even proprietary without explicit permission from the copyright owner of each component, as long as you retain the original permissive license text and attribution for each component. This is because the permissive licenses are generally compatible with more restrictive licenses so that you can relicense the entire project without the need to relicense each permissive component. 
  • Copyleft → Permissive or Proprietary. Moving from GPL (or similar copyleft) to a permissive or proprietary license is only allowed if ETH Zürich holds the copyright of every line of code in the project because any third-party GPL component contained herein cannot be distributed under a non-copyleft license.