Policies and Processes

According to external page Art. 36 of the Swiss Federal Act on the Federal Institutes of Technology (the ETH Act), ETH Zurich holds the intellectual property rights (IP), such as patents created by its employees within the scope of their employment. ETH Zurich also holds the exclusive exploitation rights of computer programs created by its employees within the scope of their employment.

IP created by a student with no employment contract with ETH Zurich, such as a bachelor or master student, originally belongs to the student.

However, if a student participates in a research project involving ETH Zurich employees, such as doctoral students or professors, the project often needs to be further developed or utilized by ETH Zürich after the student leaves. In such cases, it is essential for the student to transfer his/her IP to ETH Zurich to ensure seamless development and use of all research results. In return, the student will receive compensation for any income ETH Zurich generates from his/her contribution, in a way similar to ETH Zurich employees.

To enable IP transfers from non-employee students, we provide IP assignment agreementtemplate, which include an assignment of copyrights associated with OSS (not including moral rights). 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.

The decision of distributing a computer program under an open source license is made by the responsible Research Group Leader (normally the professor), even if he or she is not an author of the computer program.* In case of conflicts of interest**, the decision must be approved by all authors 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. Both the author(s) and 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 authors and the responsible Research Group Leader co-sign a simple one-page acknowledgment form. It serves to confirm the OSS release (including future releases), the chosen 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 authors 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." For example, a professor wants to open source the software produced in a research project that was funded by a company, to which the professor provides consulting service.

Please refer to our webpage OSS License Management for detailed information, particularly the OSS License Risk Chart.

Please refer to our webpage OSS License Management for detailed information, particularly the OSS License Selection Flowchart.

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 professor(s) and the author(s) 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.

It is best practice to mention the authors of software that is released under an OSS license. Moreover, nearly all popular OSS licenses, such as MIT, BSD, Apache 2.0, and GPL, require the inclusion of a copyright notice as a condition of using the license.

To ensure clarity and alignment with standard OSS procedures, OSS developed at ETH Zurich must include a copyright notice with the © or (c) mark. This mark should include the name of the copyright holder (ETH Zurich), the name(s) of the author(s), and the year of first distribution.

Examples of correct copyright notice:

• ©2016-2021 ETH Zurich
• ©2016-2021 ETH Zurich, [Name of author 1], [Name of author 2], etc.
• ©2016-2021 ETH Zurich, [Name of author 1], [Name of author 2], etc.; D-XXXX; [Name of Institute]; [Name of Professorship]

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 authors 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 authors leave the project and become difficult to contact.

To avoid this issue, non-employee authors should assign their software copyright to ETH Zurich using the IP assignment agreement (template). Given that authors 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 author 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. 

Ignoring license compatibility can lead to:

• Legal Violations: Using incompatible licenses may breach intellectual property laws, leading to potential lawsuits.
• Project Restrictions: Some licenses (e.g., GPL) impose obligations that might limit how the software can be used, distributed, or commercialized, or conflict with the project goal.
• Loss of Rights: If proprietary or IP-protected components (such as patented software) are mistakenly included, contributors may lose control over their code’s distribution or infringe the IP rights of third parties, leading to the risks of lawsuits.
• Reputation Damage: Non-compliance can harm trust within the open-source community and lead to project rejection or forking.

Given that OSS authors often build upon each other's work, it is strongly recommended to always review the license information of background code/data BEFORE coding the project, seek legal guidance if needed, and choose licenses that align with the project’s goals and obligations. 

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

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

​Selecting an appropriate OSS license is a pivotal decision that directly affects a project's influences and its potential for commercialization. Aligning the license with the project goals and exploitation strategy ensures clarity of rights, fosters community engagement, and mitigates legal risks. 

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.

Best practices for license selection

• Define clear objectives: Clearly define the project's goals, the target audience, and the commercialization plan.​
• Understand license implications: Familiarize yourself with the permissions and obligations of various OSS licenses, using resources like our OSS License Management.
• Consult legal expertise: Consult with legal experts to navigate complex licensing issues and ensure compliance with relevant laws.
• Consider community norms: Align with the licensing norms of the project's ecosystem to promote collaboration and adoption.​
• Review and adapt: As your project evolves, periodically reassess your licensing choice to ensure it continues to serve your goals effectively.