Menu
Members Sign In New to UIDP? Register your email
Register Now
Members Sign In
New to UIDP? Register your email

Publications & Reports

Contract Accord 16: Software

Accord Revision Date: October 2019
Page Updated: January 2020
©2020 University-Industry Demonstration Partnership (UIDP). Please refer to the copyright and disclosure statement for UIDP Contract Accords usage and rights.

See All Contract Accords                   Sign-up for Updates!

OVERVIEW AND BACKGROUND

University-industry projects often involve the use or development of software and associated technology to achieve a variety of project objectives. Whether a researcher is asked to develop software according to design specifications provided by the Company or is created by a researcher as a means of solving a problem, software may be developed, used, or modified to accomplish particular tasks required by a Statement of Work (SOW) contained in sponsored research agreements (SRAs) and other types of sponsored or collaborative agreements, e.g., Materials Transfer Agreements (MTAs).¹

For the purpose of this Contract Accord, all of these types of agreements will be generically referred to as SRAs. Software rights comprise a highly complex field that should be adequately addressed in any SRA in order to prevent misunderstandings and disputes between parties.

This Contract Accord is intended to serve as a software-specific reference guide that can be used to promote successful negotiations between University and Company collaborators within the context of the SRAs involving software.

COMMON PROJECT-RELATED SOFTWARE ISSUES

Understanding the distinct purposes served by software can help parties reach agreement on terms aligned with both specific Company objectives and standard University principles and policies.

Software can be featured in sponsored projects in various ways. The following list provides a few key examples:

  • Company-owned software is used to carry out the SOW.
  • Company software is modified during the course of research.
  • Project deliverable(s) require the University to create original software.
  • University-developed software is required to produce a non-software deliverable.
  • Company and University jointly develop/author software.
  • Third-party software is used or modified to create a software deliverable.
  • Open-source software is used, modified, or otherwise incorporated into the project.
  • Government funding or resources are used in a sponsored project involving software.

In some cases, Companies may license proprietary software to Universities for the purpose of carrying out a project. In other cases, original or derivative software may be created during the course of a project. In several countries, including the United States, original software is frequently protected under copyright law.²

As with other types of intellectual property (IP), Universities typically own the copyright to software generated by University employees. If Universities and Companies have each contributed to the creation of software, the parties will jointly own the software. Ownership and licensing issues become more complex if third-party intellectual property or open-source software has been incorporated into a software program in any of the above examples. Other licensing issues arise when a government agency has contributed funding or other essential resources to a sponsored research project involving software development. Each of these issues will be discussed in more detail below.

DEFINITIONS

The following terms may be used in an SOW, SRA, or software license and are provided to help the parties understand software terms in those contexts. Note that some of these terms have different meaning when used outside of the software context.

Algorithm is finite set of unambiguous instructions, process, or set of rules performed in a prescribed sequence to achieve a goal, especially a mathematical rule or procedure used to compute a desired result. Algorithms are the basis for most computer programming. (dictionary.com)

App is an abbreviated form of the term “computer application.” A computer application is a software program that’s designed to perform a specific function directly for the user or, in some cases, for another application program. (WhatIs.com)

Authoring Software is computer program designed for creating multimedia and hypertext documents and presentations. The authoring software uses a database to put content into a template which can be created in almost any application and added to a Web-based project.

Click-Through is the action of following a hypertext link to a particular website.

Compiler is a specialized computer program that converts the source code, which is written in one programming language, into machine-readable code or another language, which is generally referred to as object code.

Computer Graphics are pictorial computer output produced, through the use of software, on a display screen, plotter, or printer.

Copyleft License are licenses for software that enable recipients to use, modify, and make derivative works from source code. Copyleft refers to a reciprocity requirement that compels users to disseminate any information necessary to reproduce or modify code. License terms are generally included in the source code.

Data Warehouse is a large store of data accumulated from a wide range of sources within a company and commonly used to guide management decisions.

Deliverable (Software-related) is a tangible or intangible good or service produced as a result of a project which intended to be provided to the Company upon conclusion of the research. Deliverables might include a software development plan, documentation, an application or product, a server upgrade or any other building block of an overall project.

Derivative Work (Software) is a software program based upon preexisting code, including software, which once modified, adapted, or translated represents an original work of authorship.

End User License Agreement (EULA) is sometimes called “clickwraps” or “shrinkwraps,” EULAs indicate the terms under which the end-user may use the software.

Executable Code is the code in machine language (such as binary code) which is directly understood by the computer and executes it without further simplification needed while object code is the code produced by a compiler or interpreter. (Quora.com)

Executable file is a file that contains a program. That is, a particular kind of file that is capable of being executed or run as a program in the computer. (Whatls.com)

Firmware is a software program or set of instructions programmed on a hardware device. It provides the necessary instructions for how the device communicates with the other computer hardware. Firmware is typically stored in the read-only memory (ROM) of the hardware.

GNU General Public License is type of open-source license which permits end users to make changes to the software, such as altering the software source code, provided any refinements of the software are also made available to others under a GNU General Public License (GPL).³

Hardware describes the physical parts of a computer and related devices. Internal hardware devices include random access memory (RAM), the motherboard, and hard drives. External hardware devices include routers, monitors, printers, and scanners.

Maintenance or Software Support License entitles the user to receive new versions of the software for the cost of the maintenance fee, if purchased by the user in addition to the software license.

Object Code refers to the software that results after a compiler program processes software source code.

OEM (Original Equipment Manufacturer) License is a license for software (e.g., firmware) that is delivered with the hardware and is only for use on that piece of hardware. An OEM is tied to the lifecycle of the hardware and typically cannot be transferred to other hardware.

Open-Source Software (OSS) is computer software with source code made available to users with a license in which the holder of the copyright in the software provides the rights to study, change, and distribute the software with very few restrictions on the use or distribution by any organization or user.

Platform is software that enables modular development of other software that extends but does not change the underlying platform.

Proprietary Software is computer software which is owned by the software’s author or assignee (e.g., the copyright owner or, in some cases, patent holder). The owner can restrict use, inspection or modification of source code, and redistribution. Owners of proprietary software usually regard source code as a trade secret.

Proprietary Licenses grant rights to use one or more copies of software, but the ownership of those copies remains with the software publisher.

Shrink Wrapped Software is commercial, off-the-shelf software sold in retail, in contrast to specially-developed software written by programmers for a particular purpose.

Shrink Wrap License is a type of passive contract and EULA printed on paper inside the product box or packaging, which the buyer of shrink wrapped software is deemed to accept, by the fact of opening the  shrink-wrapped package.

Software is a general term describing computer programs, including applications, scripts, and instruction sets.

Software Author is the original creator(s) of the code.

Software Development Plan (SDP) describes a developer’s plans for conducting a software development effort. An SDP provides insight and a tool for monitoring progress. It provides details regarding methods to be used and approach to be followed, and should include specific standards, methods, tools, actions, and should identify the party responsible for the development and qualification of all requirements, including safety and security.

Software Documentation is a general term for documentation encompassing all written documents and materials dealing with a software product’s development and use.

Software Licenses grant rights to use software code without giving up ownership of the code.

Software Owner refers to the author of software code unless the software falls under a ‘work for hire’ exception defined under copyright law. The copyright owner can transfer or share the rights through assignment of the copyright or by granting a license of the copyright.

Source Code is the programming language, which includes instructions, functions, and other statements that tell the software how to function. Source code must be converted to object code or machine language before a computer can read or execute the program.4

Source Code Escrow is the deposit of software source code into an escrow account with a third party. Typically requested by the licensee of software to ensure continued use in the case that the licensor fails to adhere to the terms of the license agreement. Under escrow, the licensee obtains access to the source code if maintenance of the software, as defined in contractually agreed-upon conditions, cannot otherwise be guaranteed.

Testing Environment is a setup of software and hardware for the testing teams to execute test cases. In other words, it supports test execution with hardware, software and network configured.5

Website is a location connected to the Internet that maintains one or more pages on the World Wide Web prepared and maintained as a collection of information by a person, group, or organization.6

Work for Hire is an exception to the law that provides that the author of a work is the copyright owner. Under copyright law, there are two basic exceptions that provide for a work to be a work for hire and therefore not owned by the authors(s): 1) if a work is prepared by an employee within the scope of his or her employment, the employer becomes the presumed owner of the work, and 2) if the work is specially ordered or commissioned, falls within the nine categories enumerated under 17 U.S. Code § 101, and there is a written agreement between the initial owner and the party wishing to claim ownership.

INDUSTRY PERSPECTIVE

Companies often invest in University projects to partner with leading scientists in order to develop new tools or improved technologies. Companies require access to software that is used to produce or use a project result or that is the deliverable under an SRA with a University. The scope of the rights the Company needs varies with the nature of the project and the intended or potential use the Company will make of the software.

There are a number of issues that can impact the availability of specific license types. To avoid unexpected complications, the SOW7 should define any potential deliverables in as much detail as possible. The SOW should specify whether software will be created and whether project deliverables will be original work or an integration of combined software components, hardware components, or both into an overall system.8

It is important for Companies expecting licensable technology to arise from the research to know whether third-party intellectual property (IP) or open-source software will be used or incorporated into any project deliverables. If the software incorporates code owned by a third party or is subject to the terms of an open-source license, a Company may be unable to obtain a license to freely operate, distribute, or manipulate the code or create derivative works for commercial gain. Additionally, ownership and license issues can be particularly complex when a federal funding agency is a prime or co-sponsor as discussed below. University partners also may have licensed third-party software on terms that prevent the University from using the software for commercial research and from distributing or sharing it with a Company.9

Disposition of ownership and software royalties can be difficult issues for both parties to negotiate. A Company may want to assert ownership over research software if the Company has made a substantial investment in the development of the underlying technology that provided the basis for its development, or if a Company has provided proprietary information, technology, or material essential to the research.

Companies benefit from having the exclusive freedom to operate and manipulate software to enhance their competitive edge in the market. Therefore, proprietary source code may be requested over open-source source code.

Companies may support or participate in data warehouse projects that are too costly to duplicate but exist in some form in a University. Use of these data warehouses may require access to the search, classification, presentation, or other software tools used with the data warehouse. The Company would expect that access to the data includes access to the necessary software tools at no extra cost.

Since the useful life and market value of software may be more dependent on being the first, the best, or the Company standard, running royalties and other more conventional proxies for value of patentable inventions may not be as relevant for software. University software is not often developed under the quality control systems Companies need to use before putting software or a software-based product on the market. In addition, software may have limited application, i.e., be useful only (or primarily) to the Company, so that an exclusive license is not necessary. Given these facts, Companies may favor non-exclusive royalty-free licenses (NERF) to software resulting from a sponsored project over exclusive licenses that involve longer negotiation, robust approximations of profit, and accounting of revenue to determine royalties owed.

If each party has contributed to the software development, then each party may be deemed an author or creator,10 and as with joint patents, each party is permitted to license or otherwise exploit the software on a non-exclusive basis without accounting to the other party. Software royalty rates vary significantly, and rates are based on several factors, including whether the software can be readily commercialized or whether the software requires further investment and development before the Company can realize potential benefits.

UNIVERSITY PERSPECTIVE

When software development is contemplated under a sponsored project SOW, it is extremely important for the University research team and the Company to agree on a software development plan (SDP) and to clearly define mutual expectations about the documentation, storage, updates, bug fixes to or other maintenance of the software. It is equally important for Universities and Companies to clearly define circumstances and contract terms under which the non-owning party may obtain license rights and the scope of those rights. Licenses terms or agreements should reflect the Company’s intention to commercialize the software and include terms to ensure the University will have the right to continue to use the software it develops at least for internal research purposes. A NERF may be appropriate for software that is a research tool or that is in a very early stage. Otherwise, the University would expect to receive some consideration for commercial use of the software that is based on its value to the Company.

Universities are generally not able or willing to assume ongoing responsibility for bug fixes, maintenance, support, or service of software resulting from sponsored activity and will disclaim those responsibilities in the SRA. The University views these activities as more consistent with the Company’s product development and customer service roles. But, as discussed below, Universities do participate in open-source software groups and consortia that identify and resolve bugs and other software issues in research tools that are not commercially marketed.

Although public policy considerations, government funding arrangements, and tax regulations may preclude Universities from assigning copyright in software to Companies, certain exceptions may apply. Generally, Universities prefer to retain ownership of both object and source code. However, depending on the type of project and the specific nature of the software deliverable, some Universities may be willing to assign the object code to the Company, particularly if it is specifically developed for the Company or the Company’s application of the object code is not readily useful to other potential licensees. Universities are less likely to assign a title or grant an exclusive license to the source code, unless the terms of the title or license permit the University to continue to use the code for research purposes, to make derivative works, and to use it to create and license out object code for other applications.11

Before software can be copyrighted or licensed, authors/creators must be able to demonstrate both ownership and originality. To verify ownership, the creators need to identify all of the individuals who contributed to the work and ensure their intellectual property rights are not infringed by any rights granted to a Company through an SRA. To verify originality, all creators must provide confirmation that the software does not incorporate material from any other source (including open-source software tools or scripts) and that each creator’s contribution to the software is original. If University creators have integrated any third-party IP into the final deliverable, then any dissemination or license arrangement must be consistent with the terms of any third-party or open-source licenses.

Increasingly, University researchers are opting to make software they create available through open-source licensing arrangements as a way of promoting collaboration and sharing new platforms and technologies. Universities are typically amenable to disseminating original software under open-source licenses, provided the arrangement is approved by the creators/authors and is consistent with any rights granted by the University to the Company (or reserved by the government) in the SRA. If the software has more than one author (who could be an employee of a collaborating University, visitor, or a student), each must approve the open-source distribution license and demonstrate they have the right to do so.

In the event that University software creators develop new software and believe it could have broader application, may be of commercial interest, and is not licensed to the Company under the terms of the SRA, licensing is typically handled through a University’s technology transfer office (TTO). (For more information on the roles and responsibilities of different University offices, see UIDP Comparing Internal Structures Guide.)

OPEN-SOURCE CONSIDERATIONS

Open-source software is becoming a widely utilized product of research collaborations. Because it can be developed in an open, transparent, and collaborative manner, Universities and Companies are able to freely exchange, develop, study, and distribute the product of their research without being encumbered by restrictions placed on proprietary development.

When a software program is open source, it generally means the program’s source code is freely available to the public. Open-source programs can be modified and distributed by users and are often developed as a community rather than by a single organization. Since the source code of an open-source program can be modified by several people, the software may also be free to download and use. The terms of use are often defined by a GNU General Public License, or other form of predetermined license, which serves as the Software License Agreement (SLA) for many open-source programs.12

As the commercial value of source code has decreased over the past decade, many Companies are opting to release software under an open-source license. Some businesses have realized significant benefits in making software and source code readily available, even in cases where the software application serves a limited purpose specific to the Company’s activities or as a complement to a hardware deliverable. Key advantages of releasing software under an open-source license are that other programmers will have access to the code, the ability to fix bugs, improve security, and modify the code to broaden its applicability beyond its original scope. When software is released with a copyleft license, future users are required to report back any modifications and make any updated releases available to the Company. While proprietary software is a static product, able to be read, modified, or updated solely by the owner or licensee’s technical resources, open-source licensing offers a less resource intensive pathway to new applications or more robust software applications.

SOFTWARE TERMS IN SRAs GENERALLY

SRAs include clauses that deal with software for a variety of reasons. Both the Company’s and University’s researchers have acute interests in defining ownership and rights with regard to any software developed under the contract. An SRA should clearly lay out the respective rights of the parties to utilize the software during and after the agreement terminates.

In addition, and when appropriate, all parties may be interested in having a clear pathway to commercialization set forth in the agreement. The following topics provide a useful guide for successfully negotiating software specific terms in standard research agreements:

  1. Definitions. Because of the complexity of the issues involved, it is highly recommended that SRAs clearly define the intended categories of results of the project, e.g., patents, copyrights, data, and software,13 and then describe the corresponding rights of the University and Company using those defined terms.
  2. Deliverables. When software is a project deliverable, the SRA should include a Software Development Plan (SDP) that includes clear parameters to which the software code will be written, documented, secured, and validated. The SOW should set forth expectations regarding maintenance, updates, and storage. Some Companies may require the University to place and store the software code and any materials required to maintain the software with a neutral party or escrow agent. In such cases, the SRA should designate which materials are to be placed into escrow and should include language regarding the delivery method, the timing of the deposit, and payment obligations.14
  3. Third-Party Software. The SRA should stipulate whether third-party software is necessary to be incorporated into a project deliverable or utilized in the course of the project. Use of third-party software should also be addressed in the SOW, such as use of open-source, modeling, or authoring software used to conduct research or produce deliverables without rights conveyed to the Company. Access by the Company to third-party software should also be addressed.
  4. Improvements/Modifications/Updates/Support. The parties should specify how improvements, modifications, and updates to the software will be handled, whether the University is required to produce any of them, and whether the Company has rights in them. If support of the software is required, it should be described in the SOW and covered in the project budget.
  5. Confidentiality. SRAs typically include confidentiality provisions similar to those in a standard non-disclosure agreement. (See UIDP Contract Accord 9: Confidential Disclosure Agreements.) In some cases, software provided by a Company for research purposes or software developed under an SRA may be designated as proprietary.
  6. Non-Exclusive License. While SRAs do not include specific licensing terms, if the University owns the software copyright, it typically grants the Company, at least, a non-exclusive royalty-free license (NERF) to use the software within its own organization for research and development purposes. If the Company has contributed information or material critical to the software development, if the software application is useful only or primarily to the Company, or in other situations that warrant this position, the University may extend the NERF to include commercialization or grant a non-exclusive royalty-bearing license of broad scope. The NERF should specify whether it is sublicensable. The NERF may be subject to a confirmatory license (a separate document that formally conveys the rights granted in the SRA).
  7. Option to Obtain Exclusive Rights. SRAs typically grant Companies an option to obtain an exclusive license to software that is expected or required to be developed in performance of the project as described in the SOW. Options are typically time sensitive and expire after a period of time specified in the SRA. Exclusive license agreements, whether granted in the SRA or in a separate license agreement, should clearly state whether the Company has the right to make derivative works and whether the license is sublicensable and includes specific conditions, limitations, and payment terms for royalties or other negotiated fees.
  8. Export Control.15 When export-controlled technology is involved in the research, the SRA should include language to require the parties to comply with applicable export control regulations, including implementation of adequate security measures. (For more information on export control, see UIDP Contract Accord 7: Export Control.)
  9. Representations/Warranties/Indemnification. The SRA may include University disclaimers of the warranties of merchantability, fitness for a particular purpose, and non-infringement. A clause that releases the authors or copyright holders from liability for any claims or damages arising in connection with the software or its use may also be included. These disclaimers recognize that the software delivered by the University is usually early stage and requires quality control, debugging, and further development by the Company.
  10. Patents. While software is often protected under copyright, there are instances where software may be patented as an invention. SRAs typically describe the process for determining if and when a patent application covering software will be filed, as well as the respective rights and responsibilities of each party.

SOFTWARE IN GOVERNMENT CONTRACTS

The scope of rights as they pertain to computer software developed under government contracts can be somewhat complicated. In addition, the majority of Companies operating under both government and non-government contracts tends to follow, at least in part, the complicated rules defined in the Federal Acquisition Regulations (FAR).16

  1. Scope of Rights.17 It is important for both Companies and University researchers to be aware that if a government funding agency is a research sponsor, any resulting software is subject to any government-reserved rights. When a government funding agency sponsors University research in whole or part, the rights to any software developed under the contract typically follow, at least in part, the rules defined in the Federal Acquisition Regulations (FAR). Rights reserved by the government take precedence over any contractual rights granted to a third party, including Company research partners. Depending on the type of contract and the nature of the data involved, the government is generally granted one of the following licenses: unlimited rights, government purpose rights, restricted rights, or limited rights. (For more information on FAR and how it relates to SRAs, see the section on Copyrights Under Federally-Funded Projects in UIDP Contract Accord 8: Copyrights.)
  2. Unlimited Rights License. If the government exclusively funds a project, they are generally given an unlimited rights license in non-commercial computer software and non-commercial computer software documentation. This includes owner’s manuals, user’s manuals, installation instructions, operating instructions, and other similar items, regardless of storage medium, that explain the capabilities of the computer software or provide instructions for using the software.18 An unlimited rights license enables the government to use, modify, reproduce, release or disclose technical data or computer software in whole or in part, in any manner, and for any purpose whatsoever.
  3. Government Purpose Rights. If the government and the contractor each provide project funding, and the contractor delivers proprietary technical data or computer software, the government may acquire a government purpose rights license. A government purpose rights license entitles the government to use, modify, reproduce, release, or disclose the technical data or computer software within the government without restriction and outside the government for any activity in which the U.S. government is a party. This includes cooperative agreements with international or multi-national defense organizations or sales or transfers by the U.S. government to foreign governments or international organizations. Government purposes include competitive procurement, but do not include use for commercial purposes.19
  4. Restricted or Limited Rights. If the project is exclusively funded by a Company, the government may acquire a restricted rights license in non-commercial computer software and a limited rights license in non-commercial technical data. A restricted rights license applies only to non-commercial computer software and enables the government to use a computer program subject to a limited set of parameters. A limited rights license permits the government to use, modify, reproduce, release, perform, display, or disclose technical data, in whole or in part, within the government.

PRINCIPLES

  1. The SOW should adequately address the research objectives, including a clear description of any software milestones or deliverables required to ensure the parties share a mutual understanding of the specific project goals.
  2. Software deliverables should be described in as much detail as possible, and the SOW should include a software development plan that includes applicable scope of work, standards, timing, platforms to be addressed, and the necessary source code involved.
  3. The University should inform the Company of any proposed third-party or open-source software it plans to use in the project or incorporate into a deliverable.
  4. The scope of rights (and terms of use) relating to the use of any third-party or open-source software identified in the SOW needs to be addressed in the SRA.
  5. Obligations regarding improvements, modifications, software support, debugging, and other obligations that may extend beyond the term of the SRA should be discussed, allocated between the parties as agreed, and appropriately budgeted.
  6. The SOW should state any intention to allow access and use of project software through open-source licensing in the Open-source licenses must be consistent with any applicable background and third-party rights.
  7. An SRA typically grants the Company non-exclusive royalty-free rights of a defined scope and an option to negotiate an exclusive license.

OUTLIERS

The following topics are not discussed in this Contract Accord:

  • Foreign Intellectual Property Law; and
  • Public Dedication of IP – Proactively placing intellectual property (IP) in the public domain has become increasingly important for the advancement of software development and related fields. Leading companies are actively implementing programs to advance the public dedication of IP. For more information, see UIDP Public Dedication of Intellectual Property Quick Guide.

FOOTNOTES

[1] See UIDP Contract Accord 10: Material Transfer Agreements.

[2] 17 U.S. Code § 101

[3] See GNU General Public License web page for more information http://www.gnu.org/licenses/gpl-3.0.html.

[4] American Heritage® Dictionary of the English Language, Fifth Edition. Copyright © 2011 by Houghton Mifflin Harcourt Publishing Company. Published by Houghton Mifflin Harcourt Publishing Company. All rights reserved.

[5] Retrieved from https://www.guru99.com/test-environment-software-testing.html

[6] American Heritage® Dictionary of the English Language, Fifth Edition. Copyright © 2011 by Houghton Mifflin Harcourt Publishing Company. Published by Houghton Mifflin Harcourt Publishing Company. All rights reserved.

[7] See UIDP Contract Accord 1: Statement of Work

[8] IEEE 1990

[9] National Research Council. 1993. Intellectual Property Rights in Industry-Sponsored University Research: A Guide to Alternatives for Research Agreements. Washington, DC: The National Academies Press., Pg. 6. https://doi.org/10.17226/10009.

[10] See UIDP Contract Accord 8: Copyrights for more detail.

[11] National Research Council. 1993. Intellectual Property Rights in Industry-Sponsored University Research: A Guide to Alternatives for Research Agreements. Washington, DC: The National Academies Press., Pg. 19. https://doi.org/10.17226/10

[12] Christensson, P., Open Source Definition, Oct 30, 2008, Retrieved 2016, Apr 27, from http://techterms.com

[13] Potentially patentable inventions are covered in UIDP Contract Accord 6: Foreground Intellectual Property. Inventions outside the scope of research described in an SRA are covered in UIDP Contract Accord 5: Background Intellectual Property. Copyrightable materials are covered in UIDP Contract Accord 8: Copyrights. Potentially patentable inventions that have been conceived but not reduced to practice are covered in UIDP Contract Accord 4: Other Research Results.

[14] https://csrc.nist.gov/csrc/media/publications/conference-paper/1996/10/22/proceedings-of-the-19th-nissc-1996/documents/paper001/article.pdf

[15] See EAR Part 734.

[16] See DFAR Subpart 227.72

[17] See DFAR Subpart 227.72

[18] See 48 CFR 2.101

[19] See DFAR 252.227-7013

See All Contract Accords