DFARSPGI

DFARSPGI

Change Number: DFARS PGI Change 10/30/2023
Effective Date: 10/30/2023

PGI Part 227 - TECHNICAL DATA AND ASSOCIATED RIGHTS

PGI Part 227 - TECHNICAL DATA AND ASSOCIATED RIGHTS

PGI 227.71 - TECHNICAL DATA AND ASSOCIATED RIGHTS

PGI 227.7103 Other than commercial products, commercial services, or commercial processes.

PGI 227.7103-2 Acquisition of technical data.

(b)(1) See DoDI 5010.44, Intellectual Property (IP) Acquisition and Licensing, sections 4.1 and 4.2, when formulating business advice and contract implementation strategies regarding the program manager’s tailoring of technical data requirements to the needs of the Government.

PGI 227.72 - COMPUTER SOFTWARE, COMPUTER SOFTWARE DOCUMENTATION, AND ASSOCIATED RIGHTS

PGI 227.7200 Scope of subpart.

(b) The contracting officer should consider the following additional guidance and information regarding acquisition of computer software and computer software documentation:

(1) DoD Instruction 5000.74, Defense Acquisition of Services.

(2) DoD Instruction 5000.87, Operation of the Software Acquisition Pathway.

(3) DoD Instruction 5010.44, Intellectual Property (IP) Acquisition and Licensing.

PGI 227.7203 Other than commercial computer software and other than commercial computer software documentation.

PGI 227.7203-2 Acquisition of other than commercial computer software and computer software documentation and associated rights.

(b)(1) To the maximum extent practicable, an assessment of life-cycle needs should consider periodic delivery of computer software and computer software documentation including all executable code, source code, associated scripts, build procedures, automation scripts, tools, databases, libraries, test results, data sets, firmware, training materials, and any other elements necessary to integrate, test and evaluate, debug, deploy, and operate the software application in all relevant environments (e.g., development, staging, production). See DoDI 5010.44, Intellectual Property (IP) Acquisition and Licensing, sections 4.1 and 4.2, when formulating business advice and contract implementation strategies regarding the program manager’s tailoring of software requirements to the needs of the Government.

(2)(i) Procurement planning.

(A) Based on the results of the assessment of life-cycle needs, and to the maximum extent practicable, the source code should be accompanied by all software capability descriptions (e.g., features, story points, use cases) and all as-built architecture and design products, traceability products, interface definitions including interfaces to proprietary software elements, and any other requisite documentation.

(B) The assessment of life-cycle needs should consider delivery timelines to facilitate transition to a different contractor or to the Government. This approach facilitates management of program risk and supports options for flexibility in the transition of software sustainment to another organization.

(C) Contracting officers are responsible for ensuring that, wherever practicable, solicitations and contracts include the requirements for periodic delivery and any delivery timelines for computer software and computer software documentation, based upon the assessment of life-cycle needs.

(ii) Alternatives to delivery of source code and related software design details.

(A)(1)In determining whether the Government should require delivery of computer software source code and related software design details developed exclusively or partially at private expense, data managers and other requirements personnel are responsible for considering whether these alternatives permit the Government to—

(ii) Meet its management, engineering, and logistics needs; and

(iii) Maintain the currency of acquired technical data or software consistent with the assessment of life-cycle needs.

(2) To the extent practicable, the Government should also require open interface documentation for any privately developed computer software used in or interoperable with software developed for the Government, to allow for technology insertion on all sides of the interface, as applicable, and to support the use of modular open system approaches.

(B)Access agreements permit the Government to view, print, download, annotate, modify, or make derivatives of technical data or computer software stored within a contractor-controlled repository or facility (e.g., in an online environment or in person). Examples of access arrangements include remote online authorization to access an integrated data environment, product data management system operated by the contractor, or mechanisms authorizing physical entry to a contractor-controlled data repository, or cloud-based or subscription-based software products or services. The negotiated access agreement must stipulate permissions based on the assessment of life-cycle needs, and the access agreement must be made part of the contract.

(C) For each technical data or computer software requirement, the requiring activity must determine whether the Government’s needs can be better satisfied through access or formal delivery of the technical data or software (e.g., physical or electronic transfer of the data into Government custody). The Government should consider access to technical data or software when—

(1) The delivery of technical data or software is not cost-effective or feasible for technical, legal, or contractual reasons; and

(2) Access meets the Government’s needs for such technical data or software throughout the life-cycle of the program.

(D) Under a data escrow agreement, the Government and the contractor identify a third-party escrow agent that will keep designated technical data or computer software for safekeeping until a contractually specified condition occurs. If a contractually specified condition occurs, then the Government may obtain delivery of the escrowed technical data or computer software. The contracting officer shall include the data escrow agreement in the contract. The contract shall also include the Government’s license rights in the escrowed technical data or computer software. Use of data escrow agreements is not preferable in all cases but may be useful when formal delivery or access is not feasible or cost-effective during the contract’s period of performance or delivery schedule.