7 Recommended Practices for Managing Intellectual Property in the Acquisition of Software-Intensive Systems
This is the third 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. The second post in the series presented the first four of seven practices for acquiring intellectual property. This post will present the final three of seven practices for acquiring intellectual property as well as conditions under which organizations will derive the most benefit from recommended practices for acquiring intellectual property.
The post Managing Intellectual Property in the Acquisition of Software-Intensive Systems can be read in its entirety on CSIAC site at https://www.csiac.org/spruce/resources/ref_documents/recommended-practices-managing-intellectual-property-acquisition-software-in.
Here are the first four recommended practices covered in previous posts.
1. Determine the program's needs
2. Establish an IP strategy
3. Determine licenses
4. Address IP in source selection
5. Address intellectual property in contract negotiations and in the contract. Best practice would be to have data rights specified in the RFP consistent with the government's needs and purposes and then to select responsive suppliers during source selection. During contract negotiations, the program manager may need to negotiate for additional data rights as well as additional deliverables needed to execute those data rights. These deliverables might include software documentation, source code, design details, algorithms, processes, flow charts, and other materials that enable the software to be reproduced or recompiled. You also must explicitly contract for items necessary to maintain the software across its life cycle, such as test plans, programming manuals, user manuals, and maintenance manuals. The OSA Guidebook provides a sample Contract Data Requirements List for software acquisition (p. 183, Example 3). Finally, prior to acceptance, the government should ensure that all restrictive markings on deliverables are consistent with the government's licensing rights.
6. Protect IP assets. Protecting IP assets (e.g., patents, trademarks, service marks, copyrights, and trade secrets) is critical to sustaining data rights through the life of the program. Protecting intellectual property involves such activities as
- registering the intellectual property (e.g., filing a patent)
- establishing contractual agreements between the government and other parties regarding the use and disclosure of intellectual property (making expectations clear and explicit)
- marking IP assets in conformance with their registration status and contractual agreements to inform users of their rights regarding that asset and associated distribution
- conducting regular audits to help ensure that the intellectual property will be properly handled during the program life cycle
Protection also involves providing access controls to information. Recent changes to the DFARS introduce additional safeguard and reporting requirements on the handling of unclassified, controlled technical information. Although primarily a security issue, some of the IP protection activities can be extended to address the handling of such information.
7. Conduct IP audits. The goal of an IP audit is to assure that a program is properly implementing its practices for IP management. Planning for audits should begin early in the program and should identify the scope of assets to audit and the criteria to apply in evaluating them. The audit should confirm the validity of the assets and identify the IP owner. In addition, the audit should assess the compliance with the other IP-management practices, such as those related to protecting intellectual property (Practice 6). The value of audits goes beyond providing an independent view of compliance; longer term, they provide an opportunity to identify weaknesses in the current implementation of IP management and thus opportunity for making longer term improvements in management of IP.
Program managers should note several additional key points about these practices. Organizations may incorporate IP practices in different ways. For example, organizations may incorporate some IP practices within the context of other practices. For example, it could implement IP-audit practices as part of a more encompassing configuration-management practice. An organization must determine the means by which to implement IP practices in the organization's own context in light of its goals, culture, and structure.
Also, the organization's implementation of the IP practices may need to change over time to reflect changes in regulations, acquisition types, lessons learned, and the types of software and technical data that the organization acquires or licenses. When new restrictions are introduced (e.g., the one mentioned in Practice 6 on safeguarding unclassified, controlled technical information), programs may successfully adapt their internal operations to comply with the new restrictions.
Under what conditions will organizations derive the most benefit from recommended practices for acquiring intellectual property?
To achieve success in the management of intellectual property, the program manager should emphasize the following activities:
- Make the management of intellectual property a priority. The effective management of intellectual property should become a priority or even a core competency for the program. Making the management of intellectual property a priority is especially important if the organization regularly engages in contracting for systems incorporating a mix of noncommercial as well as commercial software from multiple sources, including commercial off-the-shelf (COTS) software and OSS.
- Develop a relationship with those who have expertise in intellectual property. IP attorneys are in short supply but high demand, and not all contract lawyers have specialties in intellectual property. Therefore, the program manager should establish and maintain relationships with IP attorneys, who can bring to bear deep knowledge of IP concepts and strategies, as well as help determine the implications that program and stakeholder objectives have for IP and data rights. The program manager should derive explicit objectives for IP and data rights, which will serve to align the members of the team and stakeholders before writing an RFP and contract that detail the IP requirements.
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.
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://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.
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.
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