OSS Policies and Best Practices

According to external page Art. 36 of the Swiss Federal Act on the Federal Institutes of Technology (the ETH Act), ETH Zurich holds the exclusive use rights to software created by its employees within the scope of their employment. This means that only ETH Zurich can determine who and under what conditions can access, use, distribute, and redistribute (including license and sueblicense) the code. In this sense, ETH Zurich is regarded as the copyright "owner" or "holder" of such software.

On the other hand, software copyright created by a student with no employment contract with ETH Zurich, such as a bachelor or master student, originally belongs to the student.

If the student collaborates in research projects with ETH Zurich, the project often needs to be further developed or utilized by ETH Zürich after the student leaves. In such cases, it is strongly recommended that the responsible professor asks the student to transfer his/her IP rights (including software copyright) created in the project to ETH Zurich to ensure seamless development and use of all research results.

If the student wishes to participate in research projects that fall under a collaboration between ETH Zurich and a third party, where the ownership of IP rights has been contractually agreed upon, the responsible professor must ensure that the student transfers his/her IP rights (including software copyright) created in the project to ETH Zurich before participating in that project. 

After transferring his/her IP to ETH Zurich, the student will receive compensation for any income ETH Zurich generates from his/her contribution, in a way similar to ETH Zurich employees. Also, the student retains his/her right to have his/her authorship of and/or other contributions to publications acknowledged in accordance with Art. 12–15 of the ETH Zurich Integrity Guidelines (RSETHZ 414).

To enable IP transfers from non-employee students, we provide protected page IP assignment agreement template, which include an assignment of copyrights associated with OSS. The agreement must be signed by the student and the supervisor or the responsible Research Group Leader (normally professors or heads of platforms and scientific facilities, as defined in Article 3, Para. 9 of the Guidelines for Research Data Management at ETH Zurich (RSETHZ 414.2)). For any questions, please feel free to contact us at .

To facilitate the use and distribution of OSS, under the ETH Zurich IP and Exploitation Regulations (RSETHZ 440.4), ETH Zurich as the copyright holder (see above) authorizes the responsible Research Group Leader (typically the professor) to decide whether to release software under an open source license, even if he or she is not a creator of the software. Accordingly, the responsible Research Group Leader is also responsible for ensuring that any OSS release complies with the conditions required by the Guidlines and set out here.

In case of conflicts of interest*, the decision must be approved by all creators and the responsible Research Group Leader. If they fail to reach an agreement, the Vice President for Knowledge Transfer and Corporate Relations (VPKC) shall decide.

To ensure transparency and proper documentation, we strongly recommend that all ETH Zurich creators and the responsible Research Group Leader co-sign a simple one-page protected page acknowledgment form. It serves to confirm the OSS release (including release of future versions), the selected OSS license, and the authorship. It ensures informed consent while helping prevent potential authorship disputes.

* As defined in Article 21 of the Integrity Guidelines (RSETHZ414), "a conflict of interest exists if the person involved could have an interest in the outcome of a decision whether personally, professionally, or financially, or as representative of an institution, namely because he or she or the institution he or she represents could gain an advantage or disadvantage from the decision." A conflict of interest may arise, for example, if a professor chooses to open-source software developed in a research project that could benefit a company, for which the professor serves as a consultant, or a spin-off, in which the professor holds an equity stake.

OSS often contains source codes or data developed by third parties, either under open source licenses or customized licenses. The responsible Research Group Leader(s) must ensure that all third-party codes/data are used in compliance with their own license terms.

• For third-party codes under OSS licenses, make sure their licenses are compatible when combined in the same OSS package. Please refer to "license compatibility" on our webpage OSS License Management.
• Third-party codes under non-commercial licenses. Many individuals and organizations distribute software under non-commercial licenses. These licenses typically permit free use for research and educational purposes while reserving commercial rights for the copyright holder. Because non-commercial restrictions limit how the software may be used, such licenses are generally not considered open source licenses under the definitions of the external page Open Source Initiative and are often incompatible with widely used open-source licenses. For example, GPL-family licenses do not permit additional restrictions, such as limitations on commercial use, on either the original software or derivative works. If you plan to incorporate third-party code under a non-commercial license into your OSS project, please contact us () before release for a detailed license compatibility assessment.
• Third-party code under proprietary licencss (e.g. from a software vendor) must not be included in an OSS repository if the license prohibits public disclosure, which is usually the case. Doing so would breach the license and expose both the creators and ETH Zurich to legal risks. In exceptional cases, if inclusion in OSS may be permitted, the creators must obtain explicit written permission from the vendor before publishing the source code.
• Code developed using proprietary platforms such as MATLAB, LabVIEW, Cadence, Keysight, or Altium is not automatically proprietary—but the license terms may limit what you can do with the output. There are three common scenarios:
  • For code you wrote yourself using the tool as an editor or environment, such as MATLAB .m scripts you wrote manually or LabVIEW logic you designed from scratch, you or your employer own the copyright and may open source it.
  • For proprietary vendor libraries, toolboxes, or runtime code, such as MATLAB proprietary toolboxes or LabVIEW runtime modules, you cannot open-source these components or include them in an open-source repository. You may reference them as external dependencies, if explicitly allowed by the license. 
  • Automatically generated code, such as MATLAB/Simulink auto-generated C code, may include proprietary runtime components, headers, or libraries and thus requires careful review.

When in doubt, (1) if the software was purchased via IT Shop/Procurement of ETH Zurich, please contact Ralph Curschmann to clarify whether open-sourcing is permitted for your code and to determine any required steps or conditions; (2) if the software was purchased directly by the lab, please contact the vendor, explain the intended use of the code, and obtain explicit permission before publishing the generated code.

ETH Zurich researchers must use an external page open source license approved by the Open Source Initiative (OSI) when releasing OSS. The OSI-approved OSS licenses include the well recognized MIT, BSD, Apache 2.0, and GPL licenses. Customized open source licenses are not allowed. Make sure to include the text of the selected OSS license as a top-level LICENSE file in your package or repository. You can find a list of OSI-approved open-source licenses external page here.

The selected OSS license must be compatible with the licenses of all third-party code and data used in the software.  Please refer to our webpage OSS License Management for further guidance on choosing a compatible OSS license.

Further, as best practice, the selected OSS license should align with the goals of the research project and any exploitation plans. Please see the Best Practices section below for more information. 

OSS is typically distributed without restriction on public platforms like GitHub, SourceForge, or on-premise GitLab. Thus, you should assume that the OSS is exported outside the border of Switzerland. For more information, please refer to the guidelines on Export Control for Software.

We strongly recommend verifying in advance whether an export authorization from the State Secretariat for Economic Affairs (SECO) is necessary, especially if your software falls under the following categories:

• Software for Information Security
• Software for Surveillance/Control of the Internet and Mobile Networks

It is the responsibility of the Research Group Leader to verify whether the software is classified as a controlled item and if a SECO authorization is required.

If the software has never been distributed or exported before and the software appears on the export control list, you must obtain an export authorization from SECO before releasing the software under an open source license on public platforms. Please contact Export Control for detailed guidance. 

Nearly all OSI-approved licenses, such as MIT, BSD, Apache 2.0, and the GPL licenses, require the inclusion of the copyright notice as a condition for using the license. Also, it is a best practice to credit the software creators in an authorship notice, separate from the copyright notice.

To ensure clarity and alignment with copyright laws and standard OSS procedures, OSS developed at ETH Zurich must include a copyright notice that contains the © or (c) mark, the year of release, and the name(s) of the copyright holder (ETH Zurich). The OSS must also credit the creator(s) in an authorship notice, separated from the copyright notice to avoid misleading, for example: 

©2026 ETH Zurich

Creators/Created by: [Name of Author 1], [Name of Author 2], etc.

When there are multiple copyright holders, e.g., copyright shared by multiple organizations in a collaboration project, their names should be listed on the same line following the © mark and the year of release and separated by commas, for example: 

©2026 ETH Zurich, [Name of Copyright Holder 2], [Name of Copyright Holder 3], etc.

Creators/Created by: [Name of Author 1], [Name of Author 2], etc.

Where to place the copyright and authorship notices? 

• The copyright and authorship notices are commonly placed in the README file, as well as in a top-level LICENSE file that contains the full license text, the copyright notice, and the authorship notice. 
• For simple OSS, including a short license notice and a copyright notice at the top of each source file (e.g.,  .java, .py, .c, .js, etc. files) as a header comment is considered good practice. 
• It is also very common for OSS projects to maintain a AUTHORS or CONTRIBUTORS file.

Different OSS licenses have varying requirements, such as copyleft (e.g., GPL requiring derivative works to be open-source) and commercial use restrictions. License compatibility ensures that all components of an open-source software project can be legally combined and distributed under the intended open source license. 

Given that OSS creators often build upon each other's work, it is strongly recommended to always review a third-party code's license BEFORE including it in your project. If the third-party code's license is not compatible with the project’s OSS license or the exploitation goals, replace it with another code that serves similar functions and bears a compatible license.

To help streamline this process, we provide license management tools on our webpage OSS License Management, particularly the OSS License Risk Chart and the License Collection Worksheet.

If a research project involves developing software with contributions from both ETH Zurich employees and non-employees, the copyright for employee-created work belongs to ETH Zurich, while non-employee creators retain copyright over their own work.

Since software copyright includes exclusive rights to use, distribute, and license the code, any future use, such as licensing it as proprietary software or open source, requires approval from all copyright holders. This can create significant administrative challenges, especially if non-employee creators leave the project and become difficult to contact.

To avoid this issue, the ETH Research Group Leader should ask the non-employee creators to assign their software copyright to ETH Zurich using the IP assignment agreement (template). Given that software creators often build upon each other's work, it is strongly recommended to confirm the copyright transfer BEFORE contributions are made to the project. This prevents complications later if a non-employee creator refuses to transfer his or her rights, which could require separating his or her code from the project.

​Selecting an appropriate OSS license is a critical decision that directly affects a project's influences and its potential for commercialization. 

Aligning license choice with project goals

Consider what you aim to achieve with your project:

• Encouraging widespread use: If you want as many people as possible to use and build upon your software, a permissive license like MIT or Apache 2.0 allows for broad usage with minimal restrictions.
• Protecting open contributions: To ensure that any improvements or derivatives remain open-source, a copyleft license such as the GNU General Public License (GPL) requires that modified versions also be released under the same terms.
• Balancing open source with commercial interests: If you plan to offer a free version while selling premium features, a dual licensing strategy might be appropriate. This often involves using a copyleft license for the open-source version and a separate commercial license for proprietary use.

Potential pitfalls in license selection

Choosing an inappropriate license can lead to often irreversible challenges:

• Limiting adoption: A highly restrictive license might deter developers or companies from using your software, reducing its potential impact.
• Legal conflicts: Choosing a OSS license that is incompatible with those of the background codes and databases can create legal issues, complicating development and distribution. 
• Unintended commercial exploitation: A permissive license might allow others to profit from your work without contributing back, which could be contrary to your intentions.

Please refer to our webpage OSS License Management for further guidance on OSS licensing strategies. 

Open source licenses and open data licenses serve different purposes and should not be used interchangeably. Open source licenses, such as MIT license, GPL, and Apache 2.0, govern the use, modification, and distribution of software code, while open data licenses, such as Creative Commons Attribution (CC BY), cover the use and sharing of datasets. Using an OSS license for data could result in unclear legal rights regarding the data's reuse, distribution, and attribution, and vice versa.

For more information about open data licenses, please proceed to Open Data

OSS that implements a patented inventinon or is in other ways related to a patented invention requires particular caution because many open source licenses include clauses that explicitly or implicitly grant patent rights (Apache 2.0, GPL v3, etc. See the OSS License Risk Chart for more infomation). When software is released under such licenses, the licensor automatically grant users the right to use, modify, and commercially exploit the patented invention embedded in the code. This can directly conflict with the intention to retain exclusive control over the patented technology or to license it commercially at a later stage. 

Even after a patent has been filed and the underlying invention can be published—for example, in journal publications—special care must be taken when providing supplementary code with the publication. Such code often demonstrates how the patented technology works in practice and is frequently shared under open source licenses during the peer review process. As many open source licenses include patent-granting clauses, distributing this code may unintentionally grant recipients the right to use the patented invention.

Therefore, it is essential to carefully evaluate the patent clauses of the chosen license and align the publication strategy with the overall IP and commercialization plan. 

Open source hardware (OSHW) licenses are legal frameworks that allow hardware design information—such as schematics, CAD files, or layouts—to be shared so that others can study, modify, manufacture, and distribute products based on those designs. Examples include the CERN Open Hardware Licences (CERN‑OHL) and the Solderpad Hardware Licenses. Unlike typical open source software (OSS) licenses, they extend to physical objects and the full set of design files needed to reproduce them, which can have significant legal consequences.

1. Broad “complete source” disclosure obligation

Certain licenses, such as CERN‑OHL‑Weakly Reciprocal (-W) or ‑Strongly Reciprocal (-S), require the release of the “complete source”, meaning all files necessary to reproduce the hardware, not just the selected design files. In practice, this can include additional design materials (e.g. layouts, build files, or manufacturing data), which researchers may not initially intend to share.

Further, if a design project depends on proprietary third-party software toolkits, libraries, or databases, which are needed to “make” the product, open-sourcing the project outcomes could be problematic.

2. Automatic granting of patent rights

Most OSHW licenses grant recipients the rights necessary to use, make, and sell the hardware based on the provided design files. Publishing a patented design under such a license can unintentionally give recipients the right to commercially exploit that patent and may undermine existing or future rights of exclusive commercialization.

If you intend to publish your work under an OSHW license other than CERN‑OHL‑P (the permissive variant) or the Solderpad Hardware License, Version 0.51, please contact ETH transfer () for a case-by-case assessment.

​As developers increasingly integrate AI coding tools into their workflows, it's essential to consider several legal aspects to mitigate potential risks:​

1. License Compliance: AI coding tools are trained on a vast array of publicly available code, including open-source projects with various licensing terms. There is a possibility that AI's suggestions might resemble code snippets from these sources, potentially leading to license compliance issues. For instance, if Copilot generates code similar to that under a copyleft license, using it without proper attribution or adherence to the original license terms could result in violations.

2. Code Quality and Security: Beyond legal considerations, it's crucial to assess the quality and security of the code generated by Copilot. Studies have indicated that a significant portion of Copilot's suggestions may introduce vulnerabilities, such as cross-site scripting or path traversal flaws. Therefore, developers should thoroughly review and test AI-generated code to ensure it meets security standards and does not inadvertently introduce risks into the software. ​For more information on security and privacy issues, please see this external page blog.

Best practices for developers using AI coding tools:

• Enable duplication detection: When applicable, configure the AI coding tool to detect and suppress suggestions that closely match existing public code to minimize license compliance risks. 
• Scan generative AI code output: Conduct license scanning on generative AI output. Tools like external page FOSSA help detect copyleft-licensed files and reveal the associated compliance obligations.
• Conduct thorough reviews: Always review and test AI-generated code for quality and security before integrating it into your projects.​

Copyright and patents are two different methods of protecting software, each focusing on different aspects of intellectual property rights.

Copyright In Switzerland, external page copyright law protect works that are literary and artistic intellectual creations with individual character, irrespective of their value or purpose. This includes, for example, literary and musical works, paintings, sculptures, films, operas, ballets and pantomimes works.

Computer programs (software) are explicitly considered works under copyright law. However, copyright does not protect the underlying ideas, algorithms, or functionality of the software—only the specific way these elements are expressed in code. 

A work is protected by copyright law as soon as it is created. In case of software, this means that as soon as the software code is written, it is copyrighted (as long as the other copyrightability requirements are fulfilled). 

For detailed information of the copyright law and ownership of software at ETH, please refer to Software and Copyright.

Patents, on the other hand, protect the underlying inventions that make the software function as a technical solution to a practical problem. A computer-implemented patent can protect new and inventive algorithms, methods, or technical solutions implemented by the software. With a patent, the inventor can prevent others from using, selling, or making the patented invention without permission.

If you are interested in applying for a patent for your invention implemented as a software, please proceed to Patenting Software.

The creator or author of software is the person who has materially written the program code, meaning the developer(s) or coders. If a professor hosts an OSS project but does not directly contribute to the coding (by either writing software code or being substantially involved in code development), he or she is not considered an author or creator under Swiss copyright law.

Under Swiss law, copyright author/creator have moral rights, including the right to be recognized as the author/creator of software, the right to first publication, and the right to the integrity of the work.

Importantly, if the software was created as part of an employee’s official duties at ETH Zurich, ETH Zurich holds the exclusive rights of use of the software (Federal Act on the Federal Institutes of Technology, external page Article 36, para. 2). This means that ETH Zurich can exclusively determine who and under what conditions can access, use, distribute, and redistribute (including license and sueblicense) the software. In this sense, ETH Zurich can be regarded as the "owner" or "holder" of the software copyright.

• If you wish to license your code as proprietary software to a third party, it must be approved by the responsible Research Group Leader and submitted to ETH transfer for review. ETH transfer will then draft a license agreement for the software, which must be approved and signed by the ETH Vice President for Knowledge Transfer and Corporate Relations, as well as the Research Group Leader. A detailed guidance can be found at licensing software.
• If you wish to release your code under an open-source license, the decision must be approved by the responsible Research Group Leader (normally the professor in charge of the funding for this work), even if he or she is not an author/creator of the code, and follow the OSS release conditions outlined above. 

As the OSS ecosystem operates with dynamics and mindset that differ significantly from conventional proprietary software, it is important to be fully informed about the legal, commercial, and reputational risks associated with OSS release and license management.