OSS Policies and Best Practices

OSS Release Checklist

Under the Exploitation Guideline (RSETHZ 440.4), ETH Zurich authorizes its researchers to release software created within their employment scope under an open source license approved by the external page Open Source Initiative, provided that the following conditions are met. The OSS release procedures outlined below apply to launching new OSS projects, contributing to existing OSS, and publishing OSS with accompanying journal papers. A flowchart is available below to help navigate these procedures.

The decision of releasing software under an open source license is made by the responsible Research Group Leader (normally the professor), even if he or she is not a creator of the software.* 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. The responsible Research Group Leader must ensure that the OSS release complies with the requirements outlined in the ETH Zurich Exploitation Guidelines (RSETHZ 440.4).

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.

* This reflects the planned revision of the ETH Zurich Exploitation Guideline, while the old Exploitation Guideline (RSETHZ 440.4), currently still in force, requires that the decision of OSS release must always be approved by all software creators and the professor.

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

Software developed at ETH Zurich may be subject to existing license agreements or research agreements entered into by ETH Zurich and third parties. The responsible Research Group Leader must ensure that distributing the software as OSS does not infringe any intellectual property (IP) rights or breach any contractual obligations stipulated in such agreements. Failure to do so may expose ETH Zurich and the software’s creators to claims for IP infringement or breach of contract.

The existence of a third-party license does not, in itself, preclude open-sourcing the software. Whether open-source distribution is permissible depends on the specific nature and terms of the relevant agreement. In particular, the following aspects should be assessed:

Exclusivity: If the license is non-exclusive, meaning the licensor remains free to license the software to others, ETH Zurich is generally not contractually barred from open-sourcing the software.
Confidentiality obligations: Determine whether the agreement imposes confidentiality obligations on the licensor with respect to the source code, which would prohibit public disclosure.
Term and termination: Verify whether the license agreement has expired or been terminated, as proprietary licenses are typically time-limited.
Consent of the licensee: If none of the above resolves the issue, you may seek the explicit consent of the licensee(s) to release the software under an open-source license; in some cases, licensees may also welcome open-sourcing, as it allows them continued access to the latest versions of the software.

Please see below for information on how to identify any existing license or research agreements relating to the software.

If you are a student and unclear about the status of third-parties rights related to the software, please consult your responsible Research Group Leader (typically your professor).
If the software was developed as part of a research collaboration with a third party, or if pre-existing software is to be used in such a collaboration, please first contact your contract manager at the Research Contracts Group for advice;
If the software was developed within an EU project, or if pre-existing software is to be used in an EU project with a third party, please first contact your grant manager at the Grants Office - GO! for guidance.

OSS developed at ETH Zurich often contains source code or data from third parties, either under open source licenses or proprietary licenses. The responsible Research Group Leader and the creator(s) must ensure that all third-party codes/data are used in compliance with their own license terms.

For third-party code under OSS licenses, please refer to "license compatibility" on our webpage OSS License Management.
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 that 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.

Third-party proprietary code from a software vendor. If the proprietary license forbids public disclosure, which is typically the case, including it in an OSS repository would breach that proprietary license and exposes the creators and ETH Zurich to legal risks! In exceptional cases where the creators believe that inclusion may be permissible, they must first contact the vendor, explain the intended use, and obtain explicit written permission before publishing the source code.

For any questions, please feel free to contact us at .

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 Download IP assignment agreement template (DOCX, 29 KB), 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 .

ETH Zurich researchers must use an external page open source license approved by the Open Source Initiative (OSI) for their OSS to be released. The OSI-approved OSS licenses include the well recognized MIT, BSD, Apache 2.0, and GPL licenses. Customized open source licenses are not allowed.

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.

Please also note that if controlled software is embedded in or implemented as firmware or in an FPGA, the associated hardware is automatically classified as a controlled item.

Nearly all OSI-approved licenses, such as MIT, BSD, Apache 2.0, and the GPL licenses, require the inclusion of a copyright notice as a condition of 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 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). When there are multiple copyright holders, e.g., copyright ownership 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, no need to include the persentage share of the copyright. Below are examples of correct copyright notice:

When the copyright holder, e.g., ETH Zurich, is not the individual creator(s) or author(s), who actually coded the OSS, it is strongly recommended to credit the creator(s) in an authorship notice, separated from the copyright notice to avoid misleading. This is commonly handled in the README.md file, for example:

Authors: Jane Doe, John Smith

It is also very common for OSS projects to maintain a AUTHORS or CONTRIBUTORS file. In addition, the Git commit history (canonical record) is often treated as the authoritative record of authorship, even when copyright is centralized.

Also, make sure to include a copy of the OSS license you selected 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.

Where license info and copyright notices are usually placed? In many open-source projects, copyright and license information appears in the following places:

At the top of each source file (as a header comment) — many projects include a short copyright-and-license header in each .java, .py, .c, .js, etc. file.
In a top-level LICENSE file in the project root. This LICENSE file contains the full license text and often a copyright notice / holder information.
If a project includes third-party code or combines multiple licenses, bundling all required attributions in a NOTICE file (or equivalent) helps ensure compliance without cluttering every file. It is also recommended by the Apache Softwere Foundation.
In other distributed documentation or metadata files, e.g. README, documentation files, or header/footer of web-distributed docs when source code is bundled with non-code files.
For some OSS licenses (especially permissive ones, like MIT), including a short license + copyright notice in each file is considered good practice. For more complex licenses (or large projects), sometimes only a central LICENSE + COPYRIGHT NOTICE file is used.

As required by the current Exploitation Guideline (RSETHZ 440.4), you must registrate your OSS with the ETH Data Archive. A detailed instruction is available to guide you through the registration process.

In addition, the external page open source definition (OSD) set by the external page Open Source Initiative (OSI) requires that OSS be distributed through “well-publicized means”, ensuring free and unencumbered access to the source code. Therefore, we strongly recommend that you also publish your OSS on a well-publicized platform, such as GitHub or GitLab. Access to the source code must not require a fee, membership, or invitation.

OSS Release Flowchart

A flowchart for navigating the OSS release procedures outlined above. Click on the figure to view the enlarged flowchart. For a detailed breakdown of each step, please refer to the OSS release checklist above.

Avoid Common Pitfalls - Best Practices

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

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.

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.

As developers increasingly integrate GitHub Copilot into their workflows, it's essential to consider several legal aspects to mitigate potential risks:

1. License Compliance: Copilot is trained on a vast array of publicly available code, including open-source projects with various licensing terms. There is a possibility that Copilot'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.

Configuring Copilot to avoid exact matches can reduce this risk. GitHub has implemented a duplication detection filter to help identify and suppress suggestions that match public code. To turn on the duplication detection filter, go to “Settings” and select “GitHub Copilot” in the left sidebar. Under “Suggestions Matching Public Code,” select “Block,” and then save your updated settings. For more information, please see this external page blog.

2. Intellectual Property (IP) Concerns: The legal community is actively examining whether training AI models like Copilot on public codebases constitutes fair use or infringes upon the rights of original creators. A class-action lawsuit filed in November 2022 challenges the legality of Copilot on several claims, including breach of contract and privacy violations. While some claims have been dismissed, the evolving legal landscape suggests that developers should stay informed about ongoing developments. For more information, please see this external page blog.

3. 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 Copilot:

Enable duplication detection: Configure Copilot 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 Fossology or 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.

OSS Policies and Best Practices

OSS Release Checklist

OSS Release Flowchart

Avoid Common Pitfalls - Best Practices

More Topics Related to OSS