The SPRUCE Series: The Challenges to Acquiring Intellectual Property
Software and acquisition professionals often have questions about recommended practices related to modern software development methods, techniques, and tools, such as how to apply Agile methods in government acquisition frameworks, systematic verification and validation of safety-critical systems, and operational risk management. In the Department of Defense (DoD), these techniques are just a few of the options available to face the myriad challenges in producing large, secure software-reliant systems on schedule and within budget.
In an effort to offer our assessment of recommended techniques in these areas, the SEI built upon an existing collaborative online environment known as SPRUCE (Systems and Software Producibility Collaboration Environment), hosted on the Cyber Security & Information Systems Information Analysis Center (CSIAC) website. From June 2013 to June 2014, the SEI assembled guidance on a variety of topics based on relevance, maturity of the practices described, and the timeliness with respect to current events. For example, shortly after the Target security breach of late 2013, we selected Managing Operational Resilience as a topic.
Ultimately, SEI curated recommended practices on five software topics: Agile at Scale, Safety-Critical Systems, Monitoring Software-Intensive System Acquisition Programs, Managing Intellectual Property in the Acquisition of Software-Intensive Systems, and Managing Operational Resilience. In addition to a recently published paper on SEI efforts and individual posts on the SPRUCE site, these recommended practices will be published in a series of posts on the SEI Blog. This post, the first in a multi-part series, details the challenges to acquiring intellectual property, as detailed in the SPRUCE post. Subsequent posts in this series will present seven recommended practices for acquiring intellectual property as well as guidelines for getting the most from the recommended practices.
Managing Intellectual Property in the Acquisition of Software-Intensive Systems
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 lifecycle 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 lifecycle 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 have 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 lifecycle can impede program flexibility and thus increase program costs. Many decisions made early in the development effort will apply to the entire lifecycle 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[HB2] ). 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)).
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.
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 series will introduce the seven 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.
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://dap.dau.mil/acquipedia/Pages/ArticleDetails.aspx?aid=7bfcfeee-b24b-4fdd-ad7b-046437729519
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://acc.dau.mil/CommunityBrowser.aspx?id=431675&lang=en-US
CENDI Copyright Working Group. Frequently Asked Questions About Copyright and Computer Software. October 2010. http://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://bbp.dau.mil/bbp5focus.html http://bbp.dau.mil/docs/Open_Systems_Architecture_%20Data_Rights_10_June_2013.pdf
DOD Open Systems Architecture Data Rights Team. DoD Open Systems Architecture Contract Guidebook for Program Managers (Version 1.1). DoD, June 2013. https://acc.dau.mil/OSAGuidebook
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. http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA557433