License Management

ETH Zurich is not recommending or prohibiting the use of any specific open source license. Nevertheless, you must choose from the widely recognized licenses that are approved by the external page Open Source Initiative (OSI). These include popular options like the MIT License, Apache 2.0, and the GNU General Public License (GPL). Avoid creating custom or home-made licenses, as they can complicate compliance.

To select the license that best fits your project's goals, we encourage you to make informed decisions by accessing knowledge through our OSS Knowledge Base, in particular the OSS license risk chart and the OSS license selection flowchart,  which can help you understand the key differences of the licenses and guide you step-by-step to find a compatible license.

For more information of 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.

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 modify and distribute software under a strong copyleft license, you must release the modified source code 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 these sounds like you, you might choose a permissive license in the absence of other contractual obligation:

• 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 an external page explicit patent grant, and 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.

If one of these 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 software contains any patented technology, the license allows users to freely use those patents without infringing the rights of the original patent owner or the licensees. Typical OSS licenses with explicit patent grants include GPL 3.0, Apache 2.0 and Mozilla Public License (MPL). 

By distributing OSS under a patent-granting license, the users receive a license to use any patents that are essential to the functioning of the OSS. Thus, choosing a patent-granting license provides additional legal protection for users by preventing the patent owners from later suing them for patent infringement . 

On the other hand, unintended granting of patent rights via a OSS license can lead to a violation of policy and might bring damages to a licensee of such patent rights. A research group at ETH developed and patented a new technology to improve how robotic arms work. The patent also covers the software that makes this technology function. ETH gave 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 patented 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 patented software contained in the control sysstem. This could break the agreement with Company X, since ETH had granted the company the exclusive rights to use the patented software. As a result, Company X might sue ETH and the researchers for violating those rights. Therefore, if you are unsure about the 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.

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. It ensures that when you combine or distribute code under multiple OSS licenses, you do not violate the terms of any of the licenses involved.

License compatibility is important because: 

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 License Compatibility:

• Permissive licenses (e.g., MIT, BSD, Apache 2.0) are generally compatible with many other licenses, including copyleft ones, because they have fewer restrictions.
• Copyleft licenses (e.g., GPL) may not be compatible with more permissive licenses or proprietary software because they require derivative works to remain under the same license.

Analyzing license compatibility for a specific OSS project requires a thorough understanding of the license terms for 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 guidance to help you choose a suitable and compatible license for small to mid-sized OSS projects. For additional assistance with license selection and compatibility analysis, please feel free to contact us.

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 commercial license for those who need more flexibility, such as not wanting 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 can't or don't 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 own all the copyrights to the software. If contributions come from multiple developers under an open-source license, you’ll need their explicit permission to dual-license their contributions under a different license.

License Compatibility

If your software incorporates other open-source components, 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.

Copyleft Licenses

Dual-licensing is possible if you own the copyright. For example, you can release your software under the GPL for open-source use and offer a separate proprietary license for commercial users who don't want to comply with the GPL's copyleft requirements

Permissive Licenses

Permissive licenses are more flexible because they allow for more freedom in re-licensing. You can dual-license software with a permissive license more easily, since these licenses don't impose strict conditions on derivative works. Users can choose to adopt the open-source license or a proprietary license without additional obligations like releasing their source code. 

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

In all of these permissive licenses (MIT, BSD, Apache 2.0, ISC), the original code cannot be relicensed by subsequent contributors unless they are the original copyright holders. The priginal code must still be distributed under the same original permissive license. Subsequent contributors can relicense their modifications or derivative works under a different license. However, they must still comply with the terms of the original permissive license (e.g., providing attribution, including the license text, etc.) for the parts of the code that remain unchanged and are under the original license.

In contrast, copyleft licenses require the modified code to be distributed under the same license. Nevertheless, if the copyright owner of the OSS has the authority to relicense your software, including moving from a copyleft license to another OSS license or a proprietary license. Note that changing the license affects only new releases. Any versions of the software distributed under the old copyleft license remain under that license. Also, If you have received contributions from others, their contributions are typically governed by the original license terms. You would need to secure permission from contributors if you want to relicense those contributions or the entire project.