Skip to content

Naming Open Source in Institutional IP and Open Policies §

Pattern Summary §

Work with the owners of institutional intellectual property (IP), open access, open science and/or open data policies to explicitly name or add guidance on open source software.

Problem / Challenge §

  • Many IP and open policies predate institutions’ capacity and expertise in open source, either ignoring software or treating it as IP to commercialize.
  • Without explicit policy language, researchers don't know whether or how they can release code as open source and staff in Technology Transfer Offices (TTOs) or other areas have no formal basis for supporting it.
  • Related policies are often owned by different units (e.g. Library, TTO, Office of Research, Data Institutes) and may contradict each other.

Context §

A university or research institution with an existing IP policy and an open access, open science and/or open data policy.

An OSPO, or a staff member with open source expertise (often based in a TTO, library or research office), who has an opportunity to influence policy.

Forces §

  • Institutional policies are reviewed infrequently and on different cycles.
  • Opportunities to influence policy often come through a scheduled policy review or a request to join a policy review group.
  • Policy changes must pass through formal approval processes. Draft language usually cannot be shared or promoted until it has been approved.
  • Ownership of related policies is split across units with different priorities. Open access, open science and open data communities may view open source differently from TTO staff.
  • TTO performance is typically measured by traditional commercialization metrics (patents, licenses, spin-outs) that rarely count open source releases. As a result, in some systems, TTO staff may see open source as a lost commercial opportunity rather than a valid route for knowledge transfer, and be less inclined to name it in the IP policy.
  • Industry-funded and collaborative projects carry contractual terms that may restrict or shape open source release - regardless of institutional policy.
  • Some institutions are reluctant to publish their policies, making it difficult for peers to find reusable language.

Solution §

The solution below outlines some core activities to consider.

Map relevant policies and their owners §

Identify every institutional policy that touches on software and its release. This is likely to include IP, software, student IP, consultancy, open access, open data, open science and conflict of interest policies.

For each policy, note who owns it, when it was last updated and when it is next due for review.

Review opportunities §

Policy reviews may only come around every few years.

Ensure the OSPO or open source lead knows when they are happening.

Ask to join review groups or ask colleagues on those groups to represent open source interests.

A review of one policy is often a good moment to propose changes to a related policy, so that both can be updated in parallel.

For more on helping researchers and TTO colleagues understand where open source fits alongside other software pathways, see the related pattern Integrating OSS into Institutional Software Pathways.

Start small and build over time §

A short statement that names open source as a recognised route for disseminating research outputs is far better than no mention at all.

Once a foothold exists, it can be expanded in later revisions as the institution's open source capacity and experience grow.

Draft language that addresses the essentials §

When drafting or redrafting open source provisions, the following provisions may be worth considering:

  • A recognition that releasing software under an open source license is a legitimate route for dissemination and knowledge transfer.
  • Who owns software created at the institution and how that interacts with open source release.
  • Who may decide to release software as open source and any notification or approval steps (for example, notifying the OSPO or TTO).
  • Guidance on license choice, such as preferring licenses approved by the Open Source Initiative.
  • Obligations arising from funder requirements, third-party code and collaborative or industry-funded contracts.
  • How provisions apply to staff, students and visiting researchers.
  • Who is responsible for ensuring compliance with the open source provisions.
  • Where to go for advice and support.

Decide how much crossover there should be between policies. One approach is to make a single policy the "home" for open source provisions and cross-reference it.

Where open source is addressed in more than one policy, those policies should be consistent with one another.

Whoever leads on one policy should review drafts of the others to avoid contradictions. For example, IP expertise from the TTO can help ensure an open access policy does not conflict with the IP policy.

Gather and share examples §

Collect example language from peer institutions before drafting. Useful starting points includes the Research Software Alliance's (ReSA) collection of institutional research software policies.

Allow time for approval, and document the journey §

Policy changes typically need to pass through committees and formal approval processes. Plan for this and avoid publicising draft language too early.

Keep a record of each version of the policy language and the reasons for changes. This helps the institution track progress and demonstrates how the policy evolved.

Resulting Context §

The intended outcome is that open source is explicitly named and supported in at least one of the institution's IP, open access, open science or open data policies.

Researchers have a clear basis for releasing software as open source.

OSPO and TTO staff have a formal mandate to advise and support researchers releasing open source.

Additional Learning from Trinity College Dublin §

Our IP policy has evolved over several reviews. Our 2022 policy records its own history: the original documents date from 1986 and we amended or reviewed it in 1991, 2005, 2013/14, 2015, 2018 and 2022. We review it every three years, which gives us regular, predictable opportunities to strengthen the open source provisions.

Our Policy, Practice and Regulations on Intellectual Property (2022) names open source in two places:

  • We define "Open Source" as software licensed under an Open Source Initiative approved license.

  • We included a dedicated Open Source clause (Section 2.2) in the section on disclosing IP. It explains that open source is a licensing model that lets authors share software publicly on Trinity's behalf while we keep the copyright, and that open sourced software can still be dual licensed for commercial purposes.

In that clause, we say that we support authors who want to open source software we own, as long as it doesn't conflict with our obligations to industry partners or State funding agencies. We ask authors to come to us in the TTO for advice and approval through our disclosure process (which includes a Software Disclosure Form), and to talk to us before bringing open source into new projects with commercialisation obligations. We default to a permissive license and we ask that Trinity's copyright is asserted on every license.

As part of the latest review of our IP policy, we redrafted and expanded the open source section. The revised policy is still going through our approval processes.

We're using the open access policy review to align our policies. Our open access policy dates from 2010 and is owned by the Library. We joined the review group to bring an IP perspective and to make sure that the revised policy doesn't conflict with our IP policy, which we're updating in parallel. We're also considering whether to add open source and software to the open access policy and we're working through how much crossover there should be between the two.

Contractual terms matter as much as policy. Even with supportive policy in place, a big part of our work is negotiating contractual terms with companies when open source outputs are expected from commercial or collaborative projects.

Additional Learning from ETH Zürich §

Most university TTOs in Europe acknowledge open source licensing and are actively working with it alongside conventional proprietary licensing. However, some universities may find that administration and policy-making may be slower to adapt to the trend.

At ETH TTO, we implement coherent OSS policies in both the IP regulation and the Business Creation Guideline. Together, they offer a legal basis that acknowledges open source licensing as both a tech transfer pathway alongside the transfer of patents etc. and as a foundation for establishing Spin-offs. (We have shifted to the equity participation model without the need of additional licensing for OSS.)

The TTO is in charge of the IP policy, containing the main OSS provisions while the Library is in charge of open access policies, also touching OSS. The two teams frequently communicate on revising relevant regulations to ensure aligned policy-making and operations. Our OSPO (which is hosted by the TTO) acts as the contact point between the teams.

Open Source Policy Framework at ETH Zurich §

IP and Exploitation Regulations, July 2026 - Drafted and revised by TTO, with open review by the ETH community. - Art.2, para 1k: define open source software by referring to the OSI standard. - Art. 27: authorize employees to release OSS, delegate the decision rights and responsibility to the research group leader, outline the release conditions.

Equity and Licensing Policy, July 2025 - Drafted and revised by TTO, with open review by the ETH community. - Art. 12: categorize software as OSS, ETH software, and mixed software; outline general licensing principles for software; - Art 13: recognize OSS as a foundation for establishing ETH Spin-off.

Guidelines for Research Data Management, July 2022 - Maintained and supported by ETH Library. - Art 6: implement the FAIR principle in publishing research data and code; advocate the use of open source licenses to publish research data and code (para 4); allow exceptions based on commercial use or contractual obligations (para 3).

Open Source Software – ETH transfer | ETH Zurich, January 2026 - Built and maintained by TTO (ETH transfer, the open source working group). - permanent online platform to provide comprehensive guidance and support on policy, best practice, licensing management, case-by-case consulting, CLA, etc.

Known Instances §

References §

Contributors & Acknowledgement §

A note on AI use: In addition to working from Deep Dive transcripts, capturing learning from our community discussions and other patterns from our members, this pattern was drafted with the help of AI. As a small organization, tools like this help us turn rich conversations into written resources without losing the ideas along the way. As always, there were plenty of human eyes reviewing, editing and improving the content before this pattern made it to publication. Thanks go to our community for the insights. If you do spot any errors, please let us know so we can correct them!