Software License Agreement

A software license agreement, in a university technology-transfer context, is the contract a technology transfer office (TTO) uses to grant a company or other outside party rights to use, modify, and/or distribute software the university itself developed — the reverse of the university acting as a customer that licenses in someone else’s commercial software (a Microsoft, SPSS, or MATLAB site license, for example). What makes an agreement an instance of this term is the direction of the grant: the university is the licensor, holding the underlying copyright (and, occasionally, an associated patent) in code its faculty, staff, or students created, and it is conveying specific, negotiated rights to a licensee in exchange for consideration — typically royalties, fees, equity, or some combination.

Why this is a copyright transaction first, not a patent transaction

Software is protected in the United States primarily through copyright, not patent. Computer programs were added as a defined term to copyright law by the Computer Software Copyright Act of 1980 (implementing recommendations of the National Commission on New Technological Uses of Copyrighted Works, CONTU) and are protected as “literary works” under 17 U.S.C. § 101. Copyright protection attaches automatically the moment original code is fixed in a tangible medium — no filing is required to create the right, though registration with the U.S. Copyright Office is a prerequisite to filing an infringement suit and to seeking statutory damages and attorney’s fees.

This produces a real, practical difference from the university’s other major IP-licensing transaction, covered separately in CASRAI’s patent licensing guide: a patent, once granted, gives the university the right to exclude others from making, using, or selling the claimed invention itself — the underlying method or system — regardless of whether a competitor independently arrived at the same solution. Copyright, by contrast, protects only the university’s particular expression of an idea — the actual source code as written — and explicitly does not extend to “any idea, procedure, process, system, method of operation, concept, principle, or discovery,” per 17 U.S.C. § 102(b). A competitor who independently writes different code that performs the same function has not infringed the university’s copyright, even if it infringed a patent covering the same underlying method. This is why a software license agreement’s “exclusivity” is narrower in a meaningful legal sense than a patent license’s exclusivity: it controls a specific codebase, not the underlying idea, unless the university has also separately patented a method embodied in that code (see CASRAI’s Software Patent entry for when and how that applies, including the Alice/Mayo eligibility framework that makes software patents harder to obtain than most other utility patents).

Key terms typically negotiated

• Exclusive vs. non-exclusive. An exclusive license grants only the named licensee the right to exploit the software in the licensed field/territory — the university cannot license the same rights to anyone else, and often cannot exercise them itself, though TTOs routinely carve out a “reserved rights” clause preserving the university’s own right to continue using the software for research, education, and non-commercial academic collaboration even under an otherwise-exclusive grant. A non-exclusive license lets the university license the same code to multiple parties simultaneously — the more common structure for research infrastructure software with broad potential adoption, since it doesn’t foreclose parallel deals or continued open availability.
• Field-of-use and territory restrictions. Rather than granting unrestricted rights, a license is frequently limited to a specific application domain (e.g., “diagnostic imaging” but not “industrial quality control,” for two different fields the same underlying software might serve) and/or a specific geography. This lets a TTO license the same codebase to different companies in different fields without conflict, and is a structuring tool copyright licensing shares with patent licensing.
• Royalty and payment structure. Commonly some mix of an upfront license fee, running royalties calculated as a percentage of net sales or net revenue attributable to products incorporating the software, minimum annual royalties (to keep an exclusive licensee actively commercializing rather than sitting on the rights), and — especially for an early-stage spin-out that cannot pay meaningful cash royalties — an equity stake in lieu of some or all royalty payments.
• Source code delivery and escrow. Unlike a patent license (which conveys a legal right, not a physical artifact), a software license agreement has to specify whether the licensee receives compiled object code only, full source code, or source code held in a third-party escrow account released only on specified trigger events (e.g., the university ceasing to maintain the software) — a term with no patent-licensing analogue.
• Maintenance, support, and improvement obligations. Because software requires ongoing maintenance in a way an issued patent does not, agreements typically specify whether the university (or the original lab) has any continuing obligation to fix bugs, provide updates, or support new platforms, for how long, and at whose cost — and who owns derivative works or improvements the licensee makes, since copyright law treats derivative works as a distinct right under 17 U.S.C. § 106.
• Sublicensing rights, audit rights, and termination. Whether the licensee may sublicense the software to its own customers or partners, the university’s right to audit royalty reports and usage, and the conditions (non-payment, failure to commercialize, breach) under which the license terminates and rights revert to the university.
• Government and funder rights flow-down. If the software was developed with federal funding, the agreement needs to reflect the government’s reserved rights under 2 CFR § 200.315 (a royalty-free, non-exclusive government-use license) — a copyright-side obligation distinct from Bayh-Dole’s patent-side “subject invention” machinery, which generally does not govern software directly unless a separately patented invention is embodied in it.

How this differs from CASRAI’s Open Source Software Licensing guide

CASRAI’s Open Source Software Licensing in University Technology Transfer guide covers a specific and different question: which pre-existing, standardized open-source license (MIT, Apache 2.0, GPL/AGPL, LGPL, and so on) should govern software the university is releasing publicly, and how dual licensing lets a university offer the same code under both a copyleft public license and a separately negotiated commercial license. A software license agreement, as defined here, is the broader, general category of transaction: the negotiated, typically bilateral, often non-public contract a TTO drafts when licensing university software to a specific commercial party under custom terms — proprietary or otherwise. Open-source licensing is one disposition path within that broader category (and one where most of the “negotiated” terms above are pre-fixed by the license text rather than bargained over); a bespoke commercial license to a single licensee, with the negotiated exclusivity, field-of-use, royalty, and maintenance terms above, is the more typical instance of this term.

Examples

• A university TTO grants a mid-size medical-device company a non-exclusive, field-of-use-limited license (restricted to diagnostic imaging applications) to an image-processing software package developed in a radiology lab, in exchange for a modest upfront fee, a running royalty on net product revenue, and a three-year maintenance commitment funding a part-time developer for bug fixes.
• A university licenses a statistical-genetics software platform exclusively to a single university spin-out in the field of clinical diagnostics, while reserving the university’s own right (and the right of other non-profit academic institutions) to continue using the software freely for research and teaching — a common “reserved rights” carve-out even in an otherwise-exclusive commercial license.

Counter-example

A university library or research computing center purchasing a site license for a commercial statistics package (SPSS, MATLAB) so campus researchers can run it is not an instance of this term — there, the university is the licensee, receiving rights to someone else’s commercial software, which is the reverse transaction from what a TTO negotiates when licensing university-developed software out to industry.

This entry describes general licensing principles and cites the underlying federal statutes and regulations directly; it is not legal advice. Specific license terms should be drafted and reviewed by institutional counsel, and by patent counsel where a patentable invention is also embodied in the licensed software.