An official website of the United States Government
E-2.1 Conduct Acquisition Planning
The Program Managers and MATDEVs are required to document an IP strategy for all program types covered by DoDI 5010.44, Intellectual Property Acquisition and Licensing, starting at the Materiel Development Decision (MDD) and out through the declaration of a Program of Record (POR). The IP strategy is summarized in the Acquisition Strategy/Plan or SAMP and identifies the program’s comprehensive approach to managing the IP, data deliverables, and license rights requirements that will affect the program’s cost, schedule, and performance throughout the acquisition lifecycle. The IP strategy evolves over time and should continuously reflect the current status and desired goals of the program which is achieving greater competition and more affordable sustainment costs within the business objectives of the program. Acquisition planning includes all members of the IPT, to include PM, Engineering, Scientists, PCOs, Legal Counsel, etc.
Defense Acquisition University courses and learning modules to assist in Intellectual Property acquisitions are listed below. The courses are current as of the publication date of this appendix, please reference https://www.dau.edu/blogs/dau-intellectual-property-ip-and-data-rights-resources for additional offerings.
Courses/Learning Assets
CLM 002, Intellectual Property (IP) Valuation
CLE 068, Intellectual Property and Data Rights
CLE 069, Technology Transfer
CLE 019, Modular Open Systems Approach
CLM 071, Introduction to Data Management
CLM 072, Data Management Strategy Development
CLM 073, Data Management Planning System
CLM 075, Data Acquisition
CLM 076, Data Markings
CLM 077, Data Management Protection and Storage
LOG 2150, Technical Data Management
CACQ 008, Foundational IP Credential.
CACQ 011: Foundational Software Acquisition Management Credential
CON 0180: Data Rights
IP Strategy
When developing the comprehensive IP strategy and the capability requirements for performance and sustainment, consider the following in respect to IP, data deliverables, and associated license rights (for additional information consult Army Directive 2018-26, Enabling Modernization Through the Management of Intellectual Property.):
1. Develop an IP strategy that accounts for both short-term and long-term needs, covering the full lifecycle of the system or service. The IP strategy should continuously be assessed (e.g., sustainment reviews (SR)) and updated to reflect current status (i.e. evolving technology, reduced program cost or schedule, etc.) and desired goals/objectives. At a minimum, customize IP strategies based on the common, shared, and unique characteristics of the system and its components: system architecture and interfaces: product support/sustainment strategy: organic industrial base strategy of the DoD Component concerned; whether the item can be found in the commercial market: and whether the standard commercial licensing terms meet DoD needs. (NOTE: These can be considered strengths during a tradeoff, but cannot be mandated.)
2. Determine the appropriate sustainment approach to use for the IP strategy. The strategy should focus on achieving greater competition and more affordable sustainment costs. Anticipate the impact of sustainment costs within program business objectives over the entire system or service lifecycle. (NOTE: This can be considered a strength during a tradeoff, but cannot be mandated.)
3. Determine what kind of data (e.g., form, fit, and function data), software, and associated license rights are required/desired for all stages of the acquisition life cycle, including operation, maintenance, installation, and training (OMIT); modernization; and sustainment. The IP strategy should be customized to meet specific sustainment needs of the program (i.e., data deliverable and any required computer software source code).
4. The Government should consider the following techniques for securing data/software and associated/corresponding license rights:
a. Consider including contract provisions providing for the transfer of a detailed data/software package with the corresponding license rights to the Government if the original contractor goes out of business or drops the particular item from production.
b. Consider including data escrow provisions (see DFARS PGI 227.7203-2(b)(2)(ii)(D)).
5. Describe the Modular Open System Approach (MOSA) objectives that drive modularity decisions to support the operational and lifecycle needs. Describe how IP, and related matters, necessary to support the program’s use of modular open systems approaches, in accordance with 10 U.S.C. Sections §§ 3771-3775 and §§4401 - 4403, will be addressed. This includes providing guidance for how solicitations and contracts will:
a. Identify and require all major systems interfaces to be based on widely supported and consensus-based standards (if available and suitable), which are preferably non-proprietary.
b. Include requirements to acquire the appropriate IP rights in such major systems interfaces.
c. Include appropriate requirements for other non-major systems interfaces (e.g., interfaces necessary for segregation and reintegration activities).
d. Include request for Government Purpose Rights, when appropriate, for Circuit Card Assemblies in support of organic industrial base (OIB) DSOR and DSOS capabilities.
6. Appropriately reflect the IP strategy in both the solicitation and the resultant contract. Contents of both documents should include the IP, data deliverables, and associated license rights necessary to accomplish program objectives.
7. Request that offerors propose their own sustainment transition plan (to transition sustainment from their organization to the Government or another contractor) as an evaluation factor (technical sub factor – Supportability and Maintenance).
8. The Government should only seek the IP, data deliverables, and associated license rights necessary to support the mission of the program. In some instances, where offerors are willing to provide the Government with additional license rights to technical data and software, such additional costs may not be cost effective. Having an evaluation factor in a competitive procurement environment may drive down the associated costs for broader technical data or software license rights.
9. Consult with a Government IP attorney on IP, data deliverables, and associated license rights. Statutes and regulations related to technical data, software, and associated rights are set forth in 10 USC § Chapter 275 (and DFARS 227.7102-1, DFARS 227.7103-1, DFARS 227.7202-1, and DFARS 227.7203-1). The statute and DFARS regulations should be read carefully before procuring any technical data or software. Ensure the Government receives sufficient rights in technical data and software to enable organic or competitively established sustainment of items.
IP Strategy Checklist
| IP Strategy Checklist* | |
| Phases of Acquisition | Key IP Management and Acquisition Activities, Considerations, Resources |
| Pre-Solicitation | 1. Align the initial design studies to the major functional elements 2. Establish a clear understanding of the IP, data deliverables, associated license rights requirements. If it is likely that an Offeror may propose IP that was not developed at private expense, the Contracting Officer should engage with DCAA to determine what assistance can be provided to verify funding source/existing data rights, specific to that requirement. 3. Contracting Officer/Specialist serves as Business Adviser in development of acquisition documentation. 4. PM and Contracting Officer/Specialist conduct market research, including through the Defense Innovation Marketplace 5. Write an IP strategy for the system modules that align with Modular Open Systems Approach (MOSA): Technology developed all/part by USG Funding, get delivery of what you're going to pay for (in native format, if it seems too early or costly to reformat the data for DoD’s usual standard) (Guidance Intellectual Property Strategy - 2015 (IP Strategy Brochure_Final 2-10-15.pdf (dau.edu) and Army Implementation Guidance, Appendix C (requires CAC)) 6. Verify that the strategy includes an approach for the remainder of modules that can be competitively acquired under the Restricted-Proprietary Model: Technology developed entirely at private expense (IP Strategy Brochure 2015 (IP Strategy Brochure_Final 2-10-15.pdf (dau.edu) and Army Implementation Guidance, Appendix C (requires CAC)) 7. Verify the IP strategy accounts for both short-term and long-term needs, covering the full life cycle of the system. 8. Incorporate Modular Open Systems Approach (MOSA) considerations into Acquisition Strategy. |
| Solicitation | 1. The solicitation should clearly and effectively communicate and prioritize IP goals. 2. Be transparent in articulating intellectual property; data deliverables; associated license rights requirements; Government operation, maintenance, installation, and training (OMIT); modernization; and sustainment objectives. 3. The Performance Work Statement (PWS)/Statement of Work (SOW) should identify the license rights and data deliverables (including OMIT data) required and be linked to CDRL(s). The offeror may need to provide costs/prices, if separately priced. a. License Rights and data deliverables (including OMIT data) described under CDRLs should comprise a complete package (or as much as needed) of all technical data and computer software for enabling maintenance of an entire system. 4. Request that the offeror identify restrictions on license rights. 5. Incorporate delivery requirements and require offerors to assert their specific restrictions on license rights. 6. Required data or software must be a deliverable, assigned to a CLIN. 7. Incorporate appropriate provisions and contract clauses. 8. For commercial technologies, request information similar to that required in the DFARS listing and assertion requirements provision (DFARS 252.227-7017) and include CDRL requirements for copies of commercial and negotiated licenses in the solicitation. 9. Request that offerors propose their own sustainment transition plans. Suggestion: Use sustainment transition plans as an evaluation factor. 10. Use the deferred ordering and deferred delivery clauses (but don’t overestimate its power!) Should not be used in place of proper acquisition planning. Acquisition planning for the data deliverables, and incorporate in the solicitation. 11. Consider incorporating statement for trademark license rights in solicitations and contracts *Army Source Selection Supplement, Section H-2.3, Develop the Request for Proposal 12. Consider adding in Section H – Special Contract Requirement language regarding background patent rights. 13. Consider adding in Section H – Special Contract Requirement language regarding Modular Open Systems Approach (MOSA) – including interfaces, patent and data rights, and data deliverables. 14. If the IP strategy includes recompeting a system, subsystem, or component, consider requesting the offeror’s proposed terms and conditions for delivering a Technical Data Package (TDP) that grants rights to the TDP for the system/subsystem/component. Proposal shall clearly outline the terms and conditions, all associated costs, and any minimum quantity (if applicable), in addition to providing the Government with the capability to obtain an IP license from the date of notification of award. Government should be granted sufficient IP rights including technical data rights and background patent rights necessary to allow the Government to compete the design, potentially secure additional sources for the system/subsystem/component, and/or use submitted technical data on any other Government programs. 15. Consider the use of escrow. A data escrow account is an account, held by a third-party or even a prime (provided the prime is not the owner of the data to be placed in escrow), which is populated by the offeror with designated technical data, computer software, and/or computer software documentation (“the escrow data”) and will only be released to the Government under specified, mutually agreed to, conditions. |
| Evaluation | 1. Evaluate IP, data deliverables, license rights, and MOSA in accordance with section M of the solicitation and the source selection plan. Negotiate, as needed, whether sole source or competitive. 2. Evaluate the proposed assertions (as to the restrictions on license rights). 3. With the assistance of a cognizant IP attorney, research to verify IP and data rights assertions made by each offeror. If there is reason to believe an offeror correctly asserted an item was developed exclusively at private expense, audit the offeror’s records with the assistance of the Defense Contracting Audit Agency (DCAA). (NOTE: The Contracting Officer should engage with DCAA as early in the process in the procurement planning process as possible to determine DCAA’s availability to assist.) See DFARS 252.227-7019 or DFARS 252.227-7037 for additional information. 4. Evaluate the offeror’s provided information for commercial technologies (similar to that required in the DFARS listing and assertion requirements provision (DFARS 252.227-7017)). 5. Evaluate offeror’s proposed terms and conditions for delivering a TDP and granting rights to the TDP for the system/subsystem/component, as requested in Section L, in accordance with the evaluation criteria stated in the RFP. 6. Ensure specific up-front delivery requirements for technology being developed under the contract are met; determine if cost-effective/fair and reasonable. 7. Evaluate and negotiate competitively-priced options for IP deliverables for which Army’s “need” for the deliverable is dependent on future uncertain events or decisions – When it is not certain whether an up-front purchase is cost-effective/fair and reasonable 8. Research to determine the cost of same or similar license rights or data deliverables (including data for OMIT). Research and understand any market trends specific to data and license rights that may directly impact cost. (This is typically necessary when license rights are a significant portion of the price and the evaluation will include a cost realism analysis or a complex price reasonableness analysis.) 9. When applicable, in accordance with the stated evaluation criteria in the solicitation: a. Determine whether the software developer/owner is identified. b. Determine whether the offeror wholly owns the rights necessary to make, use, sell, or offer for sale. c. Determine whether there is a third-party software developer/owner. d. Determine whether offeror proposed third-party software is open source software. e. Confirm the offeror will ensure negotiated rights are passed down to subcontractors. f. Determine whether the offeror has the capability and/or willingness to deliver license rights for technical data and computer software necessary for depot level maintenance. g. Confirm whether the offeror’s proposed special licenses meet the solicitation criteria and are reasonable. |
| Negotiations | 1. Early in negotiation process, when competition exists, establish an environment of open communication and negotiations of prices/costs. 2. Consider negotiating license rights and data deliverables (including data for OMIT) required (should be linked to CDRL(s)) and costs/prices, if separately priced. 3. Consider negotiating to ensure a complete package (or as much as needed) of all technical data and computer software for enabling maintenance of an entire system is delivered, when appropriate. 4. Contract Officer should discuss the proposed level of rights and proposed price/cost. 5. Ensure requirements for license rights, and data deliverables – including data for OMIT (developed, delivered, or provided by subs of any tier) are understood and request inclusion of required/desired terms in contracts with subcontractors. |
| Award | 1. Incorporate into contract all asserted license rights restrictions. 1. Incorporate into contract all applicable IP clauses and provisions. 2. Document (within contract) specific up-front delivery requirements for: 1) Technology being developed under the contract (i.e., you’re already paying for it!); and 2) Known requirements for proprietary technology deliverables, when cost-effective/fair and reasonable. 3. Ensure all data deliverables are assigned CLIN(s) and CDRL(s) and are traceable to the PWS/SOW 4. Incorporate proposed product support/sustainment strategy in the final contract. 5. If escrow account is used, ensure it is assigned a priced CLIN(s). |
| Post Award/ Administration | 1. Make sure the award is clear on what will be delivered and delivery date. 2. If there is a patent clause (usually in research and development contracts), ensure the invention disclosures are timely, patent applications are properly filed when appropriate, and the Government’s rights are established. Establish follow-up procedures. 3. Monitor to ensure the deliverable schedule is being met and the data quality is as required. 4. Review the IP strategy as major development milestones are completed. 5. Continuously, assess and update the IP strategy and ensure a life cycle consideration for competition is sustained within the costs of the program’s business objective. 6. Create a Program or PEO Repository to ensure that the data can be retrieved and [re] used when it is needed later (bonus: transfer to, and reuse by, other programs whenever possible). 7. Technical/operational needs are the responsibility of the Government. Do not rely on industry to ensure Government requirements can be competitively replaced. 8. Business/legal needs are the responsibility of the Government program office with support from appropriate contacting office and legal office (e.g., tracking Gov’t investment to support challenging IP restrictions/assertions). 9. Update as necessary any post-award changes to the list of asserted data rights restrictions. 10. Monitor compliance of requirement to report inventions developed during contract performance. 11. Conduct reviews to verify data is delivered and complies with contract requirements: 1) Does the data delivered match the technical/functional requirements identified in the contract; and 2) Asserted data rights markings (Do the markings match up with the list of assertions?). 12. Assess Technical compliance (audit or Independent Verification & Validation). 13. Regularly audit deliverables for Restrictive Markings (recurring) conforming and justified. 14. Invoke withhold payment clause (DFARS 252.227-7030, Technical Data-Withholding of Payment) for non-compliant technical data. 15. Initiate a validation procedure when markings are not justified (i.e., do not accurately describe the Army’s license right) Refer to DFARS 252.227-7019 and 252.227-7037. 16. Follow procedures under DFARS 252.227-7013 and 252.227-7014 when markings are nonconforming (i.e., not a marking prescribed by the DFARS). |
*Adapted from: “Intellectual Property Acquisition and Licensing Checklist” DoD Brochure on Intellectual Property Strategy, Prepared by the Department of Defense Open Systems Architecture—Data Rights Team August 2014
Market Research
Once the Government’s requirements are sufficiently defined, market research in accordance with FAR Part 10, begins and is a coordinated effort by the PM or MATDEVs and the PCO. The market research technique utilized is at the discretion of the acquisition professionals. When conducting market research, consider the critical characteristics and needs of the requirement to include the following with respect to IP, data deliverables, and associated licensing rights:
1. Are there any hardware or software solutions that meet the requirement(s) that were developed using Government funding? If so, what?
2. Does Industry have any input to assist the Government in reaching the Government’s objectives or meeting the Government’s requirement(s)? If so, what?
3. Industry Standards
a. What are the usual terms in commercial transactions for the sale of the product or service you require?
b. Are the license and other intellectual property rights adequate for Government’s needs?
c. Are there any proprietary processes or materials (e.g., trade secrets) that may limit future competition?
d. Do the commercial terms and conditions violate laws or policies applicable to Government contracting?
Note: Rights related to commercial software are governed by the standard commercial software license agreement, rather than any DFARS clauses.
e. Does the Government need/want to negotiate revisions to the standard commercial software license agreement in instances where the commercial software license agreement conflicts with Federal procurement law or does not meet the Government user’s needs?
Note: In some instances, substantial revisions to the standard commercial software license agreement (e.g., additional software copies) may result in additional costs.
4. Technical Data Delivery Format
a. Contractors often do not have technical data in formats that DoD typically expects to receive. The Government should be willing to accept standard commercial data formats, to the maximum extent practicable.
b. Competitive: What are industry standards for technical data deliverable format(s)?
c. Sole Source: What is the contractor’s usual deliverable format for technical data?
5. Technology Maturity
a. How much of the software and/or hardware is mature?
b. How much of the software and/or hardware is still in development or testing?
c. What is the overall Technology Readiness Level (TRL)?
d. Software is typically not delivered 100 percent “bug” free. It may take several years to mature. The logistics product support/sustainment strategy should address software maintenance including “bug” fixes.
6. Support and Sustainment
a. Offerors typically provide software bug fix support, but length of support varies. The Government may consider bug fix support (including cost, length, and scope of such support) during source selection as a trade-off.
Are software bug fixes supported?
If so, how long are they supported?
b. Offerors may provide software upgrades and cybersecurity updates. The Government may consider offeror provided software upgrades (including cost, length, and scope of such support)
Are software upgrades and cybersecurity updates provided at no additional cost?
If so, how long are they provided? What are the terms and conditions?
c. Is there a plan to later modify deliverable hardware, data, or software?
d. Will a data package be required?
e. Will access to support and support-related technical information be obtained, for hardware and software, to cost-effectively maintain the system at each of the designated levels of maintenance and to foster competition for sources of support throughout the life-cycle.
f. Will government purpose rights (GPR) to a Level 3 Technical Data Package enable 3D Modeling for hardware to avoid vendor lock and allow for hardware repairs within the organic industrial base (OIB)?
7. Logistics
a. What is the approximate period of time required to prepare validated procedures addressing software and configuration file loading and to maintain the software baseline?
b. What period of time is required to transition and set-up the necessary tools and test equipment for the Government to conduct maintenance on the software baseline?
c. What is the approximate period of time required to train Government personnel on required hardware testing, troubleshooting, and repair procedures and procedures for maintaining the software baseline?
