Software License Agreement: A Worked, Filled-In Example

Searches for an “example software license agreement” or “sample software license agreement” usually want the same thing: not another explanation of what a software license agreement is, but a look at what the finished clauses actually say once they are drafted out. CASRAI’s Software License Agreement dictionary entry defines the concept and CASRAI’s License Agreement Structure guide and Types of Software License Agreements guide cover the general clause structure and license taxonomy. This guide is different: it works through one illustrative, fully filled-in software license agreement, clause by clause, so you can see what the language looks like once every bracket has been replaced with a real term.

The Illustrative Scenario

In this fictional example, Fictional State University (the “Licensor”) developed a laboratory data-analysis software package in a bioinformatics lab, using university facilities and, in part, federal research funding. Northbridge Analytics, Inc. (the “Licensee”), a data-analytics company, wants a license to incorporate the software into a commercial product sold to industry customers. Because the software embodies no separately patented method in this scenario, the transaction is a copyright license, not a patent license — see CASRAI’s dictionary entry on the Software License Agreement for why that distinction matters and how it differs from patent licensing.

Recitals and Definitions

A sample recitals paragraph:

WHEREAS, Licensor is the owner of all right, title, and interest in and to certain computer software known as [software name], including the source code, object code, and associated documentation thereof (the “Licensed Software”), developed by Licensor’s faculty, staff, and students; and WHEREAS, Licensee desires to obtain, and Licensor is willing to grant, a license to use, modify, and distribute the Licensed Software on the terms set forth below, NOW, THEREFORE, in consideration of the mutual covenants contained herein, the parties agree as follows:

Sample definitions, several of which have no direct equivalent in a patent license:

“Licensed Software” means the computer program known as [software name] in both source code and object code form, including any Licensor-authored modifications, updates, or new versions Licensor elects to provide under Section [maintenance section], but excluding any Third-Party Components.

“Third-Party Components” means any open-source or third-party software components incorporated into or distributed with the Licensed Software, as listed in Exhibit A, each of which remains subject to its own applicable license terms.

“Derivative Works” has the meaning given in 17 U.S.C. § 101, and includes any modification, translation, or adaptation of the Licensed Software that Licensee creates.

“Net Revenue” means gross revenue actually received by Licensee from sale or licensing of products incorporating the Licensed Software, less returns, credits, and standard deductions for freight, insurance, and sales taxes actually paid.

Grant of Rights

The operative clause defines what the licensee may actually do with the code — use, modify, and/or distribute are independent grants, unlike a patent license’s single “practice the invention” grant:

Subject to the terms of this Agreement, Licensor hereby grants to Licensee a non-exclusive, worldwide license under Licensor’s copyright in the Licensed Software to (a) use and reproduce the Licensed Software, (b) prepare Derivative Works based on the Licensed Software, and (c) distribute the Licensed Software and Derivative Works, in each case solely as incorporated into Licensee’s commercial products. Licensor retains all rights not expressly granted, including the right to continue using, modifying, and licensing the Licensed Software for its own research, teaching, and non-commercial academic purposes, and to license the Licensed Software to other parties.

Note this example grants a non-exclusive license, the more common structure for research-originated software with broad potential adoption; an exclusive grant is possible but, per CASRAI’s Types of Software License Agreements guide, is less typical for platform or infrastructure code than for a single-product invention.

Source Code Delivery and Escrow

This clause has no patent-license analogue — a patent conveys a legal right, not a physical artifact, while software has to actually be delivered:

Licensor shall deliver the Licensed Software to Licensee in both source code and object code form within fifteen (15) days of the Effective Date, together with then-existing technical documentation. Licensor shall have no obligation to place the Licensed Software in third-party escrow.

Some agreements instead specify escrow, particularly where the licensee is dependent on the licensor’s continued maintenance:

[Alternative escrow clause] Licensor shall deposit the then-current source code of the Licensed Software with [named escrow agent] within thirty (30) days of each material update. The escrow agent shall release the deposited source code to Licensee only upon (a) Licensor’s failure to cure a material breach of its maintenance obligations within ninety (90) days of written notice, or (b) Licensor ceasing operations without a successor assuming its obligations.

Third-Party and Open-Source Component Disclosure

Because research software is frequently built using open-source libraries, a software license agreement typically requires disclosure of what those components are and confirmation that incorporating them does not impose obligations Licensee has not agreed to:

Licensor represents that Exhibit A lists all Third-Party Components incorporated into the Licensed Software as of the Effective Date, together with the applicable license for each. Licensor represents that, to its knowledge, none of the Third-Party Components is licensed under terms (such as a network-copyleft license) that would require Licensee to disclose or license the source code of its own proprietary software as a condition of distributing products incorporating the Licensed Software.

This representation matters because a component under a strong copyleft license (for example, the GNU Affero General Public License) can impose obligations on downstream distribution that a permissive license (MIT, Apache 2.0, BSD) does not — see CASRAI’s Open Source Software Licensing in University Technology Transfer guide for how license compatibility is evaluated.

Consideration and Payment Structure

The figures below are illustrative only, chosen to show what a filled-in payment schedule looks like, not typical or recommended values. CASRAI’s royalty rate setting methodology guide discusses how real rates are set.

• License fee: $15,000, due within thirty (30) days of the Effective Date.
• Running royalty: 4% of Net Revenue, paid quarterly.
• Minimum annual royalty: $5,000 per year, beginning in year two, creditable against running royalties owed for that year.
• Maintenance fee: $3,000 per year, covering the support obligations described below, payable annually in advance.

Maintenance, Support, and Derivative Works

Software requires ongoing upkeep in a way an issued patent does not, so a software license agreement typically addresses it directly — and clarifies who owns improvements the licensee itself makes:

During the Term and conditioned on Licensee’s payment of the annual maintenance fee, Licensor shall use commercially reasonable efforts to provide bug fixes for material defects reported by Licensee, but has no obligation to develop new features or support platforms not in use as of the Effective Date. As between the parties, Licensor owns all right, title, and interest in the Licensed Software, including any Derivative Works prepared by Licensor. Licensee owns any Derivative Works it independently prepares, subject to Licensor’s underlying copyright in the Licensed Software incorporated therein, and grants Licensor a non-exclusive, royalty-free license to use any Derivative Works Licensee elects to share with Licensor for Licensor’s internal research and teaching purposes.

Warranty Disclaimer and Limitation of Liability

University licensors are typically conservative here, consistent with the general pattern described in CASRAI’s License Agreement Structure guide:

THE LICENSED SOFTWARE IS PROVIDED “AS IS,” WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. LICENSOR DOES NOT WARRANT THAT THE LICENSED SOFTWARE IS ERROR-FREE. IN NO EVENT SHALL LICENSOR’S TOTAL LIABILITY UNDER THIS AGREEMENT EXCEED THE TOTAL FEES PAID BY LICENSEE IN THE TWELVE (12) MONTHS PRECEDING THE CLAIM, AND IN NO EVENT SHALL LICENSOR BE LIABLE FOR ANY INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES.

The broad disclaimer of implied warranties reflects, in part, that copyright protects only the university’s expression of the code (17 U.S.C. § 102(b)) — the university is not warranting the underlying idea or method works for Licensee’s purposes, only conveying rights in the code as written.

Government Rights (Federally Funded Software)

Because the illustrative software in this example was developed in part with federal funding, the agreement reflects the government’s reserved rights:

Licensee acknowledges that the Licensed Software was developed in part with federal funding, and that the license granted herein is subject to the reserved right of the United States Government to reproduce, use, and authorize others to use the Licensed Software for government purposes, as set forth in 2 CFR § 200.315.

Term and Termination

This Agreement shall remain in effect for five (5) years from the Effective Date, renewing automatically for successive one-year terms unless either party provides ninety (90) days’ written notice of non-renewal. Either party may terminate this Agreement upon a material breach by the other party that remains uncured sixty (60) days after written notice. Upon termination, Licensee shall cease distributing new copies of products incorporating the Licensed Software, but may continue to support copies already distributed to its own customers as of the termination date.

Boilerplate

As with any license agreement, standard boilerplate — governing law, assignment restrictions, notice procedures, and an integration clause — rounds out the contract. These provisions are not software-specific, so they are not drafted out in full here; CASRAI’s License Agreement Structure guide covers what each of these typically contains.

Frequently Asked Questions

How is a software license agreement example different from a patent license agreement example?

A software license example includes clauses with no patent-licensing equivalent — source code delivery or escrow, open-source component disclosure, and derivative-works ownership — because copyright protects the specific code as written (17 U.S.C. § 102(b)), not the underlying method the way a patent does. See CASRAI’s License Agreement Template worked example for a comparable filled-in patent license.

Can I use this example as an actual contract?

No. This page is an illustrative, fictional composite meant to show what finished clause language looks like. It is not a binding agreement, is not legal advice, and should not be copied into a real contract without review by qualified institutional counsel.

Does a university software license need to disclose open-source components?

Most do, because incorporating an open-source component under a strong copyleft license can create obligations for the licensee’s own downstream code. Disclosing the components and their licenses lets the licensee’s counsel evaluate that risk before signing, rather than discovering it after the software is already integrated into a commercial product.

Who owns improvements the licensee makes to the licensed software?

This is negotiated, and the answer varies by agreement. A common structure, illustrated above, has the licensee own its own independently developed Derivative Works while the university retains its underlying copyright in the original code those works incorporate, sometimes coupled with a license-back so the university can use licensee improvements for research and teaching.

Is a non-exclusive or exclusive license more common for software?

It depends on the software. Broadly useful research infrastructure or platform code is more often licensed non-exclusively to multiple parties, since exclusivity would foreclose other potential adopters without a corresponding development commitment. A single company building one commercial product around the code is more likely to negotiate for exclusivity, at least within its field of use. CASRAI’s Types of Software License Agreements guide covers this choice in more depth.

For the general clause-by-clause structure this example follows, see CASRAI’s License Agreement Structure guide. Related reading: CASRAI’s Software License Agreement dictionary entry, Types of Software License Agreements, Open Source Software Licensing in University Technology Transfer, License Agreement Template worked example, and the Tech Transfer pillar page.