By Software Engineering Institute
In November 2013, the Department of Defense (DoD) released Interim DoD Instruction 5000.02, “Operation of the Defense Acquisition System.” Enclosure 2 of this document describes policies that apply to the management of acquisition programs. Regulations require that programs develop an intellectual property (IP) strategy as part of the acquisition strategy. In addition, Better Buying Power, the DoD mandate to “do more without more,” published in 2010, includes seven initiatives that emphasize both greater efficiency and more innovation. Both of these references address the problem of IP management: how a program manages IP can have life-cycle cost implications.
Managing IP has special concerns for software. We distinguish two types of software:
- Commercial software is normally acquired from a commercial vendor. In this case, the DoD typically acquires rights identical to those normally available to the general public.
- Noncommercial software is specifically developed to meet the needs of a DoD acquisition and is not available to the general public.
We focus here on IP management practices with special emphasis on noncommercial software because of its relevance to system acquisition. This includes planning and consideration of data rights and licenses throughout the life cycle of the acquisition.
Our discussion of acquiring intellectual property has four parts. First, we set the context by providing an answer to the question “Why is acquiring intellectual property challenging?” The seven recommended practices for acquiring intellectual property follow. We then briefly address how an organization can prepare for and achieve effective results by following these practices. We conclude with a list of selected resources to help you learn more about acquiring intellectual property. Also, we’ve added links to various sources to help amplify a point.
Every organization is different; judgment is required to implement these practices in a way that benefits your organization. In particular, be mindful of your mission, goals, existing processes, and culture. All practices have limitations. Some of these practices will be more relevant to your situation than others, and their applicability will depend on the context to which you apply them. To gain the most benefit, you need to evaluate each practice for its appropriateness and decide how to adapt it, striving for an implementation in which the practices meet your needs. Also, consider additional collections of recommended practices. Monitor your adoption and use of these practices and adjust as appropriate.
These practices are certainly not complete—they are a work in progress. We welcome your feedback (use the comments section at the end).
Why is acquiring intellectual property challenging?
For any program in which software is a critical element of the system, data rights that do not meet needs for the entire life cycle can impede program flexibility and thus increase program costs. Many decisions made early in the development effort will apply to the entire life cycle of the product, so the program manager should take care in the initial stages of an acquisition to address intellectual property appropriately.
The program manager should understand intellectual property, data rights, and license types from a holistic perspective; how these legal concepts relate to the goals for the system; and how the system may need to evolve in the future. In particular, the program manager will need to address the following challenges:
- Understanding terminology. Program managers need to understand the legal definitions of some basic IP terms so that they can correctly interpret them and appropriately address IP issues in requests for proposals (RFPs) and contracts:
- Intellectual property “refers to creations of the mind, such as inventions; literary and artistic works; designs; and symbols, names, and images used in commerce. IP is protected in law by, for example, patents, copyright and trademarks, which enable people to earn recognition or financial benefit from what they invent or create” (WIPO 2013). For example, technical data and computer software can be patented or have copyrights.
- Technical data “means recorded information, regardless of the form or method of the recording, of a scientific or technical nature (including computer software documentation). The term does not include computer software or data incidental to contract administration, such as financial or management information” (DFARS 252.227.7013 (15)).
- Computer software “means computer programs, source code, source code listings, object code listings, design details, algorithms, processes, flow charts, formulae and related material that would enable the software to be reproduced, recreated, or recompiled. Computer software does not include computer databases or computer software documentation” (DFARS 252.227.7013 (a)(3)).
- Understanding the context for the acquisition. An acquisition can be influenced by multiple external sources that constrain the acquisition program. For example, the acquisition may take place in the context of a program executive office that imposes requirements on all acquisitions within its purview. Also, the system being acquired may need to interoperate with other systems being acquired. This may warrant interactions among multiple program managers for integration of the systems to be successful.
- Determining appropriate data rights. Data rights refers to the government’s license rights to technical data and computer software. All contracts that entail producing, acquiring, or using data to meet contract performance requirements must contain terms that define the rights and obligations of the government and the contractor to use, reproduce, and disclose that data. Data rights clauses do not specify the type, quantity, or quality of data that the contractor will deliver. Therefore, the contract must specify those details (FAR 27.403).
Analogous to the ‘we need a program—let’s start coding’ school of short-sighted software development, the ‘we need a license—let’s go for unrestricted’ strategy for data rights may cost your organization more money than it needs to spend. The Federal Acquisition Regulations (FAR) and Defense Federal Acquisition Regulation Supplement (DFARS state that an organization should obtain only the rights “necessary to satisfy agency needs,” and no more. Deciding exactly which rights will satisfy agency needs—not just now but also in the future—can be challenging.