When a university technology transfer office (TTO) licenses software it owns out to industry, two largely independent questions have to be answered before a term sheet can even be drafted: who else, if anyone, can also get rights to this code (the exclusivity axis), and how will the licensee actually access and use it (the deployment/scope model). Most real agreements combine an answer from each axis — for example, a non-exclusive site license, or an exclusive SaaS arrangement with a single spin-out. This guide is a taxonomy of the recurring types along both axes, written specifically for the outbound-licensing case: a university as licensor of its own software, not as a purchaser of commercial software for campus use.
It complements two existing CASRAI resources rather than repeating them. The Software License Agreement dictionary entry covers the negotiated terms inside a single bilateral commercial license — royalty structure, source code escrow, maintenance obligations, sublicensing, government-rights flow-down — in depth; read it for how a license is built once you know which type you’re negotiating. The Open Source Software Licensing guide covers a different decision entirely: which pre-standardized public license (MIT, Apache 2.0, GPL/AGPL) to release code under, and how dual licensing lets a university pair a copyleft public release with a separate commercial license. This guide sits between the two: it names and defines the commercial license types a TTO chooses among when structuring a bespoke, negotiated license to a specific commercial party.
The exclusivity axis: exclusive, non-exclusive, and sole licenses
This axis answers who else can exploit the software. It is the same basic three-way structure technology transfer offices use across both patent and copyright licensing, not a software-specific invention.
- Exclusive license. Only the named licensee may exploit the software in the licensed field and territory; the university generally cannot license the same rights to a second party, and often cannot exercise them itself outside a negotiated “reserved rights” carve-out for continued academic use. TTOs typically reserve this structure for situations that call for a large, risky, capital-intensive commercialization investment by a single company — the kind of bet a licensee is unlikely to make if a competitor could obtain the same rights.
- Non-exclusive license. The university can license the same code to multiple parties simultaneously. This is the more common structure for broadly useful research software (a statistical package, a lab instrument driver, a data-processing library) where parallel adoption by several companies or institutions doesn’t undermine any single licensee’s business case, and where keeping the software widely available serves the university’s own research and education mission alongside commercialization.
- Sole license. A middle structure: the licensee is the only outside party granted rights, but the university itself retains the right to continue practicing the software (for research, teaching, or its own non-commercial use) alongside the licensee. It is exclusive as to other commercial parties but not exclusive as to the university.
This three-way distinction, and the underlying rationale that exclusivity tracks the size of the commercialization investment a licensee needs to justify, is discussed in the technology-transfer literature — see Van Norman GA, Eisenkot R., “Technology Transfer: From the Research Bench to Commercialization, Part 2,” JACC: Basic to Translational Science 2(2), 2017, which frames the same exclusive/non-exclusive/sole structure across the commercialization process generally. CASRAI’s Patent Licensing guide applies it in detail to the patent side of tech transfer; the mechanics carry over conceptually to software, with the caveat noted above that a copyright license is narrower than a patent license because it protects only a particular expression of code, not the underlying idea or method.
The deployment/scope axis: how the licensee actually accesses the software
Independent of exclusivity, a license also has to define the unit the grant is measured against — a site, an organization, a named number of users, or a hosted service with no distributed copies at all. This is where software licensing diverges most from patent licensing, because a patent license conveys a legal right with no physical delivery mechanism to specify, while a software license has to.
- Site license. Grants use of the software at one or more specified physical locations or facilities (a single company campus, manufacturing plant, or business unit), typically for an unlimited number of users at that site, rather than being tied to a named headcount. Common where a licensee wants to deploy across an entire facility without tracking individual seats.
- Enterprise license. Broader than a site license: covers use across an entire organization, potentially spanning multiple locations, subsidiaries, or business units, usually priced as a flat fee or tiered by company size/revenue rather than per-installation. TTOs negotiating with a large established company (as opposed to an early-stage spin-out) more often see this structure requested, since the licensee wants deployment flexibility across its whole operation without renegotiating for each new site.
- Per-seat / per-user license. Rights are measured by a defined number of named or concurrent individual users, with the license fee or royalty scaling as headcount grows. Common for desktop or installed research-software tools where usage is genuinely tied to individual researchers or employees rather than a facility.
- SaaS / hosted / subscription license. The licensee (or the university’s own spin-out) operates the software as a hosted service that end users access remotely, rather than receiving and installing a copy at all. Because no copy is distributed, the legal grant is often structured more as a services/access agreement than a classic copy-based copyright license, and it introduces terms a site or enterprise license doesn’t need — service-level commitments, data-hosting and security obligations, and uptime — while making source-code escrow and “reserved rights to continue using a delivered copy” clauses largely moot, since there’s no delivered copy for either party to keep using if the relationship ends. It’s also the deployment model most directly implicated by the AGPL’s network-use copyleft trigger, discussed in CASRAI’s open-source guide, when the underlying code being hosted is open-source licensed.
- Evaluation / trial license. A short-term, often royalty-free or nominal-fee grant allowing a prospective licensee to test the software before committing to a full commercial license — frequently non-exclusive by default and limited to internal evaluation use, explicitly excluding any right to incorporate the software into a product or distribute it further.
- OEM / embedded / bundled license. Grants a licensee the right to incorporate the university’s software as a component inside the licensee’s own larger product, which the licensee then distributes to its own end customers — the end customer typically never contracts directly with the university at all. This structure raises its own sublicensing and audit questions (how does the university verify royalties on units of the licensee’s product that merely include the software, rather than being sold as the software), covered in the negotiated-terms detail in the Software License Agreement entry linked above.
Duration: perpetual vs. term/subscription licenses
A third, often overlooked axis is how long the grant lasts. A perpetual license grants rights for the life of the underlying copyright (or until the agreement is otherwise terminated for breach), typically paired with an upfront fee and/or ongoing royalties. A term or subscription license grants rights only for a defined period, renewable on payment of a further fee — the default structure for SaaS/hosted deployment, and increasingly common even for delivered-copy licenses where a TTO wants renegotiation leverage or wants to tie continued rights to the licensee actually maintaining minimum commercialization activity.
How the axes combine in practice
Because exclusivity, deployment model, and duration are independent choices, the same underlying software can be licensed very differently to different parties. A university might grant one company a non-exclusive, perpetual, enterprise-wide license to an internal research tool for a flat fee, while separately granting a spin-out an exclusive, term-limited, SaaS license to build a commercial diagnostic platform on the same underlying codebase, restricted to a specific field of use so the two grants don’t conflict. Field-of-use and territory restrictions (covered in the dictionary entry linked above) are frequently what makes granting more than one type of license on the same code to different parties possible without one agreement undercutting the other.
Government and funder rights still apply regardless of type
Whichever type of license a TTO negotiates, if the software was developed with federal funding the agreement still has to preserve the federal government’s reserved rights under 2 CFR § 200.315 — a royalty-free, non-exclusive right for the government to reproduce, publish, or otherwise use the software for federal purposes, and to authorize others to do so on the government’s behalf. This obligation sits alongside whichever exclusivity/deployment/duration structure the commercial license itself uses; it doesn’t change based on which type is chosen, and it is a copyright-side obligation distinct from Bayh-Dole’s patent-side “subject invention” machinery, which generally does not reach software directly.
Frequently asked questions
Can a university grant both an exclusive license and a non-exclusive license to the same software?
Yes, if the grants are structured so they don’t overlap — most commonly by restricting the exclusive grant to a specific field of use or territory while licensing the software non-exclusively (or exclusively in a different field) to other parties. Without a field-of-use or territory carve-out, an exclusive grant to one party legally forecloses licensing the same rights to anyone else, including the university itself outside any reserved-rights clause.
Is a SaaS arrangement really a “license” in the same legal sense as a site or enterprise license?
Not exactly. Because no copy of the software is delivered to the end user, a SaaS/hosted arrangement is often documented as a hybrid services/access agreement rather than a pure copyright license — but it still needs to grant the underlying right to run and make available the copyrighted code as a hosted service, so TTOs typically address both the access/service terms and the underlying IP grant in the same agreement.
Which type of license should a TTO default to for a new spin-out company?
There’s no universal default — it depends on the commercialization investment the spin-out needs to make. An exclusive license (often field-of-use limited, with the university reserving its own academic-use rights) is common where the spin-out needs to raise capital against defensible exclusivity, since investors are typically reluctant to fund a company that a competitor could license the identical technology out from under. A broadly useful research tool with many potential adopters more often stays non-exclusive.
Does the deployment model (site vs. enterprise vs. SaaS) affect the royalty structure?
Generally yes in practice, though it’s a negotiated term rather than a fixed rule. Site and enterprise licenses are more often priced as flat or tiered fees since usage isn’t metered per-transaction; SaaS/subscription arrangements more often use recurring subscription revenue as the royalty base; per-seat licenses more directly tie royalties to headcount. The dictionary entry on the software license agreement covers royalty-structure options in more depth.
Related CASRAI resources
- Software License Agreement — the negotiated terms inside a single bilateral commercial software license
- Open Source Software Licensing in University Technology Transfer — choosing among MIT, Apache 2.0, GPL/AGPL, and dual-licensing strategy
- Patent Licensing — the exclusive/non-exclusive/sole structure applied to patent rights
