2.16Lab to company: IP, tech transfer and spinouts

Open source or proprietary: research code and models

Stage: Minus-oneDeeptech

1. Core idea and who it's for#

Research software is a different kind of asset from a patented molecule. It is protected mainly by copyright, which is cheap and automatic, but only covers the code as written, not the idea. It is often already public on GitHub, has many contributors, and is mixed with third-party libraries. For many deeptech companies, open-sourcing part of the stack is a better strategy than keeping it all closed. It brings adoption, recruiting, credibility and a pool of users who may become customers. The question is never just "open or closed?" It is which layer is open, under which licence, and where the company's defensible value sits.

There are three common patterns:

  1. Open core. The core library or model is open, under a permissive or copyleft licence. The company sells hosted services, enterprise features, support or certified builds. Examples include Databricks and Spark, and several Berkeley open-source spinouts.
  2. Open research, closed product. Publish the algorithms and reference code. Build the commercial system, with its data pipelines, scale engineering, validation and integrations, as proprietary code.
  3. Fully proprietary. Keep everything closed and rely on trade secrets, copyright and, rarely, software patents. This suits cases where the code is the product and nobody needs to inspect it, such as embedded control software or a scientific instrument's firmware.

For models, add a fourth question: are the weights open, the training code open, the data open, or some mix of the three?

Who this is for: founders whose technology is mostly software, ML models or code-heavy research tools: computational biology, scientific ML, simulation, robotics stacks, quantum software. It is also for hardware founders deciding what to do with the control and analysis software. Data rights are covered in 2.17.

2. Evidence: who owns the code, what licences do, and what the market has learned#

Who owns research code depends on the university's policy, so check it first.

  • Many universities claim copyright in software made by staff with university resources. Some, like Iowa State, generally give ownership of non-patentable software to the author, unless a sponsor agreement or other agreement says otherwise (Iowa State policy).
  • Oxford requires approvals before an open-source release, including the head of department's, and helps researchers choose between open-source and commercial licensing (Oxford University Innovation).
  • Indiana stresses that all co-authors must agree to an open-source release, and that third-party code and sponsor obligations must be checked first (Indiana ICO).

What licences do. Permissive licences such as MIT, BSD and Apache 2.0 let anyone build closed products on top of your code. Copyleft licences such as GPL require derivative works to stay under the GPL when distributed. AGPL goes further: it counts offering the software as a network service as distribution, which closes the "SaaS loophole" (CASRAI). For a startup, copyleft plus a commercial licence is the classic dual-licensing model. It only works if the company owns, or has licensed, the copyright in all the code, including contributors' code. That means you need contributor licence agreements (CLAs) from the start.

Universities support open-source spinouts. UC Berkeley's Open Source Software Startup (OS3) programme offers new companies an optional, cash-free "good-standing" agreement. It confirms in writing that the university released the software under an opensource licence, and it gives the university a small equity interest (Berkeley IPIRA). Its examples include Spark, RISC-V and Open vSwitch.

The market's lesson: choose your licence early, because changing it later is costly.

  • HashiCorp moved Terraform from MPL to the Business Source License in 2023, and the community forked it as OpenTofu.
  • Redis moved from BSD to SSPL and RSAL in March 2024. AWS and Google backed the Valkey fork, and in May 2025 Redis added AGPLv3 back as an option (WZ-IT chronicle; The Register).
  • Elastic added AGPL in 2024.
  • The Open Source Initiative does not recognise SSPL or BSL as open source.

The pattern is clear: a company that starts permissive and closes later loses trust and gets forked. AGPL from day one, plus a commercial licence, is now a common choice for infrastructure startups that want protection against cloud providers.

Models are different. Weights are a newer kind of asset, and their copyright status is unsettled. Licences range from permissive ones (Apache 2.0, MIT) to responsible-AI licences with use restrictions (OpenRAIL), to custom vendor licences with acceptable-

use policies and limits for very large users. Investors will ask what stops a competitor from fine-tuning your released weights. The usual answer is the data, the evaluation pipeline and the deployment stack, not the weights themselves.

3. Method: decide what's open, pick the licence, secure the chain of title#

Step 1. Map the stack in layers. Write down each layer and ask where customers actually pay:

  • the algorithms and papers;
  • the reference implementation;
  • the core library or engine;
  • the trained models or weights;
  • the data and training pipeline;
  • integrations and connectors;
  • the hosted service or user interface;
  • validation and compliance artefacts.

Typical answers are a hosted service, enterprise integrations, validated outputs, support, and performance at scale.

Step 2. Open the layers that drive adoption, and close the layers that capture value. A rule of thumb is to open whatever makes more people need the closed part. Ask of each layer: if a competitor took this, could they take our customers? If not, opening it costs you little and buys adoption. Keep proprietary:

  • the data and pipelines that produce your model's performance;
  • validation and regulatory evidence;
  • the parts that customers in regulated industries need certified.

Step 3. Choose the licence for each open layer.

  • Apache 2.0 for libraries you want industry to adopt. It includes an explicit patent licence and is friendly to companies.
  • MIT for small tools and research reference code.
  • AGPLv3 plus a commercial licence for an engine or server you will also sell as a service. It stops cloud providers hosting it without contributing, and companies that can't accept AGPL buy the commercial licence.
  • Source-available licences (BSL, ELv2, FSL) only if you accept that they are not open source and some contributors will stay away.

For weights, use permissive licences, OpenRAIL-style use restrictions, or a custom licence with a commercial-use threshold. Write down why you chose it.

Step 4. Secure the chain of title before you release anything.

  • Get the university to assign or license the existing code to the company. The code is often in the same licence as the patents, or a separate copyright licence (2.07).
  • List every contributor, including students, postdocs and outside collaborators, and get assignments or licences from them.
  • Run a scan of dependencies and licences. A single GPL dependency in a product you want to keep closed is a problem.
  • From the company's first commit, require a contributor licence agreement or a Developer Certificate of Origin (DCO). Use a CLA if you plan to dual-license.

Step 5. Don't let open source destroy patentability. If any part is patentable, such as a novel method in hardware control or a new compression technique, file before you publish the code (2.04, 2.05). Releasing the code counts as disclosure.

Step 6. Explain it to investors in one slide. List what's open and why, what's closed and why, how the open layer drives revenue for the closed layer, and what stops a fork from competing. The usual answers are speed, data, brand and the hosted product.

Worked example (illustrative)#

A computational chemistry spinout has three assets:

  • a Python library for running molecular simulations, written over five years by eight lab members;
  • a machine-learned force field trained on a proprietary dataset of quantum calculations;
  • a cloud platform that runs simulations for pharma customers.

The decisions:

Layer Decision Why
Simulation library Open, Apache 2.0 It is already cited in papers,
adoption drives demand for the
platform, and pharma needs to
inspect it
Force-field weights (small
model)		 Open weights,
research-only licence		 Builds credibility and
benchmarks, and acts as a lead
magnet
Layer Decision Why
Force-field weights Closed This is the performance
(production model) and advantage, and the data is the
training data moat
Cloud platform Proprietary SaaS This is where revenue comes
from

Before the release:

  • The university assigns its copyright in the library to the company under the licence (2.07).
  • Six of the eight contributors sign confirmatory assignments. The other two wrote only small parts, which are rewritten.
  • A dependency scan finds one GPL plotting module, which is replaced.

Investors see an open library with 3,000 GitHub stars that brings pharma users into a paid platform. The moat is the data, not the code.

4. India / US / UK differences#

India#

  • Copyright ownership. Under the Copyright Act 1957, the employer usually owns works made in the course of employment. Institute policies, for example at IITs and CSIR, usually claim software made with institute resources. Students' ownership depends on the institute's IP policy. Get a written assignment or licence covering the code before you incorporate.
  • Software patents are narrow. Section 3(k) of the Patents Act excludes computer programs "per se", so patents on computer-related inventions need a technical effect. Check the Patent Office's current examination guidelines for computer-related inventions. In practice, copyright, trade secrets and open-source strategy matter more for Indian software startups.
  • Government-funded code. Some government schemes now encourage or require open-source release of publicly funded software. Check the grant terms.

US#

  • Copyright in employees' code belongs to the employer as work made for hire. Universities vary, and some give non-patentable software to its authors, such as Iowa State. Berkeley's OS3 programme is a model for confirming university support for an

open-source spinout.

  • Software patents are possible but limited by the Supreme Court's Alice decision. File method claims tied to hardware, or to specific technical improvements, before you release the code.
  • Federal funding: NSF and NIH often encourage open release of research software. Check the award terms before you plan a closed product built on grant-funded code.

UK#

  • Copyright in code made by employees belongs to the employer under the Copyright, Designs and Patents Act. University policies vary on students. Oxford's process, for example, requires departmental approval for open-source release.
  • Patents exclude programs "as such". Claims need a technical contribution, and UK case law on AI and software patentability is still developing, so take advice before relying on it.
  • EU rules for UK companies selling in the EU. The EU AI Act's obligations for generalpurpose models include partial exemptions for open-weight models released under free and open-source licences, with exceptions. The Cyber Resilience Act will place security obligations on commercial products that include open-source components. Check both if you sell into the EU.

Scripts#

Asking the TTO about code:

"The lab's simulation library is already on GitHub under a research licence. We'd like the company to receive an assignment of the university's copyright, or an exclusive commercial licence, and then release the core under Apache 2.0. Can the copyright be included in the patent licence, or does it need a separate agreement?"

Getting contributors' sign-off:

"You contributed to the library during your PhD. The company is taking it forward as an open-source project. Could you sign this short confirmation that assigns any rights you have to the company? It doesn't stop you using the code yourself, because it will stay open."

Explaining it to an investor:

"The library is open because adoption is our distribution channel: 40 labs use it, and four of them became paying platform customers. The production model and the data behind it are closed, and that is where the performance gap is. A fork gets the library, but not the model, the data or the platform."

Common mistakes#

  1. Releasing first and asking the TTO later. The university owns the code, and the release breaches its policy or a sponsor's terms.
  2. Missing contributor rights. Former students' code can't be relicensed, which blocks dual licensing or a sale.
  3. Starting permissive and closing later. You lose community trust and get forked, as with Terraform, Redis and Elasticsearch. Choose AGPL plus a commercial licence on day one if you need protection from cloud providers.
  4. GPL contamination. A copyleft dependency ends up inside a product you meant to keep closed.
  5. Losing patents through publication. Code released before a patent filing counts as prior art.
  6. Open weights with no moat. Releasing your best model when it is your product.
  • 2.01 Who owns your invention
  • 2.04 Patent or publish first
  • 2.07 Licence terms
  • 2.17 Rights to research data and datasets
  • 2.18 Trade secrets vs patents
  • 14.10 The seed data room

Sources#

The worked example is illustrative. This playbook is not legal advice: licence and copyright questions depend on your institution's policy and your jurisdiction. Last checked November 2026.

← 2.15 Licensing from government labs (CSIR, DRDO, ISRO; US CRADAs)2.17 Rights to research data and datasets →