SPRUCE Series

This is the second installment in a series of three blog posts highlighting seven recommended practices for acquiring intellectual property. This content was originally published on the Cyber Security & Information Analysis Center's website online environment known as SPRUCE (Systems and Software Producibility Collaboration Environment. The first post in the series explored the challenges to acquiring intellectual property. This post, which can be read in its entirety on the SPRUCE website, will present the first four of seven best practices for acquiring intellectual property.

1. Determine the program's needs
2. Establish an IP strategy
3. Determine licenses
4. Address IP in source selection
5. Address IP in contracts
6. Protect IP assets
7. Conduct IP audits

Managing Intellectual Property in the Acquisition of Software-Intensive Systems
https://www.csiac.org/spruce/resources/ref_documents/recommended-practices-managing-intellectual-property-acquisition-software-in

Recommended Practices for Managing Intellectual Property in Acquisitions

1. Determine the program's IP needs across the acquisition lifecycle. Your organization may want to use the technical data or computer software for a long time, so you'll need to develop an IP strategy that covers the entire life cycle. This potentially encompasses system development, testing, installation, transition to use, training, operations, error fixing, enhancement, transition to retirement, and retirement. Since organizational needs may change over time, so must the actions taken to mature and protect the intellectual property. Consider who will need to use or modify the data or software now, who will need to use or modify it a year or two from now, and so on through the expected life cycle of the program. Pay particular attention to which stakeholders are involved or affected in the different phases in the life of the system. If it is impossible to envision what future events could change the organization's needs for flexibility in using the data or software, several approaches may be pursued to avoid long-term vendor lock-in.
2. Establish and maintain an IP strategy as part of the broader acquisition strategy. The program manager must develop an IP strategy as part of the broader acquisition strategy for the program (Interim 5000.2, Enclosure 2, para. 7.d). The acquisition strategy describes the program manager's plan for program execution across the entire life cycle. It identifies the acquisition approach and describes the business, technical, and support strategies that the program manager will use to manage risks and meet objectives (Interim 5000.2, Enclosure 2, para. 7). Thus, the program's acquisition strategy includes business considerations such as establishing or maintaining access to competitive sources for critical system components, which inevitably touch on issues of IP ownership and data rights.

For example, the program may need to share software or technical data for critical components with other organizations. As another example, the acquisition strategy should identify the support strategy for life-cycle sustainment and continuous improvement of system affordability, reliability, and supportability, while sustaining readiness. Such considerations also touch on data rights, especially if support will be performed by an organization different from the supplier. IP attorneys can identify and help the program manager understand the consequences and risks associated with alternative approaches to licensing and data rights. Program managers should involve IP attorneys early in developing the program's acquisition strategy.

3. Determine what kind of licenses you need. Although there are many types of licenses, there are three main types of licenses for noncommercial software that reflect a range of tradeoffs between cost and scope of external release permitted.

• Unlimited rights: These rights typically apply to data or software exclusively funded by the government. Unlimited rights give you the right to use, modify, reproduce, release, or disclose the technical data or software for any purpose to anyone.
• Government purpose rights (GPR): These rights apply to technical data or software developed with mixed funding (i.e., partially funded by the government and partially by the developer) or when the government is willing to accept lesser rights in return for other considerations. This right involves the right to use, duplicate, or disclose technical data for government purposes only. For a negotiated period of time, you'll agree that you will not use the technical data or software for commercial purposes. After the end of the period, you have unlimited rights. GPRs can cost less than unlimited rights and confer a broad range of rights to use, modify, reproduce, release, perform, display, or disclose (DFARS 227.71), but you should be sure that restrictions you incur during that period will not hamper your project.
• Restricted rights: If the development of the noncommercial software is exclusively funded by the contractor, the agency usually acquires a restricted-rights license. The restricted license can limit the government to use the licensed software with only one computer at one time, set a maximum to the number of copies that your organization may make for safekeeping or backup, or set conditions under which your organization can modify the intellectual property. Software funded solely by the contractor can cost the government less than providing some or all of the funding to develop the same software. However, the risk with this form of license is that you may be subject to vendor lock-in, forever beholden to the contractor who sold you the license. For example, you might need to modify the software during sustainment or hire a third party to provide maintenance support, either of which might require you to renegotiate with the contractor for additional rights at a higher price than it might have cost earlier.

DoD policy states that "contractors shall not be prohibited or discouraged from furnishing or offering to furnish items, components, or processes developed at private expense solely because the Government's rights to use, modify, release, reproduce, perform, display, or disclose technical data pertaining to those items may be restricted" (DFARS 227.7103-1). There are situations in which obtaining a license to such software makes a lot of sense, but be mindful of how you will use the software now and in the future (Practice 1).

What kind of license will best meet your needs? Contracting for more rights than you need will waste money. But contracting for fewer rights than you need will waste resources too. You need a decision framework to determine what kind of license to pursue. One decision framework suggests an approach for identifying your organization's needs for license rights and the appropriate license type for systems with noncommercial computer software or as standalone software in the DoD environment.

4. Address intellectual property in the source-selection process. Source selection includes pre-solicitation activities such as developing an RFP (sometimes called a solicitation package) that includes a description of the criteria and evaluation process that the program manager will use to evaluate proposals (among other items such as the statement of work for the supplier). The statement of work should address any requirements that the government has, including deliverables, data rights, and post-project support (the results of Practices 1 and 2). Areas to address in the evaluation criteria include a potential supplier's IP and proprietary rights so that the program manager can consider possible impacts of these when evaluating proposals while remembering that a supplier may furnish or offer items, components, or processes developed at private expense.

The government makes the award on the basis of an evaluation process that uses these criteria to rate or score the proposals. The evaluation of a potential supplier's proposal will include an assessment of the origins for all software that will be incorporated into the final delivered system, such as whether it will use other subcontractors or OSS and associated IP ownership and data-rights implications. In this way, the award will be based in part on an evaluation of a potential supplier's ability to meet government data-rights requirements. A proposer might also provide a different overall approach to how it will manage intellectual property throughout the life cycle of the contract. Again, the program manager must carefully evaluate such a proposal against the needs of the government as reflected in the statement of work and evaluation criteria. After selecting a proposer, it may be necessary to negotiate for licenses and data rights.

Looking Ahead

Technology transition is a key part of the SEI's mission and a guiding principle in our role as a federally funded research and development center. We welcome your comments and suggestions on this work.

The next post in this series will present the final four recommended practices for acquiring intellectual property.

Below is a listing of selected resources to help you learn more. We have also added links to various sources to help amplify a point. Please be mindful that such sources may occasionally include material that might differ from some of the recommendations in the article above and the references below.

Learn More

FARs Sections 27.4 and 52.227 and DFARS Sections 227. 71 and 227.72 cover rights in technical data and computer software. And the Defense Acquisition University offers a course on Intellectual Property and Data Rights.

For more information about acquiring intellectual property, please see:

ACQuipedia. Intellectual Property and Data Rights. DAU, 2013. https://www.dau.mil/acquipedia/pages/articledetails.aspx#!116

Air Force Space Command Space and Missile Systems Center. Acquiring and Enforcing the Government's Rights in Technical Data and Computer Software Under Department of Defense Contracts: A Practical Handbook for Acquisition Professionals. U.S. Air Force, October 2012.
https://daytonaero.com/wp-content/uploads/SMC-JA_Technical-Data-and-Computer-Software-Rights-Handbook-9th-Edition_10-Oct-2018.pdf

CENDI Copyright Working Group. Frequently Asked Questions About Copyright and Computer Software. October 2010. https://www.cendi.gov/publications/09-1FAQ_OpenSourceSoftware_FINAL_110109.pdf

Department of Defense. Better Buying Power. Focus Area: Promote Competition. Initiative: Enforce open architectures and effectively manage technical data rights. June 2013.
http://www.acq.osd.mil/fo/docs/betterBuyingPower3.0(9Apr15).pdf

DOD Open Systems Architecture Data Rights Team. DoD Open Systems Architecture Contract Guidebook for Program Managers (Version 1.1). DoD, June 2013. https://apps.dtic.mil/dtic/tr/fulltext/u2/a550060.pdf

For more information about data rights, please see:

Barrow, Jane. Government Data Rights Under the DFARS. CENDI Principals Meeting, July 2009. http://www.cendi.gov/presentations/07-08-09_Barrow.pdf

Defense Information Systems Agency. Better Buying Power: Understanding and Leveraging Data Rights in DoD Acquisitions. January 2013. http://www.disa.mil/About/Legal-and-Regulatory/DataRights-IP/~/media/Files/DISA/About/GC/BuyingPowertrifold.pdf

Defense Information Systems Agency. Data Rights. http://www.disa.mil/About/Legal-and-Regulatory/DataRights-IP/DataRights

For more information about acquisition regulations and policies, please see:

Department of Defense. Defense Federal Acquisition Regulation Supplement (DFARS). Sections 227 and 252. June 2013, September 2013. http://www.acq.osd.mil/dpap/dars/dfarspgi/current/index.html

General Services Administration, Department of Defense, & National Aeronautics and Space Administration. Federal Acquisition Regulation. Sections 27.4 and 52.227. March 2005. http://www.acquisition.gov/far

Office of Acquisition Policy. General Services Administration Acquisition Manual (GSAM). U.S. General Services Administration. November 2012. http://www.acquisition.gov/gsam/gsam.html

For more information about commercial software acquisition, please see:

Office of the Under Secretary of Defense for Acquisition, Technology, and Logistics. Intellectual Property: Navigating Through Commercial Waters (Version 1.1). OSD, October 2001. http://www.acq.osd.mil/dpap/docs/intelprop.pdf

For more information about using decision frameworks to determine a licensing strategy, please see:

Gross, Charlene. A Decision Framework for Selecting Licensing Rights for Noncommercial Computer Software in the DoD Environment (CMU/SEI-2011-TR-014). Software Engineering Institute, Carnegie Mellon University, 2011. http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=9995

Gross, Charlene. Do You Own It or Not? A Primer on Noncommercial Software Licensing. IEEE Software Technology Conference, 2010. https://apps.dtic.mil/dtic/tr/fulltext/u2/a557433.pdf