FOREWORD

Business entities and governments are more cognizant of the value of intellectual property (IP) now than at any time in recorded history. Business entities consider IP their “lifeblood”, which they actively guard and for which they charge a premium. In a similar fashion, the Department of Defense (DoD) considers a certain type of IP—technical data and computer software rights acquired under its contracts—its “lifeblood” because that IP enables the DoD to enhance competition and sustain systems and their subsystems over their life-cycle (e.g., development, production, testing, installation, operation, maintenance, upgrades/modifications, interoperability with other systems, transfer of technologies to other programs/systems/platforms).

This Handbook provides a practical “cradle-to-grave” approach to acquiring IP rights in technical data and computer software. It is an extended treatment of that subject which is briefly discussed in Government Contract Law for Engineers (September 2004) issued by SMC/JA. I want to acknowledge Mr. James H. Haag as the driving force and main contributor to this Handbook. Please submit any suggested improvements or corrections to this handbook to the Contract and Patent Law Division, Office of the Staff Judge Advocate, Space and Missile Systems Center (SMC), Los Angeles AFB, 483 North Aviation Boulevard, El Segundo, CA 90245 or to james.haag@us.af.mil.

The approach described in this Handbook is agnostic, meaning that program offices have used it in development, production, and sustainment contracts to acquire hardware-intensive systems, software-intensive systems, and services. In that regard, Appendix A contains excerpts from a Request for Proposals (RFP) for the acquisition of a hardware-intensive system; Appendix B contains excerpts from an RFP for the acquisition of a software-intensive system; and Appendix C contains excerpts from an RFP for the acquisition of services. Various program offices carefully tailored those excerpts for each acquisition using the disciplined intellectual framework described in this Handbook to account for the specific needs of their particular acquisition.

Each acquisition has its own unique needs for IP rights in technical data and computer software. Unfortunately, a one-size-fits-all-panacea-clause does not exist. If it did, the drafters of the Defense Federal Acquisition Regulation Supplement (DFARS) would have included such a clause into that acquisition regulation the last time (i.e., June 28, 1995) they issued a complete rewrite of the regulations applicable to this topic—or the last time they proposed another complete rewrite of those regulations (i.e., September 27, 2010). It would therefore be inadvisable for the reader to conclude that all that is necessary is to select one of the examples included in Appendices 1-3 and copy it over into their RFP. Instead, this office recommends that readers use the disciplined intellectual framework recommended in this Handbook to carefully tailor one of these examples to satisfy the unique needs of their specific program.

The Office of the Staff Judge Advocate, Space and Missile Systems Center (SMC/JA), issued the first edition of this Handbook in June 2009. Since that time, one commentator has described this Handbook as

“[t]he most detailed guidance that we have found [regarding] how does an agency evaluate the life-cycle cost of limited rights technical data (and restricted rights computer software) when it cannot use the bargaining power of the original competition for the development contact to force the contractor to give up the rights[.]”[1]

Since SMC/JA issued that first edition, the Defense Acquisition Guidebook, the DoD Open Systems Architecture Contract Guidebook for Program Managers, MIL-HDBK-502A (Product Support Analysis), and a Government Accountability Office (GAO) audit report (GAO-11-469) have approvingly cited this Handbook. AFPAM63-128 (Integrated Life Cycle Management) has adopted the recommendations contained in Section V.A. of this Handbook. One Defense Acquisition University on-line training resource (CLM 075) has adopted the techniques described in Section V.C. of this Handbook to train over 1200 acquisition professionals from all military departments and defense agencies. In August 2015, the Assistant Secretary of the Army (Acquisition, Logistics and Technology) adopted a modified form of the approach described in Section V.D.5.g. of this Handbook when she issued the 1st Edition of the Army Data and Data Rights (D&DR) Guide and highly encouraged Program Executive Officers, Program Managers, and their support personnel to use that Guide for all Army ACAT programs. In August 2016, the Aerospace Industries Association (AIA) and the American Bar Association’s (ABA) Section of Public Contract Law cited Section V.D.1.a of this Handbook in letters sent to a Congressionally-chartered Government-Industry Advisory Panel. (The mission of that Panel is to review 10 U.S.C. §§ 2320 and 2321 and their implementing regulations to ensure those requirements are best structured to serve the interests of the taxpayers and the national defense.) A Congressionally-chartered report authored by the Institute for Defense Analyses that reviewed DoD regulations, practices, and sustainment requirements related to Government access to and use of IP rights of private sector firms recently described this Handbook as a “notable example” of an organization that had compiled best practices in order to provide guidance and templates to program offices regarding how to handle this complicated subject. Only time will tell how much further the practical techniques described in this Handbook will spread throughout the DoD.

Due to the size of the appendices to this Handbook, this office has highlighted relevant portions of Appendices 1-3 in yellow in the soft copy so readers can quickly find those excerpts. Readers may wish to print out a double-sided hard copy of this Handbook using a color copier and insert that copy into a three-ring binder, as that approach will facilitate the reader’s ability to find a relevant portion in an appendix the rationale for which this handbook discusses in the narrative portion.

One final observation bears mentioning. The first edition of this Handbook consisted of 151 pages, of which 34 pages consisted of narrative. This edition consists of 561 pages, of which 121 pages are narrative. This increase in the page count is attributable to various factors (e.g., new statutory/regulatory/policy mandates, lessons learned during the intervening years, additional explanations provided in support of recommendations previously provided, new appendices, hyperlinks to relevant resources summarized in the narrative).

But one fact has remained unchanged since this office issued the first edition of this Handbook: The proper acquisition and enforcement of IP rights in technical data and computer software under DoD contracts is one of the most complicated subjects in Federal procurement law. It cannot be understand—much less mastered—by skimming through a few cryptic bullets on a PowerPoint® presentation because, as tartly noted by the Secretary of Defense, “PowerPoint makes us stupid.”[2] If members of the DoD acquisition workforce—irrespective of rank or grade—are unwilling to spend the four hours of time needed to carefully read the narrative provided herein and review the examples provided in the appendices, they may very well learn the lesson the Program Executive Officer (Joint Strike Fighter) has learned: There is no fun to be had when cleaning up the mess left by one’s predecessors relative to the acquisition of the most expensive weapon system ever procured in U.S. history.[3]

Put another way, the pithy comment made by a legend in the spacefaring community over half a century ago remains true today:

“. . . It’s not easy for the Government to determine which bid or proposal we receive from industry is best, and how well competing claims and estimates can be substantiated. In order for us to use the very best judgment possible in spending the taxpayer's money intelligently, we just have to do a certain amount of this research and development work ourselves. We just have to keep our own hands dirty to command the professional respect of the contractor personnel engaged with actual design, shop and testing work.

Otherwise, our own ability to establish standards and to evaluate the proposals—and later the performance—of contractors would not be up to par.

Our Marshall Center engineers operate like doctors[;] i.e., you take the doctor away from his patients, he soon forgets how to practice medicine and starts writing books or publishing trade journals about it.”[4]

This Handbook is not designed to furnish legal advice to specific problems. Readers should neither cite nor rely upon this Handbook as a substitute for legal advice.

YOU ARE ENCOURAGED TO SEEK THE ADVICE OF YOUR PROGRAM ATTORNEY ON SPECIFIC LEGAL PROBLEMS.

KEVIN J. WILKINSON, Colonel, USAF

Staff Judge Advocate

Table of Contents

FOREWORD i

I. Introduction 1

A. Why Be Concerned? 5

B. Fundamental Concepts 9

II. Terminology 11

A. “Technical Data” 11

B. “Computer Software” 12

C. Noncommercial Rights 12

1. Unlimited Rights 12

2. Government Purpose Rights 12

3. Limited Rights 12

4. Restricted Rights 13

5. Specifically Negotiated License Rights (SNLR) 14

6. SBIR IP Rights 14

D. Commercial Rights 15

III. Relevant Constraints 18

IV. Modular Open System Approach (MOSA) 20

A. Definitions 21

B. Relevant Systems Engineering Resources 24

1. Systems Engineering Plan (SEP) 24

2. Work Breakdown Structure (WBS) 26

3. Spare Parts Acquisition Method Code/Acquisition Method Suffix Code (AMC/AMSC) Assignment Codes 27

4. System/Subsystem Specification (SSS) 27

5. System/Subsystem Design Description (SSDD) 28

6. Software Architecture Description (SAD) 28

7. Software Design Description (SDD) 28

C. Results Achieved By Using MOSA 29

V. The “Cradle-to-Grave” Approach 32

A. Drafting The Capability Development Document (CDD) 32

1. IP and IP Rights 33

2. MOSA 35

B. Formulating the Acquisition Strategy 36

1. Subparagraph 7.5.4 38

2. Paragraph 7.6 39

a. Subparagraph 7.6.1 39

b. Subparagraph 7.6.2 41

c. Subparagraph 7.6.3 48

d. Subparagraph 7.6.4 49

e. Subparagraph 7.6.5 50

C. Formulating the Life-Cycle Sustainment Plan (LCSP) 52

1. Paragraph 3 52

2. Subparagraph 3.3.1 54

3. Paragraph 10 54

D. Drafting the Request for Proposals (RFP) 54

1. Exhibit A (Contract Data Requirements List)(CDRL) 55

a. The “acquisition reform” experiment—and its offspring 55

b. The “back-to-basics” approach 58

2. Section B (Supplies Or Services And Prices/Costs) 63

3. Section H (Special Contract Requirements) 65

4. Section I (Contract Clauses) 65

5. Section J (List of Attachments) 66

6. Section K (Representations, Certifications, And Other Statements Of Offerors) 71

7. Section L (Instructions, Conditions, And Notices To Offerors Or Respondents) 71

8. Section M (Evaluation Factors For Award) 74

E. Integrated Data Environments (IDE) 75

1. The Concept 75

2. How To Properly Implement That Concept In An RFP 77

F. Prior to Final RFP Release 83

G. During Source Selection 84

1. General Guidance 85

2. Specific Guidance 85

a. Evaluating the Offeror’s Technical Approach 86

b. Evaluating the Offeror’s Proposed Costs/Prices 91

H. Sole Source Contracts 93

1. Establish Data and IP Rights Requirements 93

2. Understand The Offeror’s Proposed System and Software Architecture 93

3. Justify The Award Of A Sole Source Contract 94

4. Negotiate A Fair And Reasonable Price For The IP Rights To Data 96

I. Milestone B Certification 105

J. Post-Award. 106

1. CDRL Review Upon Delivery 106

2. Use, Release, And Disclosure Of Technical Data And Computer Software 110

3. Identifying And Correcting Improperly Marked CDRLs 111

4. Delivery Of Technical Data/Software Created During Contract Performance That Was .Not Expressly Identified In The Contract 114

5. Correction Of Defective Technical Data Or Computer Software 115

6. Changes In Requirements 115

7. Post-Award Analysis Of IP Rights In Technical Data And Computer Software 115

VI. Epilogue 116

Appendix A: Relevant Excerpts from GPS IIIF RFP A-001

Appendix B: Relevant Excerpts from GPS OCX Phase B RFP B-001

Appendix C: Relevant Excerpts from GPS SE&I Follow-On RFP C-001

I. Introduction

Ultimately, the development and acquisition of IP boils down to one word:

Money.

The reason why is because innovation requires substantial financial investment and effort over a long period, and it uses scarce resources. Where the Government is not subsidizing or outright funding that investment, industry must rely on the IP rights or other resulting competitive advantages as the primary means to make the investment worthwhile. By law, the Government is required to honor any restrictions on its ability to use, release and disclose a corporation’s IP—including technical data and computer software—as reflected by restrictive markings affixed to that IP. Those restrictions exist because the unauthorized or inadvertent disclosure of trade secrets may destroy their commercial value. Although legal remedies for improper disclosure of trade secrets include money damages, injunctions and criminal sanctions, contractual remedies for improper disclosure are often inadequate to preserve the value of the trade secret because it is difficult to prove misappropriation.

Arguably, the proper acquisition of technical data and computer software IP rights by the Government—a hybrid of trade secret law[5] and copyright law[6]—is one of the most complicated subjects in Federal procurement law. This dilemma is not necessarily due to any ambiguities that may exist in regulations. Rather, this dilemma is caused in part by (1) their length and format, and (2) their application to specific acquisitions.

As regards their length and format, the regulations take up 118 single-spaced pages in the DFARS. Moreover, to understand how they work one must read those pages and use them multiple times during contract formation and administration—because the regulations are not laid out in chronological order.

As noted by one commentator in a broader context:“So how does one determine how to best structure a program? Whether you are a PM, or a chief engineer, or a contracting officer, or a life cycle support manager, you have to start in the same place. You begin with a deep understanding of the nature of the product you intend to acquire. The form of the program has to follow the function the program will perform: developing and acquiring a specific product. The nature of the product should be the most significant determiner of program structure.”[7]

In a similar manner, to understand what IP rights in technical data and computer software the program office needs to procure, one must have an intimate familiarity with the weapon system—its requirements, its proposed Work Breakdown Structure (WBS) reflecting its level of system decomposition, the program’s System Engineering Plan (SEP) for that system, the system’s proposed software architecture, how the system will be designed/developed/produced, how its design/performance requirements will be validated and verified, where and under what circumstances it is likely to be deployed, and how it will be maintained/sustained/disposed throughout its life-cycle. IP rights in technical data and computer software are a function of the technical data and computer software the program office seeks to procure, which in turn is a function of the hardware the program office seeks to procure, which in turn is a function of the mission the requirements community seeks to accomplish by placing that weapon system into the warfighter’s hands. In other words, this technical data and computer software is the “technical baseline” for that weapon system.

SMCI62-109 (SMC Configuration Management (CM) Process)(May 24, 2017) states that the primary responsibility of the program manager is to ensure at all times proper configuration control of the program’s “technical baseline” throughout the program’s life-cycle. The breadth of the definition of that term in SMCI62-109 should give any program manager pause, as it encompasses

“[a]ll technical information needed to support a product throughout its life cycle, including product requirements, design, and manufacturing information required to produce, test, accept, package, store, distribute, operate, maintain, modify, and dispose of the product. Examples include: (1) customer/user - program direction, preferences, needs, requirements; (2) configuration baselines (allocated, functional, product), including: requirements, architecture, interfaces, drawings, models, code, data, commercial-off-the-shelf (COTS), open source software (OSS); (3) program specific - performance reports, deficiency reports, aging trends, certification; (4) Supply - vendors, spare parts, DMS; (5) production/maintenance: facilities, training/certification. The Product Configuration Documentation (PCD) documents the PBL and includes detailed design including necessary physical (form, fit, and function) characteristics and selected functional characteristics designated for production, acceptance testing and production test requirements, verifications necessary for accepting product deliveries (first article and acceptance instructions). The PCD must also contain any special tooling, software, equipment and facilities required to manufacture, operate, maintain, calibrate, or inspect items contained in the design, any special packaging parts required to package the CI, any quality assurance provisions required to accept deliveries of the CI (first article or acceptance inspection), any unique process specifications required to manufacture, operate, maintain, or calibrate items contained in the design, and technical data which provides instructions for the installation, operation, maintenance, training, and support of a system or equipment.”

To date, no other DoD organization[8] or private publishing company[9] has issued a publication like this one—a user-friendly resource that provides a detailed “cradle-to-grave” approach to acquiring technical data and computer software IP rights starting from the moment the program office commences drafting the Capability Development Document (CDD), through drafting the Acquisition Strategy, through properly structuring each section of the Request for Proposals (RFP), through competitive or sole-source negotiations prior to award, through delivery of the technical data and computer software to which those IP rights pertain, through validating the contractor’s asserted restrictions on the Government’s ability to use, release, or disclose that technical data and computer software outside the Government. That is the purpose of this Handbook—to put this topic in chronological order so that program office personnel understand what to acquire, when to acquire, and how to acquire IP rights in technical data and computer software.[10] But before discussing the “what”, “when”, and “how” of acquiring IP rights in technical data and computer software—much less describing certain fundamental concepts about those IP rights—one must answer a fundamental question: “Why should program office personnel be concerned about this topic?”

A. Why Be Concerned?

There are five reasons why program office personnel should be concerned about this topic.

First, law, regulation, and policy require that program office personnel be concerned. Permanent legislation[11] requires the DoD acquire certain types of IP rights in technical data under its contracts. DFARS Subparts 227.71 and 227.72 implement this statutory mandate not just for technical data but also for computer software. Memoranda issued by USD(AT&L), the DoD Chief Information Officer, the Secretary of the Air Force, and the Air Force Service Acquisition Executive,[12] as well as various instructions,[13] reflect senior leadership’s concerns regarding this topic. These concerns are primarily based upon the second reason.

Second, acquiring such IP rights has a critical impact on the cost and affordability of technology that a program office cannot treat as a separate or distinct issue it can negotiate apart from contract performance requirements or cost/price. Specifically, if program office personnel do not acquire sufficient IP rights in technical data and computer software prior to award, they may relinquish the opportunity to enhance competition and preserve core logistics capabilities as required by 10 U.S.C. §§ 2464 and 2466. If the Air Force relinquishes that opportunity prior to award, the Air Force will lock itself into a position where the incumbent can force the Air Force to pay an exorbitant price years or decades hence to be able to use, release or disclose that technical data or computer software to individuals outside the Government. Of course, that assumes the incumbent is willing to sell the Air Force a license to use, release or disclose that technical data or computer software to individuals other than Government employees at any price. And once the use of additive (versus subtractive) manufacturing techniques—a process (i.e., vat photopolymerization, material jetting, material extrusion, powder bed fusion, binder jetting, sheet lamination, directed energy deposition) that draws upon a computer-aided design (CAD) file to deposit material, layer upon layer, to construct 3D-printed parts composed of often complex geometries—become more widespread, DoD’s need for IP and sufficient IP rights thereto is likely to increase over time.

As a result, acquisition professionals need to understand the reality summarized in a Congressionally-chartered report published by the Institute for Defense Analyses:

“Long-term business interests influence how defense firms posture themselves on IP data and rights. In formulating their bids for defense weapon systems contracts, potential OEM contractors have increasingly seen that revenues from downstream sustainment and subsequent system upgrades are fundamental to their business. [footnote omitted] Given the long-term value of these contracts, firms bidding on them will often take an “aggressive” approach, in which they will bid low on early contracts with the assumption that they will be able to recoup any loss and reap substantial profits by providing support for the system over many years. [footnote omitted] Therefore, a more aggressive policy to acquire technical data and software rights early in the acquisition process in order to facilitate future competition in sustainment by DOD will likely require a higher payment upfront for development and procurement, since firms will have to risk not gaining future revenues in sustainment. From the acquisition program manager's perspective, this idea is fraught. The long-term savings cannot be guaranteed and the costs for the IP data and rights must be paid now. This is particularly onerous for the PMO when there is heavy pressure on program budgets to execute and deliver desired performance within cost and schedule constraints. The future savings, on the other hand, will accrue in future operations and maintenance budgets, probably long after the acquisition management has moved on.”[14]

Third, the unauthorized use, release or disclosure of such trade secrets is a felony under the Trade Secrets and Economic Espionage Acts. Fourth, the unauthorized use, release or disclosure of such trade secrets can subject the Air Force to paying millions of dollars in damages to the owner of that data or software. In this regard, the Armed Services Board of Contract Appeals (ASBCA) recently ruled that, as part of the implied duty of good faith and fair dealing, in every software license there is an implied obligation on the part of the licensee to use the property in a manner so as to not unnecessarily damage the software’s value to the licensor. Last, but certainly not least, if a program office does not acquire sufficient technical data or computer software and the IP rights thereto, the result could be the loss of a weapon system worth over $100 million—and perhaps the death of personnel that just happened to be using that weapon system at the time it experienced a catastrophic failure.[15]

B. Fundamental Concepts

Before discussing the “what”, “when”, and “how” relative to acquiring IP rights in technical data and computer software, one also needs to understand certain fundamental concepts about those IP “rights.” First, there is a difference between the Government owning the delivered physical medium on which the technical data or computer software resides and the Government’s right to use, release and disclose that technical data or computer software to individuals other than Government employees. The Government may own the medium (e.g., book, compact disc, iPhone®) on which the technical data or computer software resides. The Government might not, however, have acquired sufficient IP rights to use, release or disclose that technical data or computer software to persons that are not Government employees because it has no right to transfer that IP to any contractor. In that case, the Government retains complete ownership of the medium and if the IP can be removed, the Government could transfer the medium to a third party just like the purchaser of a movie on a digital video disc (DVD) could erase the movie and transfer the blank DVD to anyone.

A purchaser of the DVD, however, does not automatically have the right to do anything they want with it (e.g., show the movie to 100 people for a fee). Conversely, the Government could have acquired the IP “rights” to use, release and disclose IP to individuals that are not Government employees but not own the medium (e.g., the Government could have IP rights to technical data being developed at Government expense that has never been delivered to the Government). Under those circumstances, the Government would still have to negotiate with the contractor to have the technical data transferred to the medium and pay for the medium. Thus, in general the Government must consider both the acquisition of the medium (i.e., deliverable) and the acquisition of the IP “rights” to the technical data or computer software residing on that medium.

Second, there is a difference between ownership of the underlying technical data or computer software and a license to the IP “rights” to use, release or disclose that technical data or computer software to third parties. The owner of technical data or computer software has exclusive control over the use, release and disclosure of that IP (including the right to exclude others from using the technical data or computer software). In contrast, a licensee is limited to using that technical data or computer software in accordance with the terms and conditions of the license the owner has granted the licensee.

Therefore, here is the critical point: Under only unique circumstances (e.g., where the technical data the contractor will deliver to the Government is a “special work” such as audiovisual works, musical compositions, investigative reports, and medical records) does the Government acquire title or ownership to technical data or computer software developed under DoD contracts. This fact remains true even if the Government funded 100% of the development of that technical data or computer software. Instead, the Government almost always acquires a license to use, release or disclose that technical data or computer software to persons who are not Government employees, such as employees of Federally Funded Research and Development Centers (FFRDC) (e.g., The Aerospace Corporation, MITRE), a Systems Engineering and Technical Assistance (SETA) contractor, or a Systems Engineering & Integration (SE&I) contractor. That is why, unless assigned to the Government, the contractor typically owns the copyright in the technical data and computer software it developed under a Government contract subject to the Government’s IP rights (and therefore why copyright markings (“©”) are usually affixed to technical data and computer software delivered to the Government). Under those circumstances, the author of an expression of original thought or work can exclude others from copying, performing, displaying or distributing that IP for the life of the copyright. Accordingly, the DoD will be negotiating over IP rights and not ownership in technical data or computer software the contractor will deliver under a contract, and for the reasons stated above it is critical that DoD acquisition professionals understand what IP rights the Government will acquire under that contract.

By way of analogy, every driver’s license contains three critical pieces of information:

  • the name of the person authorized to drive,
  • the type of vehicle that person is authorized to drive (e.g., Commercial Class A, Noncommercial Class A, Commercial Class B, Noncommercial Class B, Commercial Class C, Basic Class C, Motorcycle Class M1, Motorcycle Class M2), and
  • an expiration date (i.e., the period during which that person is authorized to drive that type of vehicle).

In a similar fashion—as stated in this Handbook ever since the 4th edition was issued in August 2011—if a program office has not acquired a broad enough license to use, release or disclose a specific item of technical data or computer software to

  • specific persons or entities, for
  • specifically enumerated purposes, for
  • specified periods of time,[16]

the person who releases those items to other than those specified persons/entities or for unauthorized purposes or outside the period permitted by the license may violate two criminal statutes (18 U.S.C. §§ 1832, 1905). With this concept in mind, one can now turn to discussing the “what” (i.e., the terminology) applicable to this subject.

II. Terminology

Experience demonstrates that the DFARS defines various terms (e.g., “computer software”) more broadly in the context of technical data and computer software IP rights than engineers or computer scientists may have been taught is the case in their undergraduate- or graduate-level computer science courses. The contracting parties may fail to communicate effectively with each other if they use different definitions of the same terms during negotiations prior to award and during contract administration after award. Therefore, understanding the definitions of terms is a prerequisite to properly acquiring and enforcing IP rights in technical data and computer software.

The following discussion summarizes 10 U.S.C. §§ 2305 and 2320-2321, Federal Acquisition Regulation (FAR) Subparts 2.1, 7.1, 9.5, 15.3, 15.4, 46.3, 46.7, DFARS Subparts 207.1, 209.5, 212.1, 212.2, 212.3, 215.4, 227.71, 227.72 and 246.7, DFARS Procedures, Guidance, and Information (PGI) Subparts 207.1 and 217.75, the Small Business Innovative Research (SBIR) Program Policy Directive, and SMC Informational Guidance (IG) Subpart 5315.470. Contracts awarded by civilian agencies (e.g., Governmentwide Agency Contracts (GWAC), General Services Administration (GSA) Federal Supply Schedule (FSS) contracts) contain technical data and computer software clauses required by the FAR that are different from those clauses required by the DFARS. The subject of procuring technical data and computer software via task orders, delivery orders, and Blanket Purchase Agreements issued under GWACs awarded by civilian agencies, FSS contracts awarded by the GSA, Cooperative Research and Development Agreements (CRADA), Technology Investment Agreements (TIA), and Other Transactions (OT), are beyond the scope of this Handbook. For further details, contact SMC/JAQ.

A. “Technical Data”

“Technical data” is defined by DFARS 252.227-7013(a)(15) as recorded information, regardless of the form or method of the recording, of a scientific or technical nature (including computer software documentation), excluding computer software or data incidental to contract administration, such as financial and/or management information. Examples of technical data include, but are not limited to, design review data packages, engineering drawings, specifications, interface control documents (ICD), test plans, test procedures, test reports, assessment reports, technical orders, and operations and maintenance manuals.

B. “Computer Software”

“Computer software” is defined by DFARS 252.227-7013(a)(3) and DFARS 252.227-7014(a)(4) as 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, but excludes computer databases or computer software documentation. This definition does not expressly mention firmware as being a type of computer software. (SMCI62-109 defines firmware as the “combination of a hardware device and computer instructions or computer data that reside as read-only software on the hardware device.”) Nevertheless, the software portion of firmware is encompassed by the broad definition of the term “computer program”, i.e., “a set of instructions, rules, or routines recorded in a form that is capable of causing a computer to perform a specific operation or series of operations.”

C. Noncommercial Rights

A program office may purchase any one of four types of IP rights associated with noncommercial technical data (i.e., Unlimited Rights, Government Purpose Rights, Limited Rights, Specifically Negotiated License Rights (SNLR)) and any one of four types of IP rights associated with noncommercial computer software (i.e., Unlimited Rights, Government Purpose Rights, Restricted Rights, SNLR) under DoD contracts.

1. Unlimited Rights

With respect to noncommercial technical data and computer software, Unlimited Rights means the right to use, release, and disclose within and outside the Government without restrictions (DFARS 252.227-7013(a)(16), DFARS 252.227-7014(a)(16)).

2. Government Purpose Rights

With respect to noncommercial technical data and computer software, Government Purpose Rights means the right to use, release, and disclose within the Government without restriction and the right to release or disclose outside the Government for U.S. Government purposes. (“Government purpose” includes any activity in which the U.S. Government is a party, including competitive procurements and excluding use, release, or disclosure for commercial purposes.) After five years (or some other period negotiated by the parties), the Government’s IP rights in that noncommercial technical data or computer software are automatically upgraded to Unlimited Rights. (DFARS 252.227-7013(a)(13), DFARS 252.227-7014(a)(12)).

3. Limited Rights

With respect to noncommercial technical data, Limited Rights means the right to use, release and disclose within the Government without restriction and the right to release outside the Government only if all of the following conditions are satisfied:

(1) the recipient requires that data to perform emergency repair and overhaul or the release or disclosure will be to a “covered Government support contractor” in performance of its covered Government support contract for use, modification, reproduction, performance, display, release or disclosure to a person authorized to receive limited rights technical data or (other than detailed manufacturing or process data) will be to a foreign government that is in the interest of the U.S. Government to release and is required for evaluation or informational purposes,

(2) the recipient’s contract contains DFARS 252.227-7025, and

(3) the Government notifies the owner of that technical data of that reproduction, release, disclosure or use.

If the Government provides Limited Rights technical data to a recipient for purposes of emergency repair or overhaul, the recipient must destroy that technical data and all copies in its possession promptly following completion of the emergency repair/overhaul. (DFARS 252.227-7013(a)(14)).

4. Restricted Rights

With respect to noncommercial computer software, Restricted Rights means the right to use, copy (solely as a backup) and modify the computer software (generally limited to one computer and not placed upon a shared network) within the Government (if the contractor is notified that that software will be transferred to another government agency) and the right to disclose that software outside the Government as long as:

(1) the recipient is a contractor/subcontractor performing a services contract to use that computer software to diagnose and correct deficiencies in a computer program, to modify computer software to enable a computer program to be combined with, adapted to, or merged with other computer programs or when necessary to respond to urgent tactical situations, the recipient’s contract contains DFARS 252.227-7025 or the recipient has signed the Use and Non-Disclosure Agreement (NDA) found at DFARS 227.7103-7(c); the Government notifies the owner/licensor that a release or disclosure to the recipient was made; the Government prohibits the recipient from decompiling, disassembling, or reverse-engineering the software or using software decompiled, disassembled, or reverse-engineered by the Government; and the recipient uses the computer program with one computer at one time, or

(2) the recipient is a contractor/subcontractor performing emergency repairs or overhaul of items or components procured under this or a related contract to use the software to perform the repairs or overhaul made or to modify that software to reflect the repairs or overhaul made; the recipient is subject to the Use and NDA found at DFARS 227.7103-7(c) or is a Government contractor whose contract contains DFARS 252.227-7025; and the Government prohibits the recipient from decompiling, disassembling or reverse-engineering the software or using software decompiled, disassembled, or reverse-engineered by the Government, or

(3) the recipient is a “covered Government support contractor” performing its covered Government support contract for use, modification, reproduction, performance, display, release or disclosure of that computer software authorized to receive restricted rights computer software provided that the covered Government support contract contains DFARS 252.227-7025 and the Government prohibits the recipient from decompiling, disassembling or reverse engineering the software or using software decompiled, disassembled or reverse engineered by the Government for any other purpose. (DFARS 252.227-7014(a)(15)).

5. Specifically Negotiated License Rights (SNLR)

Specifically Negotiated License Rights means the parties can modify the standard IP rights granted to the Government or obtain IP rights under circumstances where the Government would ordinarily not be entitled to specific rights. The Government cannot release noncommercial technical data or computer software marked with SNLR outside the Government unless

(1) the conditions specified in that license—which the Contracting Officer must include into the contract—have been satisfied,

(2) the recipient’s contract contains DFARS 252.227-7025, and

(3) the recipient has signed the Use and Non-Disclosure Agreement found at DFARS 227.7103-7(c) as modified by DFARS 252.227-7025(b)(3). (DFARS 252.227-7013(b)(4), DFARS 252.227-7014(b)(4)).

6. SBIR IP Rights

SBIR IP rights means the Government acquires Limited Rights in SBIR technical data and Restricted Rights in SBIR computer software during the period commencing with contract award and ending upon the date five years after completion of the project from which that data or software were generated. (DFARS 252.227-7018(a)(19) & (b)(4)). The SBIR Program Policy Directive states the SBIR program is structured in three phases:

  • Phase I: Determines the scientific and technical merit and feasibility of the proposed experimental or theoretical research or research and development (R/R&D) related to agency requirements by a small business awardee prior to providing further Federal support in Phase II. SBIR Phase I awards normally do not exceed $150,000 or six months duration.
  • Phase II: Continues the R/R&D effort from the completed Phase I. Funding is based upon the results of the work performed under a Phase I award and the scientific and technical merit, feasibility, and commercial potential of the Phase II proposal. Only Phase I awardees are eligible for a Phase II award. Phase II contracts cannot exceed $1,500,000 total costs or two years in duration.
  • Phase III: Completes the work that derives from, extends, or completes an effort made under prior SBIR funding agreements, but is funded by sources other than the SBIR program. Phase III work is typically oriented towards commercialization of SBIR research or technology.

The SBIR Program Policy Directive states that, if an SBIR awardee receives a funding agreement—whether competed, sole-source, or subcontract—for work that derives from, extends, or completes efforts made under prior SBIR funding agreements, then the funding agreement for the new work must have all SBIR Phase III status and IP rights. The Directive also emphasizes that a Federal agency may not issue an SBIR award or approve an agreement between an SBIR awardee and a Federal laboratory that violates any SBIR requirement set forth in statute or the Policy Directive, including any SBIR IP rights protections. In other words, the Policy Directive takes precedence over any IP rights granted to the Government under DFARS 252.227-7018 except for those IP rights described in Section V.D.1.b of this Handbook that are based upon 10 U.S.C. § 2320.

In some cases, the Government may accept less than Unlimited Rights or Government Purpose Rights in noncommercial technical data or computer software—but it cannot accept less than Limited Rights in noncommercial technical data or Restricted Rights in noncommercial computer software. Moreover, if the technical data is of a certain type, the contractor may never restrict the Government from releasing or disclosing that technical data outside the Government—and the law restricts the Government from negotiating away its Unlimited Rights to use, release, or disclose that technical data. See Section V.D.1.b of this Handbook for details.

D. Commercial Rights

Before discussing the types of IP rights the Government acquires in commercial technical data or computer software, the reader must first understand the definitions of the terms “commercially available off-the-shelf” (COTS) item, “commercial item”, and “commercial computer software.” Program office personnel must understand these terms and apply them correctly to whatever technical data or computer software they seek to acquire because the types of IP rights the Government acquires in commercial technical data or computer software are different from those IP rights the Government acquires associated with noncommercial items.

FAR 2.101 defines the term “COTS” as any item of supply that (1) is a “commercial item”, (2) is sold in substantial quantities in the commercial marketplace and is offered to the Government without modification in the same form in which it is sold in the commercial marketplace, and (3) does not include bulk cargo (e.g., agricultural products, petroleum products). FAR 2.101 defines the term “commercial item” as any item of a type customarily used by the general public or by non-governmental entities for purposes other than governmental purposes that (1) has been sold, leased or licensed to the general public, (2) has been offered for sale, lease or license to the general public, (3) evolved from that item and will be available in the commercial marketplace in time to satisfy the Government’s delivery requirements, or (4) any item described above but for modifications of a type customarily available in the commercial marketplace or minor modifications not customarily available in the commercial marketplace made to meet federal Government requirements. DFARS 252.227-7014(a)(1) defines the term “commercial computer software” as software developed or regularly used for non-governmental purposes which (1) has been sold, leased or licensed to the public, (2) has been offered for sale, lease or license to the public, (3) will be available for commercial sale, lease or license in time to satisfy the delivery requirements of the contract, or (4) satisfies any of the criteria specified above and would require only minor modifications to meet the requirements of the contract.

Accordingly, when analyzing whether the technical data or computer software the program office seeks to acquire should be accepted with a commercial IP license, the Contracting Officer should use the following decision tree:

  • Does the technical data or computer software satisfy the definition of “COTS”? For example, what quantity of those items has the contractor sold in the commercial marketplace that would constitute a “substantial” quantity? What does “without modification” mean when some items are routinely customized in the commercial marketplace? If so, the program office should then perform the analysis described in Section V.G.2.a.(8) of this Handbook.
  • If not, has another contracting officer issued a commercial item determination (CID) with respect to the technical data or computer software the offeror asserts is a “commercial item” or “commercial computer software”? If the item satisfies the definition of a “commercial item” or “commercial computer software” and the Contracting Officer agrees with the content of that CID, the program office should then perform the analysis described in Section V.G.2.a.(8) of this Handbook.
  • If a CID exists, but the Contracting Officer believes it necessary to deviate from the that CID, can the Contracting Officer document a rationale for a different determination sufficient for the Head of the Contracting Activity (HCA) to overturn that CID?
  • If no CID exists, does the technical data or computer software meet the “of a type” test? For example, are the essential characteristics—i.e., form (physical characteristics), fit (interface), function (essential purpose)—of the hardware to be acquired to which the technical data pertains substantively similar to COTS hardware? Is the primary purpose of the technical data or computer software to be procured a commercial purpose? Will the “of a type” hardware to which the technical data pertains be manufactured on the same production line as the commercial item?
    • If that technical data or computer software satisfies the “of a type” test, has that “of a type” item been customarily used by the general public or by non-governmental entities for purposes other than governmental purposes, and has it been sold, leased, or licensed to the general public or been offered for sale, lease or license to the general public? If so, the program office should perform the analysis described in Section V.G.2.a.(8) of this Handbook.
  • If the technical data or computer software does not meet the “of a type” test, did that technical data or computer software evolve from a “type” of commercial item through advances in technology or performance and that is not available in the commercial marketplace but will be available in the commercial marketplace in time to satisfy the delivery requirements contained in the RFP? For example, is the technical data an updated version of technical data that one can buy in the commercial marketplace—or is the difference between those versions due to some reason other than technology or performance improvements? How far along is the hardware to which the technical data pertains in the development or manufacturing (assembly line established and tested, pieces of equipment remaining to be assembled) process? If this “evolve” test is satisfied, the program office should then perform the analysis described in Section V.G.2.a.(8) of this Handbook.
  • If the technical data or computer software would have satisfied either the “of a type” or the “evolved” test but for
    • Modifications “of a type”: How similar is the modified hardware to which the technical data pertains to other modified technical data sold in the commercial marketplace? Does the offeror perform similar modifications for its commercial customers? Are there differences in the manufacturing processes used to perform the modification for the Federal government and commercial customers to the hardware to which the technical data pertains? If this test is satisfied, the program office should then perform the analysis described in Section V.G.2.a.(8) of this Handbook.
    • Minor modifications of a type not customarily available in the commercial marketplace made to meet Federal Government requirements: Do the modifications to the hardware to which the technical data pertains do not significantly alter the nongovernmental function or essential physical characteristics of that hardware or change the purpose of a process described in that technical data? What is the value and size of the modification and the comparative value and size of the final product? FAR 15.403-1(c)(3)(iii)(B) states that modifications of a commercial item are exempt from the requirement for submission of certified cost or pricing data if the total price of those modifications does not exceed the greater of $2,000,000 or five percent of the total price of the contract. As a result, this standard may serve as a basis for determining whether in this context the proposed modifications to commercial technical data or computer software are “minor”.[17] If this test is satisfied, the program office should then perform the analysis described in Section V.G.2.a.(8) of this Handbook.

As stated above, the types of IP rights the Government acquires in commercial technical data and computer software are different from those IP rights the Government acquires to noncommercial technical data and computer software. Specifically, the Government will have the “unrestricted” right to use, release, or disclose technical data pertaining to commercial items if the technical data was previously provided without restrictions, is form/fit/function data, is a correction or change to technical data furnished to the contractor by the Government, or is necessary for operation, maintenance, installation or training purposes (other than detailed manufacturing or process data). Outside of those situations the Government may not use, release, or disclose that technical data outside of the Government unless (1) that use, release or disclosure is necessary for emergency repair/overhaul of the commercial items procured, (2) it obtains a license from the licensor to do so, or (3) the recipient is a “covered Government support contractor” performing a Government contract where that contract contains DFARS 252.227-7025 and the “covered Government support contractor” has entered into a NDA with that contractor regarding the use of that data (unless the contractor has waived the requirement for an NDA in writing). (DFARS 252.227-7015(b)).

There is no standard clause in the DFARS establishing the Government’s IP rights in commercial computer software, including Open Source Software (OSS). Therefore, DFARS 227.7202-1(a) state that such software must be acquired under licenses customarily provided to the public unless provisions in those licenses are inconsistent with Federal procurement law or do not otherwise satisfy user needs. (Section V.G.2.a.(8) of this Handbook provides specific examples of such provisions that the contracting parties must eliminate in the proposed contract prior to award. Appendix A (Relevant Excerpts from GPS IIIF) of this Handbook (at Attachment 5.h) includes an example of how to eliminate those provisions in the proposed contract.) The Government shall acquire commercial computer software competitively to the maximum extent practicable using firm-fixed-price contracts or firm-fixed-priced orders under available pricing schedules.

III. Relevant Constraints

Apart from the terminology defined above, DoD’s ability to acquire IP rights in technical data and computer software is constrained by statute, regulation and policy. DoD policy is to acquire only that technical data and computer software, and the IP rights thereto, necessary to satisfy agency needs and that is consistent with Federal procurement law. (As we will discuss in detail below, one of your most important challenges is to carefully determine what those “agency needs” are.) Once the program office has identified particular items of technical data or computer software it wants to take physical possession of (regardless of what specific IP rights it may need), solicitations and contracts must then specify the technical data and computer software the program office expects to be delivered. Solicitations and contracts must also establish procedures for determining the acceptability of that technical data and computer software. They must identify separate Contract Line Item Numbers (CLINs) and Exhibits for that technical data and computer software. They must require offerors to price each item separately. They must also require offerors to identify the technical data or computer software they will furnish with restrictions. Finally, they must require contractors to identify technical data and computer software they will deliver with restrictions prior to delivery.

Even if the DoD wants a contractor to deliver technical data or computer software developed exclusively at private expense, 10 U.S.C. § 2320(a)(2)(H) requires that the Secretary of Defense prescribe regulations that prohibit DoD from requiring the offeror, as a condition of being responsive to an RFP or as a condition for award, to sell or otherwise relinquish to the Government any IP rights in technical data related to items, components, or processes developed exclusively at private expense unless the technical data is form/fit/function data, data necessary for operation/maintenance/installation/training (OMIT) purposes (which would include computer software documentation)(other than detailed manufacturing process data), data that constitutes a correction or change to data furnished by the Government, data otherwise publicly available, or data that has been released by the contractor without restrictions. Similarly, the Government shall not prohibit or discourage offerors and contractors from furnishing or offering to furnish items, components, or processes developed exclusively at private expense solely because the Government’s IP rights to use, modify, release, reproduce, perform, display, or disclose technical data pertaining to those items may be restricted.

Regulations also prohibit DoD from requiring offerors, as a condition of being responsive to an RFP or as a condition for award, to sell or otherwise relinquish to the Government any IP rights in noncommercial computer software developed exclusively at private expense except for certain types of computer software specified in DFARS 227.7203-1(c). (Those certain types of computer software include corrections/changes to computer software or computer software documentation furnished to the contractor by the Government, computer software or associated documentation that is otherwise publicly available or has been released or disclosed by the contractor or its subcontractor without restriction on further use, release or disclosure, computer software or associated documentation obtained with Unlimited Rights under another Government contract or as a result of negotiations, or computer software and associated documentation furnished under another Government contract under restrictive conditions that have expired.) Similarly, the Government shall not prohibit or discourage offerors from furnishing or offering to furnish noncommercial computer software developed exclusively at private expense solely because the Government’s IP rights to use, modify, release, reproduce, perform, display or disclose the software may be restricted.

It is permissible, however, for the program office to evaluate the extent to which an offeror proposes to furnish IP rights in technical data and computer software, and use the results of that evaluation during source selections provided if the RFP notifies offerors of that fact. In other words, the Source Selection Authority (SSA) may use the Source Selection Evaluation Board’s (SSEB) evaluation of the offeror’s proposal to furnish a certain level of technical data and computer software IP rights as part of the SSA’s tradeoff analysis to determine which offeror’s proposal provides the “best value” to the Government. However, except for the certain types of technical data identified above, the program office cannot mandate the delivery of technical data or computer software with Government Purpose Rights or Unlimited Rights. Therefore, although the DoD cannot require an offeror to sell or otherwise relinquish to the Government IP rights in technical data or computer software previously developed at private expense except for certain types of technical data and computer software specified above, the law does not prohibit the DoD from negotiating with offerors to purchase those IP rights.

A common misconception is that the Government only acquires IP rights in technical data or computer software if it has funded, in whole or in part, the creation of that data or software. That is not always the case. Under certain circumstances the program office may—and in some cases must—obtain Unlimited Rights even if an offeror or contractor developed the technical data or computer software exclusively at private expense.

The above discussion answers the “why” and “what” questions pertaining to the acquisition of technical data and computer software IP rights. But before one can turn to answering the “when” and “how” questions applicable to this subject, it is necessary to discuss a related systems engineering topic; namely, Modular Open System Approach.

IV. Modular Open System Approach (MOSA)

Over the past two decades, the DoD has become aware that the design of a weapon system’s architecture can significantly enhance the DoD’s ability to achieve agility, rapid capability enhancement, interoperability, increase competition, and lower costs over the life-cycle of the program. To that end, since 2003 DoDD 5000.01 has mandated that acquisition programs shall employ a MOSA approach, where feasible.

Similarly, DoDI 5000.02 Change 3 and AFI63-101/20-201 require program managers to apply a MOSA to design development to the maximum extent feasible and cost effective that results in modular, interoperable systems that allow components to be added, modified, replaced, removed and supported by different vendors throughout each system’s life-cycle, thereby reducing dependency on proprietary data. DoDI 5000.02 Change 3 also states that program managers must allocate cybersecurity and related system security requirements to the system architecture and design by structuring the proposed architecture so as to protect and preserve system functions or resources (e.g., through segmentation, separation, isolation, or partitioning).

More specifically, earlier this year the Commander, Air Force Space Command (AFSPC) issued a memorandum stating that:

“[c]urrent and future space systems must implement the Universal Command and Control Interface (UCI) standard.[[18]] This ensures we are tightening integration across the Space Enterprise and providing strong business case for our industry partners. . . . The UCI extensions for space will be made available within the [UCI] repository upon their completion, NLT December 2018.

* * *

[Accordingly, a]ll AFSPC space systems will include an integrated timeline in the FY21 AFSPC Program Objective Memorandum submission specifying when the system will transition to UCI and how the transition will be funded. . . .”[19]

A. Definitions

Recently, Congress enacted 10 U.S.C. § 2446a, which requires that all ACAT I programs that will receive Milestone A or Milestone B approval shall be designed and developed to the maximum extent practicable with a MOSA to enable incremental development and enhance competition, innovation, and interoperability. That statute defines a MOSA as an integrated business and technical strategy employing a modular design that

  • uses major system interfaces between major system components, or between major system platforms,
  • is subjected to verification to ensure major system interfaces comply with—if available and suitable—widely supported and consensus-based standards,
  • uses a system architecture that allows severable major system components at the appropriate level to be incrementally added, removed, or replaced throughout the life-cycle of a major system platform to afford opportunities for enhanced competition and innovation while yielding (1) significant cost savings or avoidance, (2) schedule reduction, (3) opportunities for technical upgrades, (4) increased interoperability, including system of systems interoperability and mission integration, or (5) other benefits during the sustainment phase of a major weapon system, and
  • complies with the technical data IP rights set forth in 10 U.S.C. § 2320.

10 U.S.C. § 2446a defines a “major system platform” as the highest-level structure of an ACAT I system that is not physically mounted or installed onto a higher-level structure and on which a major system component can be physically mounted or installed. That statute also defines a “major system component” as a

  • high-level subsystem or assembly, including hardware, software, or an integrated assembly of both, that can be mounted or installed on a major system platform through well-defined major system interfaces, and
  • includes a subsystem or assembly that is likely to have additional capability requirements, is likely to change because of evolving technology or threat, is needed for interoperability, facilitates incremental deployment of capabilities, or is expected to be replaced by another major system component.

10 U.S.C. § 2446a also defines a “major system interface” as

  • a shared boundary between a major system platform and a major system component, between major system components, or between major system platforms, defined by various physical, logical, and functional characteristics (e.g., electrical, mechanical, fluidic, optical, radio frequency, data, networking, or software elements), and
  • is characterized clearly in terms of form, function, and the content that flows across the interface in order to enable technological innovation, incremental improvements, integration, and interoperability.

Publications issued by USD(AT&L) use similar terminology to describe the concepts defined in 10 U.S.C. § 2446a. Specifically, the Implementation Directive for Better Buying Power 3.0—Achieving Dominant Capabilities through Technical Excellence and Innovation, Guidelines for Creating and Maintaining a Competitive Environment for Supplies and Services in the Department of Defense, and the DoD Open Systems Architecture Contract Guidebook for Program Managers, state that an open architecture is one that adopts open standards supporting a modular, loosely coupled and highly cohesive system structure that includes publishing of key interfaces within the system and full design disclosure. This architecture is based upon the following five principles:

  • Modular designs based on standards, with loose coupling and high cohesion, that allows for independent acquisition of system components.
  • Enterprise investment strategies, based upon collaboration and trust, that maximize reuse of proven system designs and ensure DoD spends the least to get the best.
  • Aggressively transform life-cycle sustainment strategies for software intensive systems through proven technology insertion and product upgrade techniques.
  • Dramatically lower development risk through transparency of system designs, continuous design disclosure, and Government, academia, and industry peer reviews.
  • Strategic use of IP rights to ensure a level competitive playing field and access to alternative solutions and sources across the life-cycle.

The term “modular” in the first bullet is comprised of two concepts: Module Coupling and Module Cohesion. Module Coupling means that the contractor’s design will result in the creation of software items that have minimal dependencies on other items (loose coupling) to ensure that any changes to one module will not require extensive changes to other modules. Module Cohesion means that the contractor’s design will result in modules each of which feature an identifiable and discrete functionality (high cohesion). The purpose of Module Cohesion is to ensure that all that is necessary to change the performance of the system is to replace a minimum number of software items within the system that feature the increased functionality desired by the customer (“plug-and-play/”plug-and-talk”).

Having described the concept of MOSA, the question then becomes to what extent that concept must be implemented in the CDD, acquisition strategy, and resulting RFP? Before answering that question, however, the program office must first create—or, if they have already been created, carefully review—the seven resources listed below. The reason why will become clearer to the reader after they have finished reading Sections V.A, V.B.2.c., V.D.1, V.D.5.a-b, V.D.7, V.D.8, V.G.2.a.(1), (2), and (7), and—last but not least—V.H.2 of this Handbook.[20]

For the moment, however, it will suffice to say that in some cases IP rights are allocated between the Department of Defense and its industry partners based upon who funded the development of a particular item or component. But unless the program office understands what document memorializes the technical baseline associated with an item or component that was developed exclusively at private expense consistent with MOSA principles, it will be difficult at best for the program office to correctly analyze what level of IP rights it may be able to acquire to that technical baseline—and whether the scope of the license to that technical baseline will suffice to achieve the program’s manufacturing/reproduction/maintenance/sustainment/disposal strategy for each major system component.

B. Relevant Systems Engineering Resources

The purpose of this Handbook is not to provide the reader with a graduate-level understanding of systems engineering documentation as they apply to a MOSA. Nevertheless, due to the statutory mandate in 10 U.S.C. § 2446a described above, it is critical that the reader of this Handbook have a basic familiarity with various resources so the reader will understand how they relate to the proper acquisition of IP and IP rights under DoD contracts. Accordingly, the following discussion of seven resources is necessarily brief. The first five resources apply to all weapons systems; the last two resources apply only to software-intensive systems. The program office will create the first three resources; the contractor will create the last four resources. These seven resources are:

1. Systems Engineering Plan (SEP)

DoDI 5000.02 Change 3 requires that program managers for all ACAT programs prepare a SEP as a management tool to guide the systems engineering activities on the program. The SEP must be submitted for approval for each milestone review. DoDI 5000.02 Change 3 states that at each milestone and at the development RFP release decision point, the SEP will support the acquisition strategy, including the program interdependencies, and communicate the overall technical approach to balance system performance, life-cycle cost, and risk in addressing warfighter needs. Amongst other things, DoDI 5000.02 Change 3 states that the SEP will document “interface requirements and interface products to track interdependent touch points.”

To that end, the program manager must discuss the applicability of MOSA principles to their major system platform using DASD(SE)’s Systems Engineering Plan (SEP) Outline Version 3.0 (May 12, 2017) as supplemented by SMC’s Systems Engineering Plan (SEP) Development Guide (SMC-G-011)(January 18, 2017). In particular, paragraph 2.1 (Architecture and Interface Control) of DASD(SE)’s SEP Outline requires that the program office list the architecture products that will be developed (including system-level physical and software architectures and Department of Defense Architecture Framework (DODAF) architectures). The expectation is that

“Architectures are generated to better describe and understand the system and how the subsystems join together, to include internal and external interfaces, to form the system. Plans to develop architecture products to support requirements and specification development are understood.”

SMC-G-011 elaborates on that expectation as follows:

“Identify system dependencies with other space and ground systems. Describe how the system architecture view are aligned to the Space Superiority Enterprise Architecture (SSEA) and Supports the Space Enterprise Vision (SEV).

Include a list of architecture products/views in support of Capability Documents IAW JCIDS Manual, and those that are required in support of Information Support Plan IAW JITC Interoperability Process Guide.

Include system security components of the system physical and/or functional architecture diagrams (delineating system security physical and/or functional interfaces), if available. Identify any systems security dependencies with other space and/or ground systems and/or systems security enterprise services.”

Likewise, paragraph 4.3 (Configuration and Change Management) of DASD(SE)’s SEP Outline requires that the program office will list and describe the planned or established technical baseline artifacts upon approval of various design reviews; i.e.,

  • System Functional Review = Functional Baseline = Artifacts containing the system’s performance (functional, interoperability, and interface characteristics) and the verification required to demonstrate the achievement of those specified characteristics.
  • Preliminary Design Review = Allocated Baseline = Artifacts containing the functional and interface characteristics for all system elements (allocated and derived from the higher-level product structure hierarchy) and the verification required to demonstrate achievement of those specified characteristics.
  • Critical Design Review = Initial Product Baseline = Artifacts containing necessary physical (form, fit, and function) characteristics and selected functional characteristics designated for production acceptance testing and production test requirements, including “build-to” specifications for hardware (product, process, material specifications, engineering drawings, and other related data) and software (software module design – “code-to” specifications).

The expectation is that

“Programs should understand which artifacts make up each technical baseline and manage changes appropriately. At completion of the system-level Critical Design Review, the Program Manager will assume control of the initial product baseline, to the extent that the competitive environment permits (DoDI 5000.02, Enclosure 3, Para.8, page 84). Exceptions are explained.”

That paragraph of DASD(SE)’s SEP Outline also states that the program’s SEP must describe the program’s process for maintaining configuration management and control of its baselines. With respect to the program’s configuration change process, the SEP must, amongst other things, “[d]escribe how the Intellectual Property Strategy affects and influences the planned configuration control processes.” The expectation is that

“Program controls the baselines.”

Finally, paragraph 4.4 (Design Considerations) of DASD(SE)’s SEP Outline requires that the program office include a table that identifies six different design considerations key to the achievement of the program’s technical requirements. The description shall include the name of the design consideration, the cognizant program management organization, certification requirements, the documentation that memorializes that design consideration, how those documents are included into the contract (e.g., “CDRL #”), and a description of how the program office will address that design consideration. One of those design descriptions the table requires program offices provide is a description of

“how a modular open systems approach (MOSA) [is] used in the system’s design to enable affordable change, evolutionary acquisition, and interoperability. Provide rationale if it is not feasible or cost-effective to apply MOSA.”

2. Work Breakdown Structure (WBS)

MIL-STD-881D (Department of Defense Standard Practice: Work Breakdown Structures for Defense Materiel Items)(April 9, 2018)( http://quicksearch.dla.mil/qsDocDetails.aspx?ident_number=36026) states that the foundation for a WBS is DoDD 5000.1 and DoDI 5000.02. According to MIL-STD-881D, the purpose of a WBS is to define the logical relationship among all program elements (e.g., hardware, software, services, data, facilities) to a specific level of indenture that does not constrain the contractor’s ability to define or manage the program and resources. (The contractor should then extend all other elements to the level and form based upon the way the system is developed, produced, or managed.) A secondary goal is to provide a systematic and standardized method for gathering cost data so that both the Government and the contractor can track the cost to develop and produce a specific item or component that resides within a specific level of the WBS so that work progress is documented as resources are allocated and expended.

Amongst other things, the WBS segregates a defense materiel item into its component parts, clarifies the relationship among the parts, and clarifies the relationship of the tasks to be completed both to each other and to the end item (weapon system). In other words, the WBS is an organized method to break down a product into sub-products at lower levels of detail (e.g., Level 1 = Space System, Level 2 = Space Vehicle 1, Level 3 = Bus, Level 4 = Bus Flight Software, Level 5 = a Computer Software Configuration Item (CSCI). When appropriately structured and used in conjunction with systems engineering principles, cost estimating, Earned Value Management (EVM), integrated scheduling, and risk management, the WBS allows for program status to be continuously visible so the program manager and the contractor can identify, coordinate, and implement changes necessary for desired results. Since the WBS evolves during the Engineering and Manufacturing Development (EMD) phase of a program, by the end of that phase, the WBS is defined at its lowest levels, which best represents the entire system.

3. Spare Parts Acquisition Method Code/Acquisition Method Suffix Code (AMC/AMSC) Assignment Codes

DFARS PGI 217.7506 describes the Department of Defense’s spare parts breakout program. That program includes procedures for screening and coding parts in order to provide contracting officers with summary information regarding technical data and sources of supply to meet the Government’s minimum requirements. An AMC is a single digit numeric code assigned by a DoD activity to describe to the contracting officer and other Government personnel the results of a technical review of a part and its suitability for breakout. An AMCS is a single digit alpha code assigned by a DoD activity that provides the contracting officer and other Government personnel with engineering, manufacturing, and technical information.

In brief, the assignment of those codes assists the contracting officer in selecting the method of contracting (competitive, sole-source), identifying sources of supply (e.g., knowledge of manufacturing sources, additional operations performed after manufacture of parts possessing safety or other critical characteristics), and the availability of technical data (i.e., the adequacy of the technical data package for that spare part and the Government’s IP rights to use that technical data for acquisition purposes). As it relates to the topics discussed in this Handbook, Section 3-303.2 (Data Evaluation Phase) of DFARS PGI 217.7506 provides a 13-step process for determining the adequacy of that technical data, and Section 3-303.3 (Data Completion Phase) provides a six-step process for determining the adequacy of the IP rights retained by the contractor to that technical data.

4. System/Subsystem Specification (SSS)

One Contract Data Requirements List (CDRL) the program office can use to implement MOSA is an SSS. This deliverable must identify all characteristics of the system that are conditions for its acceptance by the Government. It must be divided into subparagraphs to itemize the requirements associated with each capability of the system, identify all states and modes, and specify required behavior of the system and applicable parameters. It must also specify the requirements (if any) for, and characteristics, of the system’s external interfaces, and identify internal interface requirements. Furthermore, it must identify requirements for internal data, adaptation, safety, security and privacy, environmental, computer resources, quality factors, design and construction constraints, personnel, training, logistics, packaging, precedence and criticality, qualification methods, and (for subsystem-level specifications) traceability to the system requirements it addresses.

5. System/Subsystem Design Description (SSDD)

A second CDRL the program office can use to implement MOSA is an SSDD. This deliverable contains a full identification of the system and the software residing therein. It includes decisions about the system’s behavioral design and other decisions affecting the selection and design of system components. For example, it identifies inputs the system will accept and outputs it will produce including interfaces with other systems/configuration items/users, system behavior in response to each input or condition, how system databases/data files will appear to the user, selected approach to meeting safety/security/privacy requirements, physical size/color/shape/mass/materials/markings, selected approach to providing requiring flexibility/availability/maintainability). It also identifies the components of the system, their relationship to each other (including a diagram that identifies and shows the relationships among the planned specifications for the system components, their purpose, and the system requirements and system-wide design decisions allocated to them). And it includes the concept of execution among the components showing the dynamic relationship of the components with each other, and the interface characteristics between the components and with external entities (e.g., systems, configuration items, users).

6. Software Architecture Description (SAD)

SMCI63-104 (Software Acquisition Instruction)(May 26, 2009) states that one of the 17 CDRLs all programs must acquire from contractors developing and delivering software-intensive systems to SMC is a SAD. SMC Standard SMC-S-012 (Software Development)(January 16, 2015)(http://everyspec.com/USAF/USAF-SMC/SMC-S-012_16JAN2015_52130/) states that a SAD documents the software architecture, including the approach, important design decisions, rationale and tradeoffs. It provides diagrams and text to document the various architectural views from different perspectives and serves as the basis for the detailed design. Amongst other things, the content of this CDRL must describe how and where the architecture of the system—and of each software item (SI) residing within that system—supports MOSA principles.

7. Software Design Description (SDD)

A fourth CDRL referenced in SMCI63-104 is an SDD. This deliverable describes the Computer Software Configuration Items (CSCI)-wide design decisions, the CSCI architectural design, and the detailed design needed to implement the software. It contains both technical data and computer software. Amongst other things, the content of this CDRL must identify all software units that comprise a software item (SI)) that in turn comprise a CSCI, identify the purpose of each software unit, its development status/type, planned utilization of hardware resources, concept of execution, and its detailed design. It also describes the concept of execution among the software units, and the interface characteristics between those software units and with external entities (e.g., systems, configuration items, users). The difference between the SDD and the SAD is that the former is written to the lowest level of indenture of the WBS; i.e., whereas the SDD decomposes the software architecture down to the software unit level, the SAD does not.

C. Results Achieved By Using MOSA

If program office personnel understand what these seven documents say about the systems’ architecture, they will then have a common understanding of the technical baseline and the system’s decomposition down to the lowest practicable level that can be used for their specific needs: systems engineering, cost estimating, scheduling, EVM, IP, logistics, etc. With respect to IP, armed with these six resources the program office can then determine what IP rights the Government can—if not should—acquire to the technical baseline that describes a specific major system component in order to foster competition and reduce the total life-cycle cost of the major system platform. As a result, the primary deliverables the Government would acquire from a contractor whose contract required the major system platform to be developed using MOSA principles are:

  • A contractor WBS that is based upon the program’s WBS,
  • SSSs,
  • SSDDs,
  • For software-intensive systems, a SAD and a SDD, and
  • Major system interfaces between each major system component and between each major system component and the major system platform that is comprised of major system components to the appropriate level of indenture in the WBS consistent with the program’s minimum needs (e.g., its maintenance philosophy, its SEP).

Since the benefits of that technical baseline to both the DoD and the defense

industry are not intuitive, we offer the following explanation for the reader’s consideration. First, as stated in the AFSPC memorandum referenced above,

“[o]pen, common messaging standards enable machine-to-machine communication, rapid system integration, and increased interoperability[; attributes that] are critical . . . to meet current and future warfighter needs.”[21]

In other words, major system platforms developed using MOSA principles deployed in a multi-domain environment can more easily share data with each other since data transmission/reception is based upon common major system interfaces between those platforms and between major system components residing within those platforms—thereby increasing the efficiency and effectiveness of military operations.

Second, the Government would not necessarily need to acquire Government Purpose Rights to detailed manufacturing process data for the hardware or the source code residing within the major system component identified in the major system platform’s WBS/SSDD/SAD/SDD. Instead, consistent with 10 U.S.C. § 2320, the Government would only need to acquire Government Purpose Rights to the deliverables listed above in order to use, release or disclose those items to sources other than the original equipment manufacturer (OEM). The Government’s disclosure of that technical baseline to alternate sources will foster competition at the major system component (in the case of software, software item or software unit) level thereby precluding “vendor lock” by encouraging those sources to develop, maintain and sustain components featuring equivalent or improved functionality as the component(s) the Government seeks to replace.

The reason why is because those alternate sources will retain the right to restrict the Government’s ability to use, release, or disclose detailed manufacturing process data for the hardware or the source code residing within the major system component identified in the major system platform’s WBS/SSDD/SAD/SDD to competitors in the same manner that the OEM retained the right to restrict the Government’s ability to use, release, or disclose detailed manufacturing process data for the hardware or the source code residing within the major system component identified in the major system platform’s WBS/SSDD/SAD/SDD the OEM created to those alternate sources. Ultimately, both the OEM and the alternate sources—the OEM’s competitors—will be incentivized to develop, maintain and sustain equivalent or improved functionality major-system-component-by-major-system-component at a cheaper price.

Of course, the Government would still need to acquire at minimum, e.g., Restricted Rights to computer software—in this case, source code—residing within, the major system component developed by either the OEM or an alternate source so the program office can complete the risk management framework process mandated by DoDI 8510.01 (Risk Management Framework (RMF) for DoD Information Technology)(July 28, 2017). The reason why is because, as stated in DoDI 5000.02 Change 3, undiscovered weaknesses or flaws in system elements containing software or microelectronics, including spares, can provide the foundation for threat actors to defeat fielded systems through cyber-attacks. As a result, it is imperative that the Department be able to identify and eliminate those weaknesses and flaws discovered (1) before it places the major system platform into the warfighter’s hands, and (2) after the system is fielded.

Third, the defense industry accrues cost savings, thereby increasing its return on Independent Research & Development (IR&D) investment. By way of background, DoDI 5000.01 states that contractors shall not be encouraged nor required to invest their profit dollars or IR&D funds to subsidize defense research and development contracts (except in unusual situations where there is a reasonable expectation of a potential commercial application). That regulation also states that contractors are entitled to earn reasonable rewards on DoD contracts, including competitively awarded contracts.

As stated above, major system interfaces define common form, function, and content of the data that flows across the interface between major system components. So instead of having to develop a unique component for each major system platform that features similar (if not identical) functionality, a contractor could instead develop a single common component that can be installed into multiple platforms. The reason why is because that component can interface with a higher-level subsystem or assembly using a major system interface common to each of those platforms.

In other words, a contractor deciding whether to invest its profit dollars or IR&D funds in developing a major system component could reasonably base its Return On Investment (ROI) analysis upon the expectation it will reuse that component in multiple major system platforms. When spread over the total amount the contractor budgeted to develop that component, the resulting quantity increase would translate into a lower projected unit cost than if that component could only be installed in a single platform. Since lower unit costs translate into greater sales, the contractor’s profit margin should increase.

In order to properly incorporate MOSA principles into the major system platform the program office seeks to acquire, the program office must address MOSA in the CDD, the acquisition strategy, and the RFP. And the program office must analyze the extent to which offerors propose a MOSA during source selection—especially the means offerors intend to use to satisfy MOSA principles after award. For ease of understanding, implementation of this concept at each of those stages is discussed at the appropriate locations in the text that follows consistent with the statutory mandates that now apply to each of those documents.

We emphasize, however, that an essential condition precedent to the successful implementation of MOSA is that systems engineers, product support managers, logisticians, contracting officers, and program attorneys not only need to talk to each other earlier than may have occurred in the past—they also need to have a basic understanding of the tools and lexicon used by their colleagues’ respective professions to perform their respective jobs. The reason why is because systems engineers need to take into consideration what major system components logisticians and product support managers believe would be appropriate to repair or replace consistent with the program’s maintenance philosophy, thereby ensuring that the resulting contract requires the awardee to create components featuring minimal dependencies on other components (Module Coupling) and that that functionality is confined to a specific component (Module Cohesion). Likewise, it is now incumbent upon contracting officers and program attorneys to understand the major system platform’s WBS, SSSs, SSDDs, SAD, and SDDs.

Put another way, those communities must agree with each other regarding the expected content of SSSs, SSDDs, and what major system interfaces the contract will require the contractor to create that will define the interfaces between major system components, between a major system platform and its major system components, and between major system platforms, to be repaired/replaced at the appropriate level of indenture in the WBS consistent with the program’s minimum needs as reflected in, e.g., its maintenance philosophy, its SEP. As a consequence, during development and production, the contractor will decompose the major system platform to identify where the functionality to be provided by a specific major system component will reside in the system’s architecture—the results of which will be found in the contractor’s WBS, SSSs, SSDDs and for software-intensive systems, its SAD and SDDs.

In conclusion, no better way to summarize the preceding discussion can be found than that contained in the Defense Acquisition Guidebook:

  • Successful implementation of MOSA “should be analyzed at each design review because there is a link between MOSA and the level and type of technical data, computer software, and IP rights thereto, the Government needs for life-cycle support.”
  • “Successful implementation of MOSA design principles requires the synchronized acquisition of [IP] rights for modular open systems and interfacing architecture elements.”

V. The “Cradle-to-Grave” Approach

Having answered the “why” and “what” questions pertaining to the acquisition of technical data and computer software IP rights—and having taken a temporary detour to discuss MOSA principles and related programmatic documentation—the following pages answer the “when” and “how” questions by describing a cradle-to-grave approach to acquiring sufficient IP rights in technical data and computer software to permit the program office to successfully execute a program. This approach begins with the program office’s formulation of the CDD, through drafting the acquisition strategy, through drafting provisions of the RFP, through competitive or sole-source negotiations, through the ultimate use, release and disclosure of those deliverables to non-Government employees after award of the resulting contract.

A. Drafting The Capability Development Document (CDD)

10 U.S.C. § 131 establishes a Joint Requirements Oversight Council (JROC) in the DoD. The JROC assists the Chairman of the Joint Chiefs of Staff (CJCS) in assessing joint military capabilities and identifying/approving/prioritizing gaps in such capabilities, reviewing/validating whether a capability fulfills a gap in joint military capabilities, developing recommendations for program cost and fielding targets, establishing/approving joint performance requirements that ensure interoperability between and among joint military capabilities and are necessary to fulfill capability gaps, reviewing performance requirements for existing/proposed capability that the CJCS determine should be reviewed by the JROC, identifying new joint military capabilities based on advances in technology or concepts of operation, and identifying alternatives to any acquisition program that meets approved joint military capability requirements.

According to Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 5123.01H (Charter of the Joint Requirements Oversight Council (JROC) and Implementation of the Joint Capabilities Integration and Development System (JCIDS))(August 31, 2018), the Manual for the Operation of the Joint Capabilities Integration and Development Systems (JCIDS) (August 31, 2018) provides procedures for the operation of JCIDS, the development and staffing of capability requirements documents at all classification levels for both deliberate and urgent/emergent capability requirements, and outlines the mandated Requirements Management Certification Training (RMCT) program for personnel participating in JCIDS. The JCIDS Manual states that it provides procedural guidance for the JCIDS as the primary means for the JROC to fulfill its responsibilities to the CJCS as required by 10 U.S.C. § 181. To that end, that publication identifies the required format and content of CDDs. It also states that the original CDD may remain valid through production unless there is a significant change that would require an update to the original validated CDD—in which case a CDD Update will be required and validated by the same validation authority of the original document.

1. IP and IP Rights

The JCIDS Manual states that sustainment planning early during design and procurement enables the requirements and acquisition communities to provide a system with optimal availability and reliability to the warfighter at an affordable life-cycle cost. Accordingly, the JCIDS Manual requires that all CDDs contain a Sustainment Key Performance Parameter (KPP) consisting of two mandatory components (Materiel Availability, Operational Availability) and three mandatory attributes (Reliability, Maintainability, Operations and Support (O&S) Cost).

Neither that publication nor AFI10-601 (Operational Capability Requirements Development)(November 6, 2013), however, requires that those critical documents identify what technical data and computer software and their associated IP rights the program office must acquire to successfully execute the program from development through disposal. That fact is surprising given that acquisition of technical data and computer software (and their associated IP rights) can be a critical factor in reducing the program’s total life-cycle cost. Fortunately, however, AFPAM63-128 (Integrated Life Cycle Management)(July 10, 2014) Table 11.1 now summarizes the concepts discussed below.

Although there are different ways of analyzing what IP rights the program office should acquire, as explained below, it all starts with the program office describing what critical technical data or computer software the contractor must delivered to the program office (e.g., technical baseline artifacts identified in paragraphs 4.3 and 4.4 of the program’s SEP that are summarized in Section 7 (Joint Interoperability) of the CDD). Next, the program office must describe, consistent with 10 U.S.C. §§ 2320-2321, which specific persons or entities will need to use those critical items for which specific purposes (e.g., depot level maintenance, follow-on competitive acquisitions) for specified periods in order to identify what IP rights need to be acquired for those deliverables. Ideally, the program manager should be able to summarize the results of this analysis in no more than a paragraph of text in the CDD—clearly identified in the table of contents under the heading “Intellectual Property (IP) and IP Rights”—that identifies those items and their associated license rights. That paragraph should also explain why the requirements community needs those items and their associated IP rights to enable the system’s materiel and operational availability.

We have identified five reasons why it is imperative that this summary of the Government’s needs for critical technical data or computer software and the IP rights thereto be included in CDDs. First, AFI63-101/20-101 states that all acquisition programs will coordinate the requirements document (e.g., Systems Requirements Document) used in conjunction with an RFP with the requiring Lead Command prior to the release of the final RFP and directs the reader’s attention to MIL-HDBK-520 for additional information on preparation of requirements documents. In turn, MIL-HDBK-520A (Systems Requirements Document Guidance)(December 19, 2011) indicates that requirements documents must specify technical data and computer software requirements. Thus, inclusion of those requirements into the CDD will increase consistency between the RFP and the CDD insofar as identification of critical technical data and computer software and associated IP rights are concerned.

Second, AFI63-101/20-101 states that the Commander, Air Force Space Command, will, along with the Service Acquisition Executive (SAF/AQ), certify to the SECAF that the requirements as described in the CDD for ACAT I, ACAT IA and non-delegated ACAT II space programs can, amongst other things, be translated for evaluation in a source selection in a clear and ambiguous way. That instruction also requires that source selections consider Government IP rights to data. Accordingly, inclusion of requirements for the acquisition of technical data and computer software (and their associated IP rights) into the CDD will ensure that, once the RFP is finalized, the latter mandate can be executed consistent with the former mandate.

Third, the Competition In Contracting Act (CICA) requires that the program office demonstrate that the requirements it ultimately included in a RFP are reasonably necessary for the Air Force to meet its minimum needs. In theory, a bid protester can challenge any requirement as unduly restrictive of competition. If, however, the CDD contains the information described above, it is likely that a bid protest forum (e.g., GAO, U.S. Court of Federal Claims (COFC), U.S. Court of Appeals for the Federal Circuit (CAFC)) will give the determination made by the Vice Chairman of the Joint Chiefs of Staff in the CDD regarding what IP rights in technical data and computer software needed to accomplish the mission great weight—especially if the reasonable explanation for needing that technical data and computer software and their associated IP rights is included into the CDD.

Fourth, if the requirements community includes its summary of its minimum needs and their rationale into the CDD, any successor program manager will find it difficult to relax those requirements after the Government has awarded the contract. Situations where a relaxation of requirements might be contemplated would include the program manager erroneously assuming that that relaxation will reduce the total life-cycle cost of the program or the contractor experiencing “seller’s remorse” (described in Section V.J.1 below) with respect to the IP rights it agreed prior to award to deliver to the program office after award. The reason why is because that program manager will be unable to relax those contract requirements unless and until those requirements are deleted from the CDD by the Vice Chairman of the Joint Chiefs of Staff. In other words, including those requirements in the CDD puts the program manager in a strong position to resist pressure originating from any source to relax them.

Finally, the Government can maximize the materiel and operational availability of that system by requiring the contractor to deliver critical technical data and computer software needed to maintain that system within an area of operation overseas by either government personnel or support services contractors, and the associated IP rights needed to provide those items to those personnel or contractors. If, however, the Government never required the delivery of those critical items or failed to acquire the appropriate IP rights to use, release and disclose those items to those government personnel or contractors, when that system breaks down, the user will have no choice but to ship it back to the OEM in the United States. The user must then wait the weeks (if not months) it will take that manufacturer to repair that system and return it to that area of operation.

2. MOSA

10 U.S.C. § 2446b requires that CDDs must identify and characterize the extent to which requirements for system performance are likely to evolve during the life-cycle of the system because of evolving technology, threat, or interoperability needs, and for requirements that are expected to evolve, the minimum acceptable capability that is necessary for initial operating capability of the ACAT I program. This mandate is now implemented in the JCIDS Manual.

Specifically, the JCIDS Manual states that Section 4 (Program Summary) of the CDD shall briefly describe whether the system being designed plans to use a MOSA including integration of capabilities developed within the system and/or plan for evolution of capabilities that will be added, removed, or replaced in future increments. In a similar manner, Section 7 (Joint Interoperability) of the CDD must specify how the individual system will interoperate within the joint environment and enhance innovation such as the use of MOSA to support future incremental development. Any information on MOSA provided in that section should be consistent with Section 4 of the CDD and the program manager’s acquisition strategy. To that end, Section 7 of the CDD must briefly describe any considerations that may affect a future system or subsystem’s interoperability with the base system (e.g., inclusion of system interfaces that support one or many consumer/producer systems and are compliant with consensus-based standards).

Given the effective date of the JCIDS Manual (November 29, 2018), no program’s CDD has yet had to comply with this mandate. Accordingly, we offer the following suggestions for the reader’s consideration. Section 4 of the CDD should first summarize the major system platform’s sustainment strategy as reflected in its proposed acquisition strategy. That section should then state what major system components located at what level of indenture of the major system platform’s WBS that feature what capability will be added, removed, or replaced in future increments consistent with that major system platform’s sustainment strategy. Then consistent with the major system platform’s SEP, Section 7 of the CDD should identify the artifacts that will comprise the technical baseline for those components—including the major system interfaces between major system components, between those components and the platform, and between platforms.

B. Formulating the Acquisition Strategy

10 U.S.C. § 2431a states that the Milestone Decision Authority (MDA) shall review and approve, as appropriate, the acquisition strategy for an ACAT I/II program at each of the following events:

  • Milestone A approval
  • The decision to release the RFP for development of the program or system
  • Milestone B approval
  • Each subsequent milestone
  • Review of any decision to enter full-rate production
  • When there has been a critical change to the cost of the program or system, a significant change to the cost, schedule, or performance of the program or system, or at any other time considered relevant by the MDA

That statute also states that acquisition strategies for ACAT I/II programs shall consider the IP strategy in accordance with 10 U.S.C. § 2320.

To that end, DoDI 5000.02 Change 3 states that every acquisition strategy must address how program management will create and sustain a competitive environment throughout the program’s life-cycle. With respect to IP rights, that regulation requires program management establish and maintain an IP strategy to identify and manage the full spectrum of IP and related issues (e.g., technical data and computer software deliverables, patented technologies, and appropriate IP rights) from the inception of a program and throughout the life-cycle. (In this regard, DoDI 5000.02 Change 3 states that a life-cycle affordability analysis should nominally cover 30-40 years into the future. Of course, certain weapons systems in DoD’s inventory (e.g., B-52, U-2, CVN-68) have been in operational use longer than 40 years.)

The IP Strategy must describe, at a minimum, how program management will assess program needs for, and acquire competitively whenever possible, the IP deliverables and associated IP rights necessary for competitive and affordable acquisition and sustainment over the entire product life-cycle, including by integrating, for all systems, the IP planning elements required by DFARS 207.106 (S-70) for ACAT I and II programs and subsystems thereof. (That subsection of the DFARS requires that acquisition strategies assess the long-term technical data and software needs for those programs and subsystems prior to issuing an RFP for that system or subsystem, address the merits of including a priced option for the future delivery of technical data, computer software and associated IP rights that were not acquired upon initial contract award, and address the potential for changes in the sustainment plan over the life-cycle of that system or subsystem.) The program manager must update the IP Strategy throughout the entire product life-cycle, summarize it in the acquisition strategy, and present that document along with the LCSP during the Operations and Support Phase.

Along the same lines, AFI63-101/20-101 states that the IP Strategy describing the acquisition of technical data and associated IP rights for the system’s total life-cycle sustainment must be addressed and documented at Acquisition Strategy Panels, reviews, and in associated data planning documents. Specifically, AFI63-101/20-101 states that IP rights requirements and corresponding acquisition strategies must ensure they provide for IP rights or delivery of data the Government requires for systems sustainment and to maintain competition throughout the life-cycle (e.g., organic source of repair and/or supply decisions, Government Core depot maintenance capability requirements, expeditionary logistics footprint requirements, engineering data requirements needed for Operational Safety, Suitability, and Effectiveness (OSS&E) assurance, integrity programs, sustaining engineering, reliability management and configuration management, technical orders, reprocurement/modification/upgrade, demilitarization/disposal, MOSA, cybersecurity strategies, technology refreshment or enhancement, training and training program information, spare parts procurement, testing and evaluation, intelligence mission data production, contractor logistics support, supply chain management, depot-level reparable and consumables procurement, support equipment procurement and maintenance, special tools/tooling, diminishing manufacturing sources and material shortages). Conversely, the MDA must approve the business case analysis justifying the decision not to acquire licenses or associated IP rights necessary for organic support. The program manager must also ensure that the program acquires computer software as executable code and source code unless the MDA documents and approves the rationale for not doing so.

For services acquisitions, DoDI 5000.74 Change 1 states that acquisition strategies for those acquisitions will provide appropriate mechanisms to identify and manage intellectual property issues to allow industry a fair and reasonable ROI while avoiding vendor lock, and enable the competitive and cost-effective transition to follow-on service providers. Where competition is determined not to be feasible or practical, acquisition strategies and plans will incorporate processes to generate improved performance or cost savings with the sole source vendor, such as incentives and performance metrics.

For business systems—i.e., information systems operated by, for, or on behalf of the DoD (e.g., financial systems, financial data feeder systems, contracting systems, logistics systems, planning and budgeting systems, installation management systems, human resources management systems, and training systems) that are not national security systems or information systems used exclusively by and within the defense commissary system or the exchange system or other instrumentality of the DoD conducted for the morale, welfare, and recreation of members of the armed forces using non-appropriated funds—DoDI 5000.75 states that the tailored acquisition strategy shall include a description of the program approach to leverage competition to acquire the required capability at reduced cost and risk. As a result, the approach for acquiring those business systems must describe the business strategy that includes an IP Strategy.

Before the program office begins to implement those statutory and regulatory mandates by drafting the acquisition strategy for a specific program, however, all personnel who will be assigned to the resulting source selection or sole-source acquisition who will evaluate an offeror’s proposal relative to technical data and computer software IP rights should first read DFARS Subparts 227.71 and 227.72 and the related clauses for themselves so they will possess an intimate familiarity with pertinent terminology. (A copy of the DFARS is available on-line at http://www.acq.osd.mil/dpap/dars/dfarspgi/current/index.html.). Next, those personnel should address the topics discussed below.

You may notice that some of these topics relate to how the program office should structure various sections of the RFP. The reason why these topics are discussed in this section is because DoDI 5000.02 Change 3 requires that at the Development RFP Release Decision Point, the program manager will summarize the Technology Maturation and Risk Reduction (TMRR) Phase progress and results, and review the acquisition strategy for the EMD phase. As a result, program offices seeking approval of their acquisition strategy should commence drafting that document at the same time they are drafting their RFP.

The current template program offices must use when drafting their acquisition strategy is PDUSD(AT&L)’s Technology Development Strategy/Acquisition Strategy (TDS/AS) Sample Outline (April 20, 2011). That Sample Outline includes two paragraphs relevant to the acquisition of IP and IP rights under DoD contracts: Subparagraph 7.5.4 and paragraph 7.6. The following text describes what information the program office should insert into those parts of its acquisition strategy—and what analysis the program office will need to perform to complete that task.

1. Subparagraph 7.5.4

This subparagraph of the program’s acquisition strategy must identify the source selection approach (e.g., tradeoff, lowest price technically acceptable) and briefly summarize planned procedures (assuming, of course, that the program office will not be acquiring supplies and services sole-source) the program office intends to use to select the winning offeror. Accordingly, it should summarize the notional evaluation factors and subfactors (and their relative weight) the program office intends to include into Section M of the RFP.

AFI63-101/20-101 requires that source selections consider Government IP rights to data. Therefore, this subparagraph of the program’s acquisition strategy must summarize what evaluation criteria the program office intends to insert into the appropriate Technical subfactor of Section M of the RFP relative to IP and IP rights the program office seeks to procure for that acquisition’s life-cycle. It should also explain how the Government will evaluate the offeror’s proposed prices for IP rights in technical data and computer software the offeror proposes to deliver to the Government after award.

2. Paragraph 7.6

This paragraph of the program’s acquisition strategy must summarize the IP strategy for meeting product life-cycle IP rights requirements and to support the overall competition strategy by discussing the following topics.

a. Subparagraph 7.6.1

This subparagraph of the program’s acquisition strategy must include an analysis of the data required to design, manufacture and sustain the system as well as to support re-competition for production, sustainment, or upgrade and consider baseline documentation data, analysis data, cost data, test data, results of reviews, engineering data, drawings, models, and Bills of Materials.

To comply with this mandate, the acquisition strategy must:

(1). In accordance with DFARS 207.106(S-70), identify the long-term technical data, computer software, and contract administration information needs of the program to achieve the program’s objectives (and identify those objectives) and how those needs were assessed. It should consider the needs of the entire life-cycle, including potential competition/re-competition for procurement of the system, subsystems, components, and logistics support (including spare and repair parts), e.g., the potential for changes in the sustainment plan over the life-cycle of the weapon system or subsystem. Put another way, the program office should assume that the OEM will not maintain or sustain the system.

To complete this task, the acquisition strategy must identify what deliverables (Contract Data Requirements List (CDRLs)) will be included into the RFP and why those deliverables are needed. The most efficient way to do so is to initiate the data call required by DoD 5010.12-M. The purpose of that data call is to solicit answers from systems and software engineers, logisticians, cost analysts, and requirements personnel internal and external to the program office to the following questions based upon the unique nature of the supplies or services being acquired and how those supplies or services will be used by, e.g., the warfighter. To that end, the program office should obtain answers to the following questions:

(a). What critical technical data and computer software—if any—does the CDD/CPD require the program office to acquire from the contractor? Although not all CDDs or CPDs may contain such requirements, the program office should not assume that those documents omit mention of that topic. Those requirements may be buried on some obscure page, the existence of which is not explicitly stated in the table of contents underneath a heading (e.g., “Software Engineering”) that does not contain helpful terminology like “technical data and computer software.” Accordingly, the program office must carefully scrutinize each page of the CDD or CPD for those requirements.

(b). Based upon its review of the program’s SEP, WBS, spare parts AMC/AMSC assignment codes (if already issued), SSDD, SAD, and SDD, what technical data that describes the technical baseline for each major system component, the major system interfaces between major system components, between the major system platform and its major system components, and between that platform and other major system platforms, will the program office need for the total life-cycle of the program?

(c). What data (including technical data and computer software) will the program office need to acquire to develop and produce the weapon system? For example, consistent with SMCI63-104, systems and software engineers will recommend acquiring deliverables like engineering change proposals, SSSs, SSDDs, WBSs, design review data packages, test plans, test procedures, test reports, software development plans, software product specifications, SADs, SDDs, system safety program plans, environmental analysis data reports, and Integrated Program Management Reports (IPMR). As indicated by the Defense Acquisition Guidebook, they will also recommend acquiring all requirements tools and data sets, all test software and supporting information necessary to build and execute the tests, all other software test tools such as interface simulators and test data analyzers (whether custom developed or not), and all information for defects remaining in the software upon delivery to the Government. Consistent with 10 U.S.C. § 2322a, that data should include all noncommercial computer software and related materials necessary to reproduce, build, or recompile the software from original source code and required libraries; to conduct required computer software testing; and to deploy working computer software system binary files on relevant system hardware. That software must be delivered in a usable, digital format; not rely on external or additional software code or data (unless such software code or data is included in the items to be delivered); and in the case of negotiated terms that do not allow for the inclusion of dependent software code or data, include sufficient documentation to support maintenance and understanding of interfaces and software revision history. Cost analysts will recommend acquiring Cost Data Summary Reports (CDSR), Functional Cost-Hour Reports (FCHR), Progress Curve Reports (PCR), Sustainment Functional Cost-Hour Reports (SFCHR), Contractor Business Data Reports (CBDR), Software Development Reports (SDR), Software Maintenance Reports (SMR), and Enterprise Resource Planning (ERP) Software Development Reports (ERP-SDR).

(d). What technical data and computer software will the program office need to maintain, sustain, and dispose of the weapon system? For example, logisticians will recommend acquiring ICDs, technical orders, training manuals, and product drawings/models and associated lists.

Based upon the answers to these questions, the program office should include a comprehensive list of proposed CDRLs into this subparagraph of the acquisition strategy.

(2). As required by FAR 7.105(b)(2)(iii) and (b)(14)(iii), identify the estimated cost of those CDRLs and their delivery schedules.

(3). Describe how the program office will store, manage, and review those CDRLs for technical accuracy and completeness—and who (e.g., the program’s Engineering Data Manager) will be responsible for ensuring those activities are performed.

b. Subparagraph 7.6.2

This subparagraph of the program’s acquisition strategy must explain how the program will provide for IP rights and delivery of technical data the program office requires for the system’s total life-cycle sustainment (e.g., material management, training, cybersecurity, cataloging, open architecture, configuration management, engineering, technology refreshment, maintenance/repair within the technical order (TO) limits and specifically engineered outside of TO limits, reliability management).

To address this mandate, the acquisition strategy must:

(1). Identify the IP rights the program office will acquire to the CDRLs described in subparagraph 7.6.1 of the acquisition strategy—and why those IP rights are needed. For example, it should address the potential for changes in the sustainment plan over the life-cycle of the weapon system or subsystem. Put another way, the program office should acquire sufficient rights so it will not need the OEM to maintain or sustain the system. To do so, the program office should address the following issues:

(a). The program office must procure those rights the Government is required to acquire by 10 U.S.C. § 2320, DFARS Subparts 227.71 and 227.72, DoDI 5000.02 Change 3, AFI63-101/20-101, and SMCI63-104. Section V.D.1.b below provides further details regarding the rights 10 U.S.C. § 2320, DFARS Subparts 227.71 and 227.72 require the Government to procure. The IP rights the other resources cited in the preceding sentence require the program office to procure are discussed in the following paragraphs.

(b). To comply with DoDI 5000.02 Change 3/AFI63-101 for hardware-/software-intensive systems, DoDI 5000.74 Change 1 for services acquisitions, and DoDI 5000.75 for business systems, the program office must take into consideration the unique nature of the goods or services it seeks to acquire—and thus what IP and IP rights are needed to sustain the system and its subsystems over their life-cycle (e.g., development, production, testing, installation, operation, maintenance, upgrade/modification, interoperability with other systems, transfer of technologies to other programs/systems/platforms). In order to make this determination, the program office must analyze to whom does the program office want to release or disclose specific items of technical data and computer software (i.e., CDRLs) listed in paragraph 7.6.1 of its draft acquisition strategy, for what purposes, and for what specified period.

For example, does the weapon system’s maintenance/sustainment philosophy as reflected in the system’s LCSP—as summarized in Subsections 7.4.1 and 7.4.2 of the acquisition strategy for that system—state the program office plans to competitively procure additional quantities of the system, spare parts, or future system upgrades/modifications, or that services contractors will perform organic sustainment of the system? (Subsection 7.4.1 of the Sample Outline states the acquisition strategy must specify the contracting strategy to provide product support throughout the system life-cycle (e.g., the maintenance or support Concept of Operations (CONOPS), impacts to system capability requirements, responsiveness of the integrated supply chains across government and industry, maintaining long-term competitive pressures on government and industry providers, providing effective integration of weapon system support that is transparent to the warfighter and provides total combat logistics capability). Subsection 7.4.2 of that Outline states the acquisition strategy must state the assumptions used in determining whether contractor or agency support will be employed both initially and over the life of the acquisition, including consideration of contractor or agency maintenance and servicing, support for contracts to be performed in a designated operational are or supporting a diplomatic or consular mission, and distribution of commercial items.) Does the LCSP state the Government will compete on-orbit anomaly resolution of bus flight software? Or is the current producer unable to satisfy surge requirements? If so, the program office should acquire Government Purpose Rights to that technical data or computer software.

In contrast, does the program office want to use, release or disclose that technical data to only Government employees for organic sustainment? In the alternative, does the program office need that technical data to perform only emergency repair and overhaul (as opposed to routine repair and overhaul) of the system? If so, the program office should acquire Limited Rights.

Do contractors performing services (not supply) contracts need that computer software to diagnose and correct deficiencies in a computer program or to modify computer software to enable a computer program to be combined with, adapted to, or merged with other computer programs or when necessary to respond to urgent (as opposed to routine) tactical situations if additional restrictions are satisfied? Or do contractors need that computer software to perform only emergency—as opposed to routine—repairs or overhaul of items or components thereof to use that software when necessary to perform the repairs or overhaul or modify the software to reflect the repairs or overhaul if additional restrictions are satisfied? If either is the case, the program office should acquire Restricted Rights.

Does the program office want to modify the standard IP rights granted to the Government, need additional IP rights in technical data or computer software acquired with Government Purpose, Limited or Restricted Rights, or does the program office want to obtain IP rights in technical data or computer software in which it does not have IP rights? If so, it will need to acquire a Specifically Negotiated License.

(c). The program office must attempt to procure the IP rights required by the program’s CDD. Although not all CDDs may contain such requirements, the program office should not assume that those documents omit mention of that topic. As suggested above, those requirements may be buried on some obscure page, the existence of which is not explicitly stated in the table of contents underneath a heading (e.g., “Software Engineering”) that does not contain helpful terminology like “IP Rights.” Accordingly, the program office must carefully scrutinize each page of the CDD for those requirements.

(d). The program office must ultimately structure RFP provisions in a manner that will make it extremely difficult for a contractor to change the basis of the parties’ bargain after award. By way of explanation, DFARS clauses in the contract permit the contractor to assert after award additional use, release or disclosure restrictions when those restrictions are based upon “new information” or “inadvertent omissions” “unless the inadvertent omissions would have materially affected the source selection decision.” If the program office structured the RFP in the manner recommended in Section V.D. below, it will be difficult for a contractor to make those assertions after award. The reason why is that the program office will be able prove the negative: It will be able to point to contemporaneous records proving that, had the program office known of those additional restrictions prior to award, those omissions would have materially affected the source selection decision. (Those records would include, but not be limited to, the offeror’s initial proposal, EZSource findings, the Initial Evaluation Briefing, the Competitive Range Decision Document, Evaluation Notices (ENs), the awardee’s responses to those ENs, videotaped discussion sessions, the Pre-Final Proposal Revisions (FPR) Request Briefing, the awardee’s FPR, the SSEB Report, the Final Decision Briefing, the Source Selection Advisory Council’s Comparative Analysis Report and Award Recommendation, and the Source Selection Decision Document that supported the award of the contract in question.) Conversely, if the program office fails to carefully structure the RFP in that manner, the contractor can (and may) drive the proverbial truck through this exception.

(e). The provisions the program office ultimately includes in the RFP must be unambiguous and therefore enforceable. To that end, the program office must ensure that those provisions precisely identify what specific CDRLs the Government may use, release or disclose to which specific persons/entities who are not Government employees, for which specific purposes, and for which specific period—otherwise known as “mapping” various licenses to applicable CDRLs. The reason why is because if the program office does not “map” licenses to specific CDRLs in the RFP, the program office will have difficulty analyzing whether the proposed licenses satisfy its minimum needs prior to award. Moreover, for the reasons discussed below, if licenses are not “mapped” to specific CDRLs in the resulting contract the program office will find it virtually impossible to successfully complete that “mapping” exercise after contract award.

(f). The program could experience adverse consequences if the program office uses some novel approach to acquire technical data and computer software IP rights for an ACAT I program (i.e., any program that will require an eventual total expenditure for RTD&E of more than $365 million in FY00 constant dollars or more than $2.19 billion in FY00 constant dollars of procurement appropriations). It is therefore preferable for a program office to include provisions in the RFP that have been battle-tested in a program of similar magnitude. For example, when considering that program of similar magnitude, the evidence demonstrates that those provisions minimized if not eliminated disagreements between the parties during contract administration. That is not to say, however, that a “one-size-fits-all” approach is appropriate. Each program has unique characteristics that the program office must take into consideration when it is formulating its acquisition strategy and the resulting RFP.

(g). DoDI 5000.02 Change 3 states that a program manager will ensure ergonomics, human factors engineering, and cognitive engineering are employed during systems engineering over the life of the program to provide for effective human-machine interfaces and to meet human systems integration requirements. That publication also states that systems designs will minimize or eliminate system characteristics that require excessive cognitive, physical, or sensory skills, entail extensive training or workload-intensive tasks, result in mission-critical errors, or produce safety or health hazards.

We submit this principle applies equally to structuring IP rights provisions in RFPs. For decades, some program offices and their contractors have repeatedly violated this fundamental principle of systems engineering by including cumbersome and confusing IP rights provisions into RFPs and contracts—when they should have instead included provisions that are as user-friendly as an Apple iPhone® used by a teenager (or an AK-47 wielded by (regrettably) a child soldier). In other words, when drafting those provisions the program office should consider the following “human [IP rights] integration” requirements:

(i). They must be structured to permit the SSEB to quickly identify potential licensing problems associated with a specific CDRL contained in an offeror’s proposal.

(ii). They must take into consideration the program office’s personnel constraints (i.e., the lack of specialized training provided to program office personnel on this subject). In other words, upon receipt of a CDRL deliverable after award, a Second Lieutenant or a support services contractor employee should be able to compare the restrictive marking to the contract requirements and provide their assessment to the Contracting Officer regarding whether the marking is consistent with contract requirements within 10 seconds. In contrast, a program office violates a fundamental principle of error-free design when it awards a contract which establishes numerous types of SNLR, each of which grant 20+ categories of entities/personnel (“communities of interest”) differing levels of use, release, or disclosure IP rights to vaguely-identified items of technical data or computer software that are not expressly “mapped” to specific CDRL deliverables: “Simplify where you can, and build in constraints to block errors.”[22] If the program office violates this fundamental principle, the resulting contract will obscure what IP rights the Government actually acquired and thus exponentially increase the risk of unauthorized releases of trade secrets. Similarly, licensing approaches that make it impossible for program attorneys to figure out what IP rights were acquired for any item of technical data or computer software (i.e., CDRL)—unless a great deal of technical assistance is provided by program office engineers—are a waste of resources. In short, the program office should baseline all contents of a specific CDRL to a single level of IP rights to the maximum extent practicable in the RFP.

(iii). They must not require audit assistance to resolve disputes between the contractor and the program office regarding what IP rights the program office acquired under a particular contract. By way of background, except as indicated below, DFARS 227.7103-5 and 227.720-3-5 state that the level of IP rights the Government acquires depends upon the source of the funding used to develop the noncommercial technical data or computer software in question (otherwise known as the “doctrine of segregability”). This “source of funding” test means that the Government acquires

  • Unlimited Rights to noncommercial technical data pertaining to an item, component, or process or computer software that has been or will be developed exclusively with Government funds,
  • Government Purpose Rights to noncommercial technical data pertaining to an item, component, or process or computer software developed with mixed funding,
  • Limited Rights to noncommercial technical data pertaining to an item, component, or process developed exclusively at private expense, and
  • Restricted Rights to noncommercial computer software developed exclusively at private expense.

DFARS 227.7103-4(b) permit “segregation” in a contractor’s accounting system of the cost to develop technical data pertaining to items, components or processes to any practicable sub-item or sub-component level of the WBS, or any segregable portion of a process. For computer software, DFARS 227.7203-4(b) states that “segregation” would apply to a software item that performs a specific function. Therefore, if the program office merely includes the standard DFARS clauses into the contract and a dispute arises between the parties after award regarding what type of IP rights the Government acquired to a particular item, component or process, or a software item that performs a specific function, the program office will need to request audit assistance.

During the audit, the auditor will need to analyze the extent to which the contractor (1) developed an accounting system capable of tracking the allocation of private and government funds to the developmental work accomplished with those funds, (2) identified technologies that offered long-term competitive advantages worthy of the initial investment to develop them, and (3) broke or separated the accounting trail for development of those technologies to indirect cost pools (e.g., IR&D, costs not allocated to a government contract, or any combination thereof. If the contractor properly implemented these steps, the contractor can demonstrate that it developed a particular item, component or process (or all items, components or processes) described in a particular CDRL exclusively at private expense.[23] The program office would have to obtain an estimate from the auditor regarding when the program office should expect to receive that incurred cost audit report. Only upon receipt of that audit report might the program office receive a nasty surprise: The contractor’s position is unassailable—and therefore the program office will not receive the IP rights in technical data and computer software it assumed would be the case.

Complicating the matter further would be if the audit report concluded that the contractor developed some noncommercial items, components or processes described in that CDRL exclusively at private expense (e.g., IR&D), it developed other noncommercial items, components or processes with both contractor and Government funding (“mixed funding”), and it developed yet other noncommercial items, components or processes exclusively with Government funds. Accordingly, differing levels of IP rights would apply to various portions of a particular CDRL—which means that only certain individuals could see certain portions of that CDRL. (That situation would violate the pragmatic rule described above: To the maximum extent practicable, the program office should ensure that all content of a specific CDRL is governed by a single level of license rights.) In contrast, if the program office uses the framework discussed below, the issue of the source of funding used to develop a particular item, component or process becomes completely irrelevant. The reason why is because all that matters is the content of the license(s) (otherwise known as SNLR) attached to the contract which the parties agreed prior to award would apply to that specific CDRL.

One final point bears mentioning before leaving this discussion regarding the doctrine of segregability. The reader may have noticed the preceding discussion omits any reference to obtaining audit assistance from the Defense Contract Audit Agency (DCAA). The reason why is because that agency’s Contract Audit Manual states that, although its auditors can verify that the amount claimed by the contractor as the cost of developing the proposed technical data, and can evaluate information regarding sales of the technical data to other parties if those sales have occurred, the auditor cannot determine if the costs incurred under a claimed project or account relate only to the proposed data. Nor can the auditor determine if there were other costs related to the data that were incurred under additional projects or accounts, or be reasonably certain regarding whether any specific contract required development of some or all of the proposed data. As a result, the auditor will be unable to render an informed opinion regarding the reasonableness of the contractor’s proposed price for IP rights.

(h). If feasible, the program office should include provisions in the RFP that obtain an express waiver from the contractor for “covered Government support contractors” to enter into any NDAs between the contractor and the program office’s “covered Government support contractor” relating to any Limited/Restricted Rights noncommercial technical data or computer software and commercial technical data and computer software the contractor will deliver under the resulting contract. If that is not feasible, those provisions should ensure that any NDA does not impose impermissible terms and conditions upon those “covered Government support contractors.” (A “covered Government support contractor” is a contractor (other than a litigation support contractor covered by DFARS 252.204-7014) under a contract the primary purpose of which is to furnish independent and impartial advice or technical assistance directly to the Government in support of the Government’s management and oversight of a program or effort, so long as the contractor is not affiliated with the prime contractor, a first-tier subcontractor on the program or effort, or any direct competitor of that prime contractor or any first-tier subcontractor, and receives access to technical data or computer software for performance of a Government contract that includes DFARS 252.227-7025.)

For example, NDAs should not prescribe the use of terms (i.e., restrictive markings) on technical data or computer software CDRL deliverables sent from the contractor to the program office’s “covered Government support contractors” that are different from those terms described above. Moreover, they should not require the transfer of technical data and computer software directly from the contractor to the program office’s “covered Government support contractors.” The reason why is because if they do, those NDAs may erode the program office’s control of the program since it takes the program office “out-of-the-loop” because the program office is no longer the sole conduit of that technical data and computer software between that contractor and its support services contractor—potentially resulting in the adverse consequences described above. Furthermore, they should not be so restrictive as to prevent that “covered Government support contractor” from warning other programs about systemic problems of which it is aware associated with the contractor’s performance (of the subject contract) that might arise on those other programs—such text might violate FAR 52.203-19 (Prohibition on Requiring Certain Internal Confidentiality Agreements or Statements).

After the program office has used the criteria described above, it should summarize in subparagraph 7.6.2 of its acquisition strategy the level(s) of rights it believes it must acquire to the CDRLs listed in subparagraph 7.6.1 along with the logic it used to select the level(s) of rights it did and the alternative solutions considered.

(2). List or summarize the DFARS clauses that will be included into the resulting contract(s) (including the Deferred Ordering and Deferred Delivery clauses).

(3). As required by FAR 7.105(b)(14)(iii), identify the estimated cost of the IP rights to those CDRLs.

(4). Describe the overall approach to managing data the program office will acquire with less than unlimited rights and how data deliverables will be reviewed for unjustified or nonconforming markings.

(5). Describe the process the program will follow to question or challenge contractor assertions or markings, and the approach for maintaining the software and its related documentation once software maintenance is transferred from the OEM (including contract provisions that will allow for a cost-effective migration).

(6). Describe the use of withholding or incentives specific to performance in the area of data management (e.g., heavily-weighted award fee plan subjective evaluation criteria to incentivize the contractor to deliver CDRLs with conforming and justified restrictive markings, withholding payment of up to 10% of the total contract price if technical data is not delivered in a timely manner or is deficient upon delivery).

(7). Describe how the use of an Integrated Data Environment (IDE) (see Section V.E below) factors into the IP Strategy, any required interfaces to government data systems or repositories, how those requirements will be satisfied, and the digital format standards to be used and why they were selected.

c. Subparagraph 7.6.3

This subparagraph of the program’s acquisition strategy must include a business case analysis calculation, conducted in concert with the engineering tradeoff analysis, which outlines the approach for using MOSA and acquiring technical data IP rights. This calculation must analyze alternative acquisition decisions to provide evidence that justifies an investment decision to implement (or not implement) an MOSA or acquiring (or not acquiring) rights in technical data and computer software for the program. It must take into consideration the contractor’s economic interest in technical data and computer software pertaining to items, components or processes that potential offerors have developed at private expense. It must also consider the Government’s costs to acquire, maintain, store, retrieve and protect the data, as well as procurement needs, repair/maintenance/overhaul philosophies, spare/repair part considerations, and whether procurement of the items, components or processes can be accomplished on a form, fit or function basis.

As best as can be determined—given the lack of detailed guidance that exists on this topic—this analysis consists of four parts:

(1). Using the program’s SEP, WBS, SAD, SDD, and spare parts AMC/AMSC assignment codes, decompose the major system platform down to its major system components consistent with the reference design concept for that platform the program office has identified in Figure 2 (Sample Drawing of the Reference Design Concept) of Section 2.6 of its acquisition strategy as required by the Sample Outline. (That figure must depict major subsystems and features (one or more drawings as needed) to describe or illustrate the expected features of the product.) Then, as required by 10 U.S.C. § 2446b, to the maximum extent practicable,

  • clearly describe the MOSA to be used for the program,
  • differentiate between the major system platform and major system components being developed under the program, as well as major system components developed outside the program that will be integrated into the ACAT I program,
  • clearly describe the evolution of major system components the program office anticipates will be added, removed, or replaced in subsequent increments,
  • identify additional major system components that may be added later in the life-cycle of the major system platform,
  • clearly describe how IP and related issues—e.g., technical data deliverables—that are necessary to support a MOSA will be addressed, and
  • clearly describe the approach to systems integration and systems-level configuration management to ensure mission and information assurance.

(2). Analyze the contractor’s economic interest in the technical data that describes the technical baseline for those major system components that potential offerors developed exclusively at private expense. Specifically, the program office should perform market research by, e.g., issuing presolicitation notices requesting potential offerors identify what technical data or computer software they have developed exclusively at private expense would be contained in a CDRL deliverable, what IP rights they contemplate delivering to the Government, and what would be the price they might charge to deliver a higher level of IP rights than that which they contemplate delivering to the Government.

(3). Analyze the Government’s costs to acquire, maintain, store, retrieve and protect the data, repair/maintenance/overhaul philosophies, spare/repair parts considerations, and whether procurement of major system components can be accomplished by acquiring the SSSs to those components and to the major system platform, and related major system interfaces. In other words, the program office must analyze the basis of its maintenance philosophy and what is the potential that philosophy may change. If, for example, the program’s Source of Repair Assignment Process (SORAP) determines that various major system components residing within the major system platform cannot be repaired but instead must be replaced for the foreseeable future, it is unlikely the program office could justify acquiring Government Purpose Rights to a full design disclosure technical data package for those components as its minimum need. In contrast, the program office will need to acquire Limited Rights to the Critical Design Review data package for those components so the program office and its covered government support contractors can analyze the design details and manufacturing processes for that component for, e.g., single-point failures.

(4). Compare the results of item (2). to item (3). to justify an investment decision to implement (or not implement) an MOSA or acquire (or not acquire) IP rights in technical data and computer software for the program.

d. Subparagraph 7.6.4

This subparagraph of the program’s acquisition strategy must include a cost-benefit analysis of including a priced contract option for the future delivery of technical data and IP rights not acquired upon initial contract award. For example:

  • Based upon its technology readiness assessment, the program office determines whether critical technology elements will mature to the extent that a component that cannot be repaired at present can be repaired by a depot-level maintenance facility in the future.
  • The requirements community can be convinced over time that a company other than the software developer can deliver software patches/updates of equivalent quality at a cheaper price.
  • The program office will acquire Unlimited/Unrestricted Rights to all technical data and computer software needed for the life-cycle of the weapon system as part of the basic contract.

e. Subparagraph 7.6.5

This subparagraph of the program’s acquisition strategy must include an analysis of the risk that the contractor may assert limitations on the government’s use and release of data, including IR&D-funded data (e.g., require the contractor to declare IR&D up front and establish a review process for proprietary data). In other words, the program office should analyze the difference (“gap”) between those minimum needs it has identified for the contemplated acquisition in subparagraphs 7.6.1 and 7.6.2 of its acquisition strategy and those IP rights in technical data and computer software associated with items, components or processes for any components or subsystems of that weapon system the Government already acquired under existing contracts. Note that the level of system decomposition used in performing this analysis should be consistent with the program’s SEP, WBS, and LCSP for the contemplated acquisition.

To determine what rights the Government currently possesses, the program office should carefully review the following six sources of information:

  • Copies of all relevant contracts.
  • Copies of FAR/DFARS standard clauses incorporated by reference into those contracts. Note that by the time that analysis commences, the program office might have difficulty obtaining a copy of those clauses if those regulations have been revised to include a more current version of those clauses or those clauses have been deleted from the FAR/DFARS. The law library of the Office of the Staff Judge Advocate contains hard copies of superseded versions of those clauses.
  • Copies of any asserted rights restrictions made by the contractor prior to award in its completed DFARS 252.227-7017 certification/representation.
  • Copies of technical data/computer software (i.e., CDRLs) delivered under predecessor contracts, as the restrictive marking on the cover page of those CDRLs should indicate what use, release, and disclosure restrictions apply to those CDRLs.
  • If the CDRLs did not contain technical data which by law the Government was entitled to receive Unlimited Rights, the program office should request the contractor provide its accounting records that identifies the sources of funding used to develop the items, components, or processes associated with the technical data or computer software delivered via those CDRLs. For further details, see Section V.H.4.d.(2) below.
  • Copies of any Earned Value Management (EVM) data submitted to the Government under any Government contract that may identify the sources of funding used to develop the items, components or processes associated with the technical data or computer software delivered via those CDRLs. By way of background, DFARS 234.201(1)(ii) requires that all cost and incentive contracts and subcontracts valued at $50,000,000 require the contractor to have an EVM system that complies with ANSI/EIA-748. As stated in DoD’s EVM Interpretation Guide (February 18, 2015) (https://www.acq.osd.mil/evm/docs/dod%20evmsig.pdf), government and industry program managers use EVM as a program management tool to provide joint situational awareness of program status and to assess the cost, schedule, and technical performance of programs for optimum program planning and control. In brief, EVM requires that the contractor establish a budget—otherwise known as a Budgeted Cost of Work Performed (BCWP)—for discrete work packages that define the scope of the work to be performed at a level below WBS Level 5, and then compare that BCWP on a regular basis to the Actual Cost of Work Performed (ACWP) to perform that work package as reflected in the contractor’s CDSRs, FCHRs, PCRs, SFCHRs, and CBDRs to determine the efficiency of the work being performed. Actual costs (both direct and indirect) must be accurately accumulated and summarized in the contractor’s EVM System by the program’s WBS and Organizational Breakdown Structure (OBS) elements, depending upon the level of indenture to which the WBS has been extended (e.g., a specific item/component/software item). As a result, the contractor’s EVM data will indicate whether it incurred any costs during performance to develop the technical baseline (i.e., the technical data or computer software associated with that item/component/software item that is a WBS element) it delivered to the program office within a specific CDRL. And if it did so, for the reasons described in Section V.B.2.b.(1).(g).(iii) above, the Government acquired Government Purpose Rights—if not Unlimited Rights—to that technical baseline.

The results of this analysis will lead the program office to one of three conclusions:

  • The contractor will not assert any limitations.
  • The contractor will assert limitations that are unjustified.
  • The contractor will assert limitations that are valid.

In the first situation, the program office would summarize its analysis in subparagraph 7.6.5 of its acquisition strategy. In the second situation, the program office should formally challenge those limitations as described in Section V.J.3 below. In the third situation, the program office should summarize its analysis in subparagraph 7.6.5 of its acquisition strategy—and in its sole-source Justification & Approval (J&A) document as described in Section V.H.3 below.

C. Formulating the Life-Cycle Sustainment Plan (LCSP)

10 U.S.C. § 2337 requires that the Secretary of Defense issue and maintain comprehensive guidance on life-cycle management and the development and implementation of product support strategies for ACAT I and II programs. It also states that the Secretary of Defense shall require that each ACAT I and II program be supported by a product support manager (PSM). This mandate is implemented by DoDI 5000.02 Change 3.

Specifically, DoDI 5000.02 Change 3 requires the program manager, with the support of the PSM, develop and implement an affordable and effective performance-based product support strategy. Amongst other things, that strategy must address the IP deliverables and associated license rights consistent with and integrated with the program’s IP Strategy, and how and when computer software and computer software documentation and other material and activities required to maintain and sustain the software after Initial Operational Capability (IOC) will be provided to the Government for systems that require core logistics support or when depot level software maintenance is required.

DoDI 5000.02 Change 3 also requires that, beginning at Milestone A, program managers develop and maintain an LCSP consistent with the product support strategy. The LCSP must be updated at each milestone at which time the LCSP must focus on issues specific to that milestone. It must be submitted to and approved by the MDA at Milestone B and reviewed by SAF/AQ at least every five years after a system’s IOC. Amongst other things, the LCSP will include as an annex the program’s IP Strategy which must be updated appropriately during the Operating & Support (O&S) phase.

AFI63-101/20-101 requires that the program manager develop or update an LCSP for all ACAT programs for Milestones A/B/C/Full Rate Production and every five years after IOC until system disposal. Amongst other things, it requires that the program manager include the program’s IP Strategy as an annex to the LCSP for the O&S phase only, and develop and coordinate the LCSP in accordance with the OSD approved outline. That OSD approved outline—otherwise known as Life-Cycle Sustainment Plan (LCSP) Outline Version 2.0—states that it and the product support strategy supports the conditions for the Services to analyze the decision space for how to control O&S cost.

1. Paragraph 3

Paragraph 3 (Product Support Strategy) of the LCSP Outline does not require that the LCSP address how the program is implementing MOSA principles as part of its product support strategy. It does, however, state the decomposition of the sustainment requirement and the system architecture and allocation against the product support elements necessary to satisfy the requirement should be included in Figure 3-1 (Sample Drawing of the Reference Design Concept) and Table 3-1 (Product Support Strategy for Reference Design Concept). At Milestone A, that data may be notional and only be at the first indentured level (WBS) of the system’s architecture; but by post-Preliminary Design Review (PDR), Milestone B, and beyond, greater detail and data for systems, subsystems, or components should be included. That Outline also states that, while data on the design, specific facilities, or providers may not be known early in the life-cycle, the program must provide sufficient detail to illustrate planning for data in the IP Strategy and technical data IP rights provisions in its contracting actions, maintenance planning, and supply chain management.

Table 3-1 of that Outline contains rows and columns that provide greater granularity with respect to the product’s support strategy for all subsystems in the weapon systems’ architecture. Specifically, Column 1 of that table must identify all subsystems and related test equipment and simulators, Column 2 must identify whether there is any “Proprietary Intellectual Property” residing within that hardware, Column 3 must identify what “[IP] Rights” the Government acquired to that hardware, Column 8 must identify the level of organic support that will be provided for the software residing within that hardware (full organic capabilities, limited capabilities) or which contractor will be providing that support, and Column 11 must identify the level of organic support that will be provided for the “Technical Data” that describes the technical baseline of that hardware (full organic capabilities, limited capabilities) or which contractor will be providing that support.

FAR 45.101 states that the Government acquires title to hardware and does not acquire title to IP or software. Instead, the Government acquires IP rights to technical data and computer software that describes the technical baseline of that hardware (and, if the resulting contract is properly structured consistent with the guidance provided in this Handbook, contract administration information). Therefore, it would be inappropriate for a program office to complete Table 3-1 by stating that it acquired, e.g., “Government Purpose Rights” to the, e.g., “Heaters, Thermisters and Thermostats” of the “Thermal Control (TCS)” subsystem of the “Bus” of the “Space Vehicle”.

Instead, when completing this table, we suggest the program office identify in Column 3 what IP rights it acquired to what CDRL deliverables that describes the technical baseline of the subsystem, component, or software item identified in Column 1 of that table the program office needs to maintain and sustain that system throughout its life-cycle. If a program office has properly structured the contract that will acquire that weapon system consistent with the guidance provided below, it should not take the program office much time to do so. This approach will facilitate the reader’s understanding of precisely what technical data or software that describes the technical baseline for that subsystem, component, or software item/software subroutine will be organically supported or supported by a specific contractor identified in Columns 11 or 8, respectively.

In this regard, we note that, contrary to the suggestion in Table 3-1, DFARS 252.227-7013 does not identify a type of IP rights as “OMIT data”. As indicated above, that acronym stands for “operations, maintenance, installation, training”—which is a type of technical data for which the Government is entitled to acquire Unlimited Rights irrespective of which entit(ies) funded the development of that technical data (unless that OMIT data includes detailed manufacturing process data). In contrast, if the program office implements the suggestion we provide above, use of the title of the CDRL itself in Column 3 of that table might be sufficiently illuminating to convince the reader that that deliverable contains “OMIT data” (e.g., “Orbital Operations Handbook”). Compounding the confusion created by the Outline is that Table 3-1 provides as an example a platform that apparently acquired “OMIT data” rights to the “Diagnostics Software” to the “Fire Control” component of the “Avionics” subsystem. But unless the RFP and resulting contract specifies otherwise, OMIT data encompasses only technical data and computer software documentation—not computer software. Again, inserting the title of the CDRL into Column 3 and “mapping” that CDRL to the IP rights the Government has acquired or will acquire to that deliverable will help the reader understand what type of IP rights the Government has acquired or will acquire to that deliverable.

2. Subparagraph 3.3.1

This subparagraph requires that the program office complete Table 3-5 (Performance Based Arrangements in Contracts) of the LCSP Outline, which characterizes the primary attributes of sustainment contracts and must reflect the requirements decomposition and WBS presented in Table 3-1. For each current and planned sustainment contract, Table 3-5 must include the name and CLIN, organization and points of contact, products and period of performance covered, responsibilities/authorities and functions, performance metrics and incentives, and status of Cost and Software Data Reporting (CSDR) planning/reporting.

3. Paragraph 10

This paragraph requires that the program office include as annexes summaries of various programmatic documents. One of those documents is the program’s IP Strategy, which shall be added to the program’s LCSP not later than the Full Rate Production decision.

D. Drafting the Request for Proposals (RFP)

As stated above, AFI63-101/20-101 requires that source selections consider Government rights to data and include priced options that correspond to the data and IP rights recommended as part of the IP Strategy. Neither that instruction nor the Air Force Federal Acquisition Regulation Supplement (AFFARS), provides detailed guidance on how to structure an RFP in order to implement that mandate. Experience has demonstrated that merely incorporating by reference standard DFARS clauses will not suffice to identify and resolve critical technical data and computer software rights issues prior to and after award. For example, DFARS 227.7103-3(b) and DFARS 227.7203-3(a) require that program offices include into their RFPs a provision that offerors use to identify use, release, and disclosure restrictions (DFARS 252.227-7017). As stated above, however, that provision does not require that the offeror “map” those restrictions to specific CDRLs—it only requires that the offeror “map” those restrictions to the technical data or computer software to be delivered to which those restrictions pertain. If the program office does not correct this omission prior to award, the program office may not have a defensible position regarding whether the restrictive markings the contractor affixed to a particular CDRL prior to delivery are consistent with contract requirements.

Similarly, as stated above, even though military departments encourage contractors to deliver COTS software, no DFARS clause establishes the Government’s rights in that commercial computer software. If a program office accepts delivery of that COTS software but fails to obtain, read, and incorporate the relevant IP license agreement(s) into the contract prior to award, it may be in for an unpleasant surprise after award. Specifically, it may realize the license(s) prevent(s) the use, release or disclosure of that software to certain entities to which it must release that software in order to execute successfully the program. And it will do no good for the program office to plead ignorance of the terms and conditions of that IP license, as a recent ASBCA decision ruled that the Government can be bound by the terms of such a license it has neither negotiated nor seen prior to the receipt of the software, so long as the terms are consistent with those customarily provided by the vendor to other purchasers and do not otherwise violate Federal law.

Accordingly, what follows is a structured approach for drafting the relevant sections of the RFP consistent with the Uniform Contract Format (UCF) contained in FAR 15.204-1 Table 15-1 that, if implemented, should minimize the probability that the program office will acquire insufficient IP rights in technical data and computer software to successfully execute an acquisition program. This approach is not the only manner in which a program office could structure an RFP to achieve that objective. (Note, however, that various program offices have successfully used the framework described below on a Navy ACAT I program and multiple Air Force ACAT I programs. For further details, see Appendices 1-3.) Any other approach that satisfies all objectives described above in Section V.B. would be equally acceptable. Again, however, experience demonstrates that unless the program office implements an approach similar to that described above from the outset, it may be forced into having protracted discussion sessions with offerors that take much more time than would otherwise have been the case had the RFP been properly structured in the first place (not to mention multiple RFP amendments). That situation, of course, will cause delays in award of the resulting contract.

1. Exhibit A (Contract Data Requirements List)(CDRL)

a. The “acquisition reform” experiment—and its offspring

One school of thought which held court during the “acquisition reform” heyday of the 1990s—and which may be reemerging from the Sebonian Bog—asserts that a reduction in the number of CDRLs will dramatically reduce the (initial) cost of the weapon system. In retrospect, the consequences of implementing that approach should have come as no surprise: The contractors wrote few documents; they did not provide those documents in a timely manner; and the Government had much less authority to require improved documentation when the products omitted necessary content. Deficient documentation then resulted in late, inadequate weapon systems needing rework to improve them so the Air Force could field those weapon systems. Contracts awarded based in part upon that school of thought experienced substantial cost overruns in the years that followed—including, in some cases, multiple Nunn-McCurdy breaches. Moreover, in some cases, the Air Force could not perform anomaly resolution activities and resolve pertinent issues during Safety Investigation Boards (SIB) in order to determine the most probable root cause of an on-orbit failure of a satellite. In sum, the offspring of that school of thought was that the Government lacked necessary insight into the weapon system, its quality, and overall progress.

That school of thought failed then—and fails now—to consider a basic principle of systems engineering: No weapon system ever magically appeared on-demand in the warfighter’s hands as an Immaculate Conception. Before the developer can manufacture any component of any of the subsystems of that weapon system, the developer must create documentation that accurately describes the product baseline. And during the manufacture of that weapon system, the developer must create documentation that accurately describes the product (as-built) baseline and the final (as-built) configuration. As the Armed Services Pricing Manual (ASPM) succinctly stated over three decades ago,

“The contractor will prepare certain data as a natural consequence of contract performance. Design, development, testing, and production tasks will generate certain data, whether or not you identify a requirement on the DD Form 1423 and ask for its delivery.”

That is why Aerospace Report No. TOR-2006(8506)-5738 (Recommended Software-Related Contract Deliverables for National Security Space System Programs)(February 14, 2008) states that successful (software) development depends upon having the necessary system, segment, subsystem, and element CDRLs items in place.

Like nature, competent accountants cannot be fooled.[24] Even if the regulatory mandates described below did not exist, a program office must still spend money having the contractor create documentation that accurately describes the product (as-built) baseline and the final (as-built) configuration in order to successfully design, develop, manufacture, deploy, sustain/maintain and dispose of a weapon system.

In other words, the free lunch does not exist. The lunch must be prepared and served. The only question is who will pick up the tab.

During the “acquisition reform” heyday of the 1990s, program offices also attempted to convey the impression to senior leadership that they had managed to square the circle. They would still acquire the technical data and computer software necessary to successfully execute the program while at the same time dramatically reducing the number of CDRLs. How did they do that? In two ways. First, they started using the Data Accession List (DAL) CDRL as the proverbial “kitchen sink” into which all of their known requirements for technical data or computer software could be poured. In doing so, they disregarded two facts.

The first fact they disregarded was that the very text of the Data Item Description (DID) for a DAL (DI-MGMT-81453B) warns that a program office is not authorized to use the DAL in that manner: The DAL “is not a substitute for standard data requirements that are contractually applied.” The reason why the DoD does not authorize misusing the DAL in that manner is because the DAL is nothing more than a list of technical data and computer software the contractor decided to and ultimately created during contract performance. The DAL does not describe in detail the content of any technical data or computer software the program office will require the contractor to deliver after award that is listed on the DAL.

A fundamental principle of government contracting is that in a competitive environment an RFP must provide for the submission of proposals based upon a common understanding of the agency’s requirements. Since the DAL does not accurately describe the content of each item of technical data or computer software the program office expects the contractor will deliver to it after contract award, it is impossible for a common understanding to exist between all offerors and the Government as to that content. As a result, the Government will be unable to negotiate a fair and reasonable price for that data. Some offerors may underbid not realizing what the Government’s content needs are. Other offerors may overprice assuming that the Government will require delivery of all items the contractor will eventually list on the DAL.

The second fact they disregarded was that the DAL states that the list “shall also identify the Government Rights to the data using the following codes: ‘GPS – Government Purpose Rights[;] UR – Unlimited Rights[;] LR – Limited Rights[;] RR – Restricted Rights (computer software only)[;] CLR – Commercial License Rights for commercial technical data[;] CSLR – Commercial Software License Rights for commercial computer software and commercial computer software documentation[;] SNLR – Specifically Negotiated License Rights.” This language basically permits a contractor to unilaterally determine what license rights the Government will acquire to those items listed on the DAL after award—as opposed to the Government knowing prior to award what rights it will acquire to each item of technical data or computer software that is the subject of its own DD Form 1423. In short, a program office that seeks to use the DAL in the manner described above is like a real estate developer whose standard practice is to use the butt-end of a screwdriver to hammer nails to build commercial and residential properties: It is possible—but the adverse consequences could be catastrophic.

Second, program offices required their development/production contractors agree to so-called “enabling” provisions in Statements of Work/Performance Work Statements (SOW/PWS) (SMC MP5335.0-90). Such “enabling” provisions require those contractors provide a program office’s support services contractors “access” to various types of technical, cost, and schedule data that were not CDRL deliverables. Although this is a type of IP license (since it attempts to identify who can have “access” for what purposes for a specified period), such provisions are a questionable solution to the problem of properly acquiring IP rights in technical data and computer software for two reasons.

First, the license rights used by the DFARS clauses described above do not use the term “access”—they are phrased in terms of “use”, “release” and “disclosure” restrictions associated with deliverables. It is unclear why a program office would want to become embroiled in litigation regarding whether the vague term “access“ is synonymous with those terms—or whether, according to Webster’s Dictionary, that term should be interpreted to mean anything from “an attack or onset of illness or disease”, to “a fit or spell of intense feeling”, “permission, liberty, or ability to enter, approach, communicate with, or pass to and from”, etc. Second, if a development/production contractor is providing those support services contractors “access”, then the contractor is providing that “access” directly to a support services contractor. In other words, use of those agreements may erode the program office’s control of the program since it takes the program office “out-of-the-loop” because the program office is no longer the sole conduit of that technical data and computer software between that contractor and its support services contractor. And if the recipient provides comments on that technical data or computer software to which it has had “access” back to the contractor, those comments may not have been approved by the program office—but nevertheless might be construed by the contractor as a constructive change to its contract. (For further details regarding the concept of a constructive change, please see Government Contract Law for Engineers.)

b. The “back-to-basics” approach

After having read the above discussion you should now understand why program offices should reject the “acquisition reform” approach and get “back-to-basics”—which is why the DoD Open Systems Architecture Contract Guidebook for Program Managers states that

“[t]he main thrust for DoD and Service systems engineering and Program Manager communities should be on the development of appropriate SOW requirements, Data Items Descriptions (DIDs), and CDRLs across the enterprise.”

Specifically, DoD 5010.12-M, DFARS 215.470(b), and SMC IG5315.470-90(a) require that program offices acquire technical data under DoD contracts via a DD Form 1423 (CDRL). Similarly, the military departments acquire computer software and contract administration information via DD Form 1423.

The DoD uses DD Form 1423 to assist in defining delivery obligations, not to establish the Government’s rights to use, release or disclose the delivered IP outside the Government. As recently stated by the GAO, use rights and delivery of items are legally distinct concepts. As a result, the contract must require both delivery of a particular item of technical data, computer software, or contract administration information, as well as the IP rights to those items.

Use of the DD Form 1423 properly bounds the scope of the technical data and computer software that the contractor will deliver to the program office. Moreover, the Warranty of Data clause in the resulting contract (DFARS 252.246-7001) states that the warranty period extends for three years after completion of the delivery of the line item of data “as identified in DD Form 1423, Contract Data Requirements List. . . .” As a result, if the program office did not acquire a particular item of technical data “identified in [a] DD Form 1423” it is doubtful whether the program office acquired a warranty to that data.

Accordingly, the first step the program office should take when drafting the RFP so that it will properly acquire IP rights in technical data and computer software is to create the appropriate CDRLs. (As explained in Sections IV and V.D.5.a below, CDRLs in Exhibit A would include the WBS and WBS dictionary, SSSs (DI-IPSC-81431A), SSDDs (DI-IPSC-81432A), and—for software-intensive systems—SDDs (DI-IPSC-81453A), and the SAD. SMC-S-012, Appendix H.2, contains the required format and content of a SAD. The program office would copy that text into the CDRL for that deliverable incorporated by reference into Exhibit A of the RFP.) Creating the appropriate CDRLs includes ensuring the content of those CDRLs—including any tailoring of referenced Data Item Descriptions (DID)[25]—encompasses the universe of all technical data, computer software, or both, that the program office desires the contractor to deliver after award. And where the ACAT I program will implement MOSA principles, 10 U.S.C. § 2320 states that major system interfaces—i.e., between a major system platform and a major system component, between major system components, or between major system platforms—must be expressly identified in the RFP (i.e., as DD Form 1423 CDRLs).

To that end, the content of a CDRL could—and may very well need to be—component-specific. For example, if the WBS for a major system platform is written to the fifth level of indenture, the DD Form 1423 could require the contractor to deliver a separate Design Review Data Package (DI-ILSS-81335) CDRL for each major system component at that level of indenture residing within the system. Similarly, to implement MOSA principles, the DD Form 1423 could require the contractor to deliver separate Interface Control Document (ICD)(DI-SESS-81248B), Interface Requirements Specification (DI-IPSC-81434A), and Interface Design Description (DI-IPSC-81436A) CDRLs that describe the interfaces between

  • each major system component and all other major system components, and
  • the interface between each major system component and the major system platform in which that component resides.

As indicated in Sections V.B.2.b.(1).(e), V.B.2.b.(1).(g), and V.D.5.g., this approach would facilitate “mapping” of licenses to each deliverable and baselining license rights to a single level per CDRL.

We hasten to add that one should not read the phrase “high-level” as that phrase is used in the definition of “major system component” in 10 U.S.C. § 2446a as meaning the program office may only acquire major system interfaces between items at the third level of indenture of the WBS (e.g., an interface between a satellite bus and a payload). Instead, the primary consideration that should govern what major system interface CDRLs between major system components residing within the major system platform the program office will require the contractor to deliver via Exhibit A—irrespective of the level of indenture of the WBS at which those major system components will reside—are the program’s minimum needs as reflected in, e.g., its maintenance philosophy, its SEP.

The approved method of completing the task of creating appropriate CDRLs is for the program manager to convene the Data Requirements Review Board (DRRB) described in DoD 5010.12-M. The co-chairs of the DRRB should be the program manager and the Contracting Officer. Attendees should include all CDRL authors (e.g., business financial managers, engineers, logisticians). During the DRRB, the author of the CDRL should:

  • Explain why the program office needs that CDRL,
  • Explain why delivery of the proposed content is required (e.g., the tailoring of that CDRL is consistent with the DID invoked by that CDRL, the author used the Queen’s English properly),
  • Identify where in the SOW/PWS is the tasking statement that requires the development/production and delivery to the Government of that CDRL,
  • Validate that the SOW/PWS does not describes CDRL content that should instead be described in the CDRL itself, and
  • Explain why “approval” (vice “review”) of that CDRL is required.

Assuming that the proposed Exhibit A to the RFP contains 112 CDRLs, this activity will probably take 75-80 hours to complete. But that is time well-spent—because if the program office fails to describe that technical data or computer software in a particular CDRL, that item may not be a deliverable. As a result, the program office may not acquire any IP license to use, release or disclose that item to non-Government employees for any purpose whatsoever.

We note in-house counsel for some defense contractors cannot even agree amongst themselves whether the Government acquires rights to various items of technical data—that the contract did not classify as a “deliverable” via a DD Form 1423—where the Government only acquired electronic “access” via some type of IDE. In other words, neither in-house counsel—nor, for that matter, academia—agree whether delivery must occur before the DoD acquires IP rights to the content of that technical data or computer software. These facts strongly counsel in favor of a program office making every scrap of technical data, computer software, and contract administration information that the program office needs to successfully execute the program throughout its life-cycle the subject of a DD Form 1423—thereby neatly circumventing the need for the program office to extricate itself from this legal quagmire after award.

The program office should also include a sentence at the beginning of Block 16 of the DD Form 1423 that states whether the CDRL requires the delivery of technical data only, computer software only, both technical data and computer software, contract administration information, or both technical data and contract administration information. The purpose of that sentence is to document the offeror’s agreement that that CDRL contains only that content. The reason why is because contractors have occasionally asserted that a particular CDRL should be delivered with “Restricted Rights”—which, as stated above, is a term that only describes the type of IP rights the Government acquires to noncommercial computer software—notwithstanding the DD Form 1423 expressly states that “This CDRL contains only technical data.” Under such circumstances, the program office will be able to quickly correct the contractor’s misunderstanding in this regard by just pointing to that sentence—vice having to provide a lengthy explanation that quotes various portions of the tailored DID in support of its position.

Next, the program office should review the content of the SOW paragraph, the tailored DID, and any compliance documents invoked by each CDRL and then answer the following questions to determine the technical data/computer software rights associated with that CDRL to which the Government may be entitled. (Thus, if Exhibit A of Section J of the RFP contains 112 CDRLs, the program office must repeat the following analysis 112 times.)

If those sources describe noncommercial technical data, is it (1) form/fit/function data, (2) data necessary for operation/maintenance/installation/training (OMIT) purposes (which would include computer software documentation)(other than detailed manufacturing process data), (3) data that constitutes a correction or change to data furnished by the Government, or (4) data otherwise publicly available or has been released by the contractor without restrictions? If that technical data fits within any of those categories, the program office should acquire Unlimited Rights in that technical data unless the program office determines that its minimum needs may be satisfied by acquiring a level of license rights (i.e., SNLR) no lower than Limited Rights. In making this determination, the program office must remember that, when agreeing to a lower level of license rights, it cannot surrender rights below the level of Government Purpose Rights if relinquishment would unduly restrict future competition.

To reiterate, with respect to one type of form/fit/function data—major system interfaces between an item or process and other items or processes necessary for the segregation of an item or process from, or the reintegration of that item or process (or a physically or functionally equivalent item or process) with, other items or processes in a MOSA—10 U.S.C. § 2320 states that the Government shall have Government Purpose Rights in that type of technical data developed exclusively at private expense or with mixed funding except where negotiation of different rights in that technical data would be in the best interest of the Government. And if that type of technical data was developed exclusively at private expense, the program office must negotiate with the contractor the appropriate and reasonable compensation for that technical data. For details in this regard, see Section V.H.4 below.

If not, does that noncommercial technical data pertain to (1) studies, analyses, test data or similar data produced in the performance of a contract where that study, analysis, test data or similar work was specified as an element of performance, (2) data that the Government has obtained Unlimited Rights under another Government contract or as a result of negotiations, or (3) data furnished under another Government contract with Government Purpose Rights or Limited Rights and the restrictive condition(s) has/have expired? If that technical data fits within any of those categories, the program office should acquire Unlimited Rights in that technical data unless the program office determines that its minimum needs may be satisfied by acquiring a level of license rights (i.e., SNLR) no lower than Limited Rights.

If those sources describe noncommercial technical data that does not fit within the enumerated categories listed above, will the contractor develop that item exclusively with Government funds? If so, the program office should acquire Unlimited Rights in that technical data unless it has determined that its minimum needs will be satisfied by acquiring a level of license rights (i.e., SNLR) no lower than Limited Rights. If not, will the contractor develop that item in part with Government funds? If so, the program office should acquire Government Purpose Rights in that technical data unless it has determined that its minimum needs may be satisfied by acquiring a level of license rights (i.e., SNLR) no lower than Limited Rights. In making this determination, the program office must remember that, when agreeing to a lower level of license rights, it cannot surrender rights below the level of Government Purpose Rights if relinquishment would unduly restrict future competition.

If those sources describe commercial technical data, is it (1) form/fit/function data, (2) data necessary for installation/operation/maintenance/training purposes (which would include computer software documentation)(other than detailed manufacturing process data), (3) data that constitutes a correction or change to data furnished by the Government, or (4) data otherwise publicly available or has been released by the contractor without restrictions? If so, consistent with 10 U.S.C. § 2320, the program office should acquire Unrestricted Rights in that technical data unless it has determined that its minimum needs may be satisfied by acquiring a lower level of license rights. In making this determination, the program office must remember that, when agreeing to a lower level of license rights, it cannot surrender rights below the level that is equivalent to Government Purpose Rights if relinquishment would unduly restrict future competition.

If those sources describe noncommercial computer software, is it (1) corrections/changes to computer software furnished to the contractor by the Government, (2) computer software that is otherwise publicly available or has been released or disclosed by the contractor or its subcontractor without restriction on further use, release or disclosure, (3) computer software obtained with Unlimited Rights under another Government contract or as a result of negotiations, or (4) computer software furnished under another Government contract under restrictive conditions that have expired? If so, the program office should acquire Unlimited Rights in that noncommercial computer software unless it has determined that its minimum needs may be satisfied by acquiring a lower level of license rights. If not, will the contractor develop that item in part with Government funds? If so, the program office should acquire Government Purpose Rights in that noncommercial computer software unless it has determined that its minimum needs may be satisfied by acquiring a level of license rights (i.e., SNLR) no lower than Restricted Rights.

If those sources describe noncommercial computer software that does not fit within the enumerated categories above, will the contractor develop that item exclusively with Government funds? If so, the program office should acquire Unlimited Rights in that technical data unless it has determined that its minimum needs will be satisfied by acquiring a level of license rights (i.e., SNLR) no lower than Restricted Rights. If not, will the contractor develop that item in part with Government funds? If so, the program office should acquire Government Purpose Rights unless it has determined that its minimum needs will be satisfied by acquiring a level of license rights (i.e., SNLR) no lower than Restricted Rights.

If those sources describe commercial computer software, what rights to use, release, or disclose that software outside the Government does the program office need to acquire? Irrespective of the answer to that question, are the proposed rights inconsistent with Federal procurement law?

2. Section B (Supplies Or Services And Prices/Costs)

DFARS 204.7103-1(a) states that contracts shall identify the items or services the Government will acquire as separate Contract Line Items Numbers (CLIN) unless it is not feasible to do so. That regulation also states that, in general, CLINs shall have a single unit price, be a separately identifiable item, have a separate delivery schedule, and reference a single accounting classification. In order to comply with that regulation, and for the reasons described below, Section B should contain both a separately-priced CLIN for the data the Government will acquire, as well as another separately-priced CLIN for the IP rights to that data the Government will acquire.

With respect to the former CLIN: In many cases the Government has established a “Not Separately Priced” (NSP) CLIN that requires the delivery of technical data and computer software. That approach, however, is not the best approach because the Government’s assumption that the contractor will develop and deliver certain items of technical data, computer software, or contract administration information as part of a CDRL exclusively at its expense—and therefore the Government will receive a certain level of rights to use that CDRL—may be incorrect. Conversely, its assumption that the contractor will develop and deliver certain items of technical data, computer software, or contract administration information as part of a CDRL exclusively at private expense—and therefore it will receive a different level of rights to use that CDRL—may likewise be incorrect.

Accordingly, as recommended by AFPAM63-128 Table 11.3, the Government should establish in Section B a priced CLIN for the delivery of all technical data, computer software, and contract administration information described in Exhibit A (CDRLs) so the program office will understand what it is paying for and enhance its ability to make informed decisions. Section V.D.7 below explains how the offerors will propose pricing for this CLIN on a CDRL-by-CDRL basis, thereby indicating how the result will be included in Exhibit A of the awarded contract.

With respect to the latter CLIN: DFARS 207.105(S-70)(2)(ii) states that acquisition plans should address the merits of including a priced contract option for the future delivery of rights in technical data and computer software that the program office will not acquire upon initial contract award. That said, for the following two reasons, the Government should establish in Section B a priced CLIN for the IP rights the program office will acquire to those deliverables irrespective of (1) whether the rights the contractor proposes to grant to the Government are based upon which entity funded the development of a particular item, component or process, or (2) whether it will acquire such IP rights as a priced option or part of the basic contract.

First, the instructions provided on the back of the DD Form 1423 that explain how offerors should fill-in Block 18—with their estimate of the costs to be incurred in developing or producing that CDRL over and above those costs which would otherwise be incurred in performance of the contract if no data were required—expressly state that

“The estimated data prices shall not include any amount for rights in data. The Government’s right to use the data shall be governed by the pertinent provisions of the contract.”

That statement begs the question: If Block 18 does not identify the price the Government will pay to acquire IP rights to the data required to be delivered by that CDRL, where if at all in the contract will that information be contained? If the program office follows the recommendations in this Handbook, the answer to that question will be that that CLIN will in turn reference pricing tables contained in a Section J attachment of the RFP entitled “IP Rights”. (For details, see Section V.D.5.g below.)

Second, such an approach will let competition—if competition exists—encourage the offeror to propose to deliver those rights at a competitive price. The reason why is because that price will become part of the offeror’s Most Probable Cost (MPC) the SSA will use to perform their tradeoff analysis consistent with the relative ranking of evaluation factors in Section M of the RFP to decide which offeror’s proposal represents the “best value” to the Government. In other words, a properly structured RFP will incentivize offerors to not put themselves at a competitive disadvantage.

3. Section H (Special Contract Requirements)

a. If the contractor is delivering computer software under a fixed-price CLIN, the program office should consider acquiring a warranty for that software. In contrast, if the contractor will be delivering the computer software under a cost-reimbursable CLIN, the Government may not obtain a warranty for that software.

b. If the program office has included a fixed-price Option CLIN into Section B for IP Rights, it must include an option exercise clause that states the Government may exercise the option in whole or in part from the date of contract award through the end of the period of performance of the contract. In other words, the program office can exercise an option for a certain level of rights associated with a specific CDRL upon obligation of the amount indicated in Table 1 of the IP Rights Attachment (described below).

AFI65-601V1 (Budget Guidance and Procedures)(August 16, 2012) states that the source of funds to procure and print technical data depends upon the appropriation that funded the acquisition of the end item of equipment or systems to which the technical data is applicable. We can therefore logically conclude that the appropriation used to acquire the IP rights in technical data or computer software should be the same as the appropriation used to fund the creation of that technical data or computer software. Accordingly, the option exercise clause should state that the Contracting Officer will obligate the same type of appropriations onto that CLIN to procure rights in technical data, computer software or computer software documentation to be delivered as part of a CDRL as that appropriation they obligated to procure that item and that is current in the year an option is exercised for the rights in that item.

c. Many DoD contracts incorporate by reference via a Section I clause (i.e., FAR 52.204-19 (Incorporation by Reference of Representations and Certifications) all Section K certifications/representations the offeror completed, including those completed electronically via the System for Award Management (SAM). FAR 52.204-7 (System for Award Management) requires offerors to complete certifications/representations in the SAM database. FAR 52.204-13 (System for Award Management Maintenance) requires contractors to update that information on an annual basis to ensure it is current, accurate, and complete. One of the provisions in the SAM database is FAR 52.227-15 (Representation of Limited Rights Data and Restricted Computer Software).

FAR 27.400 and DFARS 227.400 state that FAR IP rights clauses do not apply to DoD contracts. Moreover, FAR 52.204-13 states that updating information in the SAM database does not alter the terms and conditions of the contract. But that language would not appear to affect any restrictions the offeror submitted to that database prior to award. Accordingly, the Contracting Officer should include language into a Section H clause stating that none of the restrictions an offeror may have submitted into the SAM database in response to FAR 52.227-15 will apply to the acquisition in question.

4. Section I (Contract Clauses)

Incorporate by reference all technical data and computer software clauses required by the DFARS, including DFARS 252.246-7001 (Warranty of Data).

5. Section J (List of Attachments)

a. Exhibit A. Include all CDRLs. The CDRLs should include a WBS/WBS dictionary, SSSs, SSDDs, and (for software-intensive systems) a SAD and a SDD. In accordance with 10 U.S.C. § 2446b, Exhibit A should also include ICD CDRLs between the major system platform and its components, between all major system components, and between major system platforms to the appropriate level of indenture in the WBS consistent with the program’s minimum needs (e.g., the program’s maintenance philosophy, the program’s SEP). It should also include CDRLs that require the contractor to deliver documentation demonstrating that the major system platform complies with all existing major system interfaces invoked in the Compliance and Reference Document List and all ICDs it will deliver to the Government. Since no DID currently describes such content, the program office should tailor DI-MISC-80508B (Technical Report—Study/Services) to achieve that objective.

b. WBS. In accordance with 10 U.S.C. § 2446b, the WBS must identify the minimum set of major system components that must be included in the design of that program.

c. SOW (MIL-HDBK-245D)/PWS.

(1). As recommended by the Defense Acquisition Guidebook—and as required by SMC IG5315.470-90—the SOW/PWS should contain tasking statements that require the development/production and delivery of CDRLs contained in Exhibit A. If a program office fails to do so, the development costs for the relevant technology can be shifted to an indirect cost pool, and by being so shifted, can leave the Government with fewer IP rights than otherwise expected. This risk is particularly relevant in light of a judicial interpretation of a sentence buried in a cost principle—the Independent Research and Development and Bid and Proposal (IR&D/B&P) Costs cost principle (FAR 31.205-18) that governs the allowability of costs incurred under Government contracts. The sentence in question defines what IR&D is—and what it is not. Specifically, that cost principle states that “[t]he term does not include the costs of effort sponsored by a grant or required in the performance of a contract.”

Based upon its review of the nearly 40-year-long disagreement between the DoD and its industry partners, the CAFC decided that “required in the performance of a contract” means “specifically required” by that contract. (In contrast, the DCAA’s Selected Area of Cost Guidebook: FAR 31.205 Cost Principles states that auditors must ensure that contractors do not include costs in the IR&D cost pools for developmental efforts “that are specifically required in the performance of a contract or those efforts that are not explicitly stated in the contract, but are necessary to perform the contract.”) Therefore, unless the contract specifically requires development or production of a specific item of noncommercial technical data or computer software in the performance of the contract, the cost for those items could be allocated to an indirect cost pool (e.g., IR&D) so that—based upon the funding rules described above—the Government acquired only Limited or Restricted Rights, respectively, to that technical data or computer software.

Given this judicial interpretation of the IR&D cost principle, program offices would be well-advised to include tasking statements required by SMC IG5315.470-90 into the SOW/PWS that clarify that the development or production of that item of noncommercial technical data or computer software was specifically required in the performance of the contract. For example, depending upon the type of appropriation used to fund the development or production of that item, a tasking statement would be phrased as follows: “The contractor shall develop and deliver a Critical Design Review data package (CDRL A0XX)”, or “The contractor shall produce and deliver a Systems Engineering Management Plan (CDRL A0XX)”.

One additional benefit of this approach is that, consistent with SMC IG5315.470-90(e), a CDRL will exist in Exhibit A associated with every such tasking statement contained in the SOW/PWS. As a result, the program office will have built bidirectional traceability into its contract, thereby easing the burden of contract administration. The reason why is that the instructions for filling-in BLK 5 of the DD Form 1423 require the author identify what SOW/PWS paragraph requires the creation of that item of technical data, computer software, or contract administration information—thereby making it easier for the reader to quickly find that paragraph in the SOW/PWS. In a similar fashion, adding the parenthetical proposed above just after the tasking statement in the SOW/PWS makes it easier for the reader to quickly find in Exhibit A the DD Form 1423 that describes the content of the deliverable mentioned in that SOW paragraph.

(2). In order to diagnose on-orbit anomalies on the ground, it is essential that the software portion of firmware delivered as part of the end item be identical to that contained in a CDRL. Accordingly, the program office should include a sentence into the SOW/PWS that states the software portion of firmware delivered as part of an end item (e.g., space vehicle, launch vehicle) must be identical to that contained in a CDRL.

d. Performance specification (MIL-STD-961E Change 3)/System Requirements Document (SRD)(MIL-HDBK-520A). Where the ACAT I program will implement MOSA principles, to implement 10 U.S.C. § 2446b the performance specification/system requirements document shall describe the MOSA to which the contractor’s design must comply.

e. Compliance and Reference Document List. The purpose of this document is to identify all documents the contractor must comply with during performance of the contract, as well as all documents that the contractor may use as guidance for which the primary audience is the program office. In this case, as stated by DoDI 5000.02 Change 3, the list of reference documents should include the SEP for the reasons described in Section IV.B.1 above.

f. DFARS 252.227-7017. Indicate that the offeror’s completed DFARS 252.227-7017 provision identifying technical data or computer software the offeror will furnish with restrictions on the Government’s ability to use, release, or disclose that information (see below) will be an attachment to the resulting contract.

g. Include a IP Rights Attachment (see Appendix A (Relevant Excerpts from GPS IIIF RFP) Attachment 5). Within this attachment resides the heart of the program office’s approach to acquiring rights in IP. Specifically, this attachment contains three tables that separate the IP rights the program office will acquire to (1) noncommercial technical data and computer software, (2) commercial technical data and computer software, and (3) contract administration information.

In negotiated procurements, clearly stated solicitation requirements are considered material to the needs of the Government. Thus the primary purpose of this attachment is to make it clear to all offerors that the program office’s need to acquire certain types of IP rights to specific CDRLs is a material term and condition of the solicitation. As a result, the failure of an offeror’s proposal to conform to those terms and conditions is unacceptable and cannot form the basis for award. (Material terms of a solicitation are those that affect the price, quantity, quality, or delivery of the supplies or services being provided.) More specifically, the primary purpose of these tables is—as stated in Section V.B.2.b.(1).(e) & (g).(2) of this Handbook—to identify what license rights the program office will acquire to each CDRL (“mapping”) and to baseline all contents of a specific CDRL to a single level of license rights to the maximum extent practicable. This attachment also contains other conditions that apply to this subject as follows:

(1). Table 1 consists of five columns (i.e., “CDRL Number,” “Data Item Title (Subtitle),” “Government Asserted Rights Category”, “Offeror Proposed Rights Category”, “Price”) and a quantity of rows equal to the number of CDRLs. The program office must fill-in the first and second columns using the information in Exhibit A. Based upon the answers provided to the questions listed in Sections V.B.2.b.(1).(b). and V.D.1.b. of this Handbook, the program office must also fill-in the third column with the level of IP rights it believes reflects its minimum needs for the content to be delivered with that CDRL. The offeror will fill-in the fourth column for each level of IP rights associated with each CDRL, and will fill-in the fifth column to indicate the price it proposes to deliver the level of IP rights it proposes to deliver for that CDRL content. If a Specifically Negotiated License will satisfy the program office’s needs, the program office—with the program attorney’s assistance—must clearly specify the scope of that license (i.e., identify specific persons/entities to whom that CDRL may be released or disclosed to for what specific purposes and for what specified period) just above or just below this table. Since some CDRLs require the delivery of both technical data and computer software, this table needs to account for that fact.

(2). Table 2 identifies any commercial technical data and computer software the contractor will deliver to the program office for which its associated license is included into an Appendix A to the IP Rights Attachment. This table presupposes that, although the end item being procured is not itself a commercial item (e.g., F-35), and many items included in that end item are likewise not commercial items, various commercial items will be included in that end item delivered to the Government that in and of themselves satisfy the legal definition of a commercial item. This table will contain five columns (i.e., “CDRL Number” (or, for firmware delivered as part of a hardware item, “CLIN Number”), “Data Item Title (Subtitle)” (or, for firmware delivered as part of a hardware item), “CLIN Noun Description”), ”Vendor Name, Technical Data/Software Application Name, License No.”, “Quantity” of licenses (if applicable), “Price”) and rows equal to the number of CDRLs and CLINs that will contain that commercial technical data and computer software. It is unlikely the program office will know under what CDRL or CLIN the offeror will deliver each item of commercial technical data associated with each commercial hardware component, and under what CDRL or CLIN the offeror will deliver each commercial software item or subroutine to the program office. Therefore—in contrast to Table 1—the offeror will fill-in all five columns.

(3). Military departments invariably acquire other types of data via CDRLs that do not fall within the definition of “technical data” or “computer software” described above (e.g., CSDR, FCHR, PCR, , IPMR, Conference Agendas). As a result, the program office acquires no IP rights to use, release or disclose that contract administration information outside the Government to even covered government support contractors because the IP rights provisions in the DFARS clauses discussed above do not apply to that data. Accordingly, if that data must be used, released or disclosed to those contractors so the program office can successfully execute the program, the attachment should describe the IP license the program office will acquire to use, release or disclose that data to those contractors for enumerated purposes for what specified period. To that end, Table 3 identifies any contract administration information the contractor will deliver to the program office. This table should contain three columns (i.e., “CDRL Number”, “Data Item Title (Subtitle)”, “Price”) and rows equal to the number of CDRLs that will contain that data. The program office must fill-in the first and second columns and the offeror will fill-in the third column. Since some CDRLs require the delivery of both technical data and contract administration information, different parts of those CDRLs will have to be identified in both Table 1 and 3.

(4). Many program offices procure systems via contracts that contain both fixed-price and cost-reimbursable CLINs. To prevent cost migration between various cost-reimbursable CLINs and between cost-reimbursable and firm-fixed price CLINs, the attachment should mandate how the contractor must allocate costs for various IP licenses procured under various CLINs in reasonable proportion to the benefits received by each CLIN.

(5). In many cases, the contractor will deliver firmware as a part of an end item (e.g., space vehicle, launch vehicle) under the resulting contract. Accordingly, the attachment should state that all IP licenses to be furnished by the contractor associated with any computer programs (inclusive of firmware) shall be identical to those associated with any computer programs (inclusive of firmware) the contractor will deliver under a specific CDRL.

(6). The attachment should state that the price for any level of IP rights to a specific CDRL granted by the Contractor includes the same level of IP rights to any updates, software maintenance patches, minor version changes, and substitutions, at no additional cost to the Government. The purpose of this provision is to facilitate accurate submission of future years’ budget requests requesting funding to acquire those IP rights. In other words, this approach will reduce the probability that the contractor can “nickel-and-dime-to-death” the program office for the IP rights to use, release and disclose to non-Government employees each time the contractor or its subcontractors release any update, patch, minor version change, etc., in the future.

(7). The attachment should state that any IP licenses shall transfer to the Government upon delivery of that CDRL or CLIN to the Government.

(8). The attachment should specify what restrictive markings the contractor must affix to which CDRLs, and require that the contractor physically attach a copy of the attachment and all applicable commercial IP licenses to the CDRL prior to delivery to the Government. The purpose of this requirement is so that the recipient can quickly determine what use, release and disclosure restrictions apply to which specific items of commercial technical data located in which specific portions of the CDRL—versus having to hunt around for a hard or soft copy of the contract in order to make that determination.

(9). The attachment should prohibit the contractor from including impermissible terms and conditions described above into any NDAs between it and the program office’s “covered Government support contractors” relative to the use, release or disclosure of technical data or computer software to which Limited/Restricted Rights markings are affixed. Better yet, for the reasons discussed in Section V.B.2.b.(1).(h.) above, the attachment should request the contractor waive the requirement that the program office’s “covered Government support contractors” enter into NDAs with the contractor relative to the use, release or disclosure of that technical data or computer software.

(10). The attachment should require the contractor to, whenever it proposes changes to, e.g., existing CDRLs, to propose the appropriate changes to the attachment as well.

(11). To prevent the contractor from abandoning fundamental principles of configuration control, the attachment should prohibit the contractor from adding, deleting, or replacing any commercial item technical data, computer software, or computer software documentation listed in Table 2 from any CLIN or CDRL under which that technical data, computer software or computer software documentation will be delivered to the Government unless the Government has approved that addition, deletion or replacement and the contract has been modified to add, delete or replace that item from that table and deleted or replaced the applicable license(s) in Appendix A of the IP Rights Attachment. The purpose of this prohibition is three-fold: First, to ensure at all times that the paper (the contract) reflects reality (the system’s architecture). Second, presumably the program office does not want to learn for the first time ever as the weapon system undergoes the RMF process that the contractor inserted that software into that system. Third, to give the program office the opportunity to determine whether the IP license(s) associated with that replacement software are consistent with Federal procurement law and satisfies the program office’s needs.

(12). In many cases, subcontractor commercial technical data and computer software IP licenses contain provisions that violate Federal procurement law. Examples of such provisions include, but are not limited to, disputes provisions, choice of law provisions, attorneys’ fees, automatic renewal provisions that violate the Anti-Deficiency Act, and provisions that prohibit disclosure of license terms/conditions. Therefore, the attachment should include an order of precedence clause that nullifies provisions that violate Federal procurement law.

(13). If standard provisions in those IP licenses do not satisfy user needs (e.g., they are inconsistent with requirements specified in the CDD), the order of precedence clause should expressly nullify those provisions.

6. Section K (Representations, Certifications, And Other Statements Of Offerors)

Insert DFARS 252.227-7017 (Identification and Assertion of Use, Release, or Disclosure Restrictions). That provision—which is not included in the SAM database—requires offerors to identify any technical data or computer software it proposes to deliver to the Government after award with less than Unlimited Rights.

7. Section L (Instructions, Conditions, And Notices To Offerors Or Respondents)

Under the GAO’s Bid Protest Regulations and bid protest decisions issued by the CAFC, protests based upon alleged solicitation improprieties which are apparent prior to the time set for receipt of initial proposals must be filed prior to the time set for receipt of initial proposals. The importance of this fact is that a protester could file a bid protest with either of those forums claiming that the contents of the RFP exceed the program office’s minimum needs for IP rights in technical data and computer software.

Accordingly, the program office should explain in Section L its minimum needs for IP rights in technical data and computer software and the pedigree of those needs so that if a protest results, the program office will be able to establish that rationale existed prior to release of the RFP—it is not some after-the-fact rationale the program office created after the protester filed its protest. By “pedigree”, we mean that Section L should state, e.g.,

  • The statutory/regulatory basis for requiring offerors to deliver certain types of technical data with unlimited rights.
  • What type of noncommercial or commercial license IP rights the CDD or acquisition strategy indicates are needed to satisfy the total life-cycle needs of the program.
  • The rationale for requiring offerors to negotiate with their commercial software vendors modifications to those vendors’ standard commercial software licenses to meet the Government’s minimum needs or to be consistent with Federal procurement law.
  • The extent to which the weapon system’s maintenance/sustainment philosophy dictates that the Government must acquire a certain type of IP rights—e.g., the maintenance philosophy will be that the Government will compete on-orbit anomaly resolution of a specific major system component (i.e., software item) of bus flight software identified at the fifth level of indenture of the WBS and in the SSDD, SAD, and SDD—including the extent to which that maintenance philosophy as described in the program’s LCSP will change at some point. Of course, if the Government never represents to offerors what its maintenance philosophy is—or if the offeror’s assumption that it will perform maintenance of that component or major system platform for the life-cycle of that platform is not expressly incorporated into the contract prior to award—it would be unreasonable for the offeror to base its decision (in whole or in part) to submit a proposal for the development/production of that platform based upon a belief that the Government will award it follow-on maintenance contracts sole-source for the life-cycle of that platform (whatever the duration of that life-cycle may be).

Immediately after describing this pedigree of the program office’s minimum needs, Section L should emphasize that the technical data and computer software IP rights described in the DFARS clauses listed in Section I of the RFP are the IP rights the program office expects to receive in exchange for paying for development of the technical data or computer software. The purpose of this information is to warn offerors they should not propose the Government have to pay an additional cost for acquiring those IP rights.

Section L should then require that offeror’s Technical Volume explain how its IP Rights Attachment in its Contract Volume will meet the Government’s minimum needs and will result in an executable program underneath the appropriate subfactor(s). Section L should also describe how the offeror must propose prices or estimated costs for licenses in its Cost/Price Volume.

Next, Section L should require the offeror fill-in Block 18 of each DD Form 1423 (Estimated Total Price) contained in Exhibit A of its Contract Volume with the amount equal to that portion of the total price estimated to be attributable to the production or development for the Government of that item of data. The ASPM explains the purpose for which the SSEB will obtain that information from the offeror:

“The [program office] will use the submitted prices in deciding whether its needs for the data are worth the dollars they will cost. If the [program office] concludes that the benefits are commensurate with the cost, the data requirement stays on the list; if the [program office] concludes that the data are not worth what they will cost, it modifies or deletes the requirement. The amended list is made a part of the contract. The prices on that list, how they are derived, and what they mean are the subject of this section.”[26]

Next, Section L should provide instructions to offerors (1) describing how they must fill-in their IP Rights Attachment described above, and (2) requiring them to complete their DFARS 252.227-7017 certification/representation consistent with the manner in which offerors have filled-in the tables in their IP Rights Attachment. Experience has demonstrated that the most effective way to achieve this objective is to have Section L require offerors to simply insert the phrase “See Attachment X” (“X” identifying the IP Rights Attachment) and sign the representation.

In contrast, a far less desirable alternative would be for Section L to permit offerors to include assertions in that provision that are allegedly consistent with the manner in which offerors have filled-in the tables in their IP Rights Attachment. If Section L will permit offerors such latitude, so that the program will know precisely what it is buying Section L should also require that for each assertion it makes in that provision the offeror shall

  • Describe with specificity the item of technical data (e.g., document title, revision number, release date) associated with the sub-item, sub-component, or segregable portion of a process or computer software (e.g., name of software sub-routine that performs a specific function, version number, release date). State that the mere identification of a hardware item to which the technical data or computer software pertains will not suffice.
  • Identify the lowest level of indenture in its proposed WBS, SSDD and (for software-intensive systems) its SAD and SDD that sub-item or sub-component or software unit or subroutine that performs a specific function will reside (i.e., require the offeror to “map” its asserted restriction to the item of hardware or software to which the asserted restriction pertains).
  • Since making such assertions may defeat the purpose for which the IP Rights Attachment “mapped” requested IP licenses to CDRL deliverables, identify (“map”) under what CDRL that item will be delivered and cite to the lowest achievable level of specificity the text of that CDRL (e.g., a specific sub-sub-subsection of a Data Item Description (DID) cited in BLK 4 of a DD Form 1423, specific sub-sub-subsection of a compliance document cited in BLK 16 of a DD Form 1423, specific paragraph of text in BLK 16 of a DD Form 1423 that tailors a DID cited in BLK 4 of a DD Form 1423) that requires the delivery of that item of technical data, computer software, or computer software documentation.
  • For technical data (including computer software documentation), explain why that specific item of technical data to which the asserted restriction pertains does not fit within any of the exceptions identified in 10 U.S.C. § 2320(a)(2)(C), DFARS 227.7103-5(a)(2) and (a)(4) through (a)(9), and DFARS 227.7203-5(a)(3) through (6)—because those statutory/regulatory provisions entitle the Government to acquire unlimited rights in the items described therein irrespective of whether the offeror or any of its subcontractors developed those items exclusively at private expense.

As stated above, a recent ASBCA decision ruled that the Government can be bound by the terms of a commercial software license it has neither negotiated nor seen prior to the receipt of the software, so long as the terms are consistent with those customarily provided by the vendor to other purchasers and do not otherwise violate Federal law. Prudence suggests, therefore, that program offices should know what they are getting into prior to award by including language in Section L that requires offerors to provide copies of all licenses associated with all commercial technical data and computer software the offeror proposes to deliver to the Government. The program office should also insert DFARS 252.227-7028 (Technical Data or Computer Software Previously Delivered to the Government) into Section L.

Finally, for the reasons mentioned in Section V.D.5.a-b above, Section L should require the offeror to include into Section J of its proposed Contract Volume a WBS and WBS dictionary as a Section J attachment and instruct the offeror to further extend each WBS element as necessary to define the complete contract scope, consistent with its proposed approach for executing the program. Section L should also require that the offeror describe how its proposed WBS supports the program’s delivery schedule, the extent to which its MOSA approach will define all major system interfaces consistent with the program’s performance specification/system requirements document—because as stated in DoDI 5000.02 Change 3, poorly configured, inadequately maintained, undocumented, or unprotected network and system interfaces create cybersecurity vulnerabilities—and how its approach for conducting systems engineering will be consistent with the program’s SEP. For software-intensive systems, Section L should also require the offeror submit a SAD as part of its Technical Volume, and include the SSDD, SAD, and SDD CDRLs into Exhibit A of its proposed Contract Volume. The proposed SAD should identify precisely where all noncommercial and commercial software applications will reside in the offeror’s proposed architecture.

8. Section M (Evaluation Factors For Award)

The GAO has held that the Government must evaluate proposals in accordance with the terms of the solicitation, and that an agency may properly consider specific, albiet not expressly identified, matters that are logically encompassed by, rationally related to, or intrinsic to, expressly stated evaluation criteria. The COFC has enunciated a similar standard: A solicitation need not identify each element to be considered by the agency during the course of the evaluation as long as such element is intrinsic to the stated factors.

This does not mean, however, that an agency may evaluate whatever it wants to under any particular evaluation criteria, as there must be a clear nexus between the stated evaluation criteria and the unstated criteria. Given this legal principle—and the fact that the subject of acquiring IP rights is in a class by itself—it is highly inadvisable for any program office to assume that it will be able to prove its evaluation of the offeror’s proposal to furnish IP rights in technical data and computer software was logically encompassed by, and rationally related, to whatever expressly stated technical evaluation criteria was in Section M. Accordingly, and for the reasons described in Section V.B.1 above, Section M must include evaluation criteria within the appropriate Technical subfactor that expressly state that the Government will evaluate the extent to which the offeror’s proposed IP rights—as reflected in its IP Rights Attachment (including the content of any commercial licenses) and its completed DFARS 252.227-7017 certification/representation—satisfies the Government’s minimum needs and does not inhibit the Government’s ability to execute successfully the program throughout its life-cycle.

Section M should also explain how the Government will use the prices the offeror proposes for the technical data, computer software, and contract administration information the offeror proposes to deliver to the Government after award as well as the rights to that IP as part of the Government’s cost/price evaluation. In this regard, if the Government will permit offerors to propose more than one type of IP rights (and therefore a different price for each type), it should identify what price for what type of IP rights it will use as part of its MPC calculation for each offeror. Caution is advised when making this identification—as an improper selection could widen the MPC differential between offerors to such an extent as to make it difficult if not impossible for an SSA to award the contract to a technically superior offeror.

Finally, for the reasons mentioned in Section IV above, Section M must state the Government will evaluate the extent to which the offeror’s proposed architecture will implement MOSA principles consistent with the program’s SEP, the offeror’s proposed WBS as contained in Section J of its Contract Volume, and (for software-intensive systems) its proposed SAD as reflected in the offeror’s Technical Volume.

E. Integrated Data Environments (IDE)

1. The Concept

Over the past two decades, program offices have used IDEs to execute their acquisition programs. Unfortunately, in some cases they have realized too late that they unconsciously inserted into their program management structure something they would rarely—if ever—permit a contractor to intentionally insert into the design of the weapon system to be provided to the warfighter: A single-point failure just waiting to happen. The single-point failure is because for administrative convenience, the program office decided that an IDE would reside on the prime contractor’s servers. What that means is that the program office will not have physical custody or control of any data residing within that IDE. The single-point failure occurs when the prime contractor unilaterally decides to electronically shut off “access” to its servers for any reason (or no reason at all), thereby preventing the program office from using, releasing or disclosing that technical data or computer software outside the Government—irrespective of whatever restrictive markings (if any) the contractor affixed to any data deposited/uploaded into that IDE Repository.

The consequences of this unilateral decision is that program execution comes to a screeching halt when those personnel the program office intended to have “access” cannot “access” that data anymore to execute the program. Only then does the program manager realize that the parties “made this IDE up as they went along”—because prior to contract award and during contract performance, they never memorialized that concept in enforceable language and included that language into the RFP and resulting contract as required by DFARS 227.7108 and 227.7207, AFI63-101/20-101 paragraph 4.7.4.2, and AFPAM63-128 paragraph 11.11.2.1. With those catastrophic consequences in mind, the stage is now set for a discussion regarding what IDEs are and how the parties should memorialize that concept in the request for proposals and the resulting contract. That discussion begins with defining what is an “IDE”.

An IDE is a data storage and information management system. Its purpose is to create an environment of connected knowledge workers, in which the preferred approach to performing work involves instantaneously accessing data (including work-in-process data) required to accomplish the necessary tasks and then outputting the results into an instantaneously accessible form. It is the infrastructure that permits implementation of Product Life Cycle Management as it integrates the people, processes, business systems, and information associated with the design, development, production, deployment, maintenance, sustainment, and disposal of a weapon system over its entire life-cycle. Under this construct, information sharing is rewarded and redundant data development, transmission or storage is frowned upon.

The IDE can either be a program-unique repository run by Government personnel on a Government server, a program-unique repository run by a contractor on its own servers, or an existing Government enterprise repository on a Government server (e.g., Military Engineering Data Asset Locator System (MEDALS), Joint Engineering Data Management Information and Control System (JEDMICS)). Key functions of IDE support include:

  • Product data management: Storing and managing all information about the weapon system throughout its life-cycle.
  • Configuration management: Tracking and managing all configuration changes.
  • Collaboration: Supporting virtual teaming and common access to team work products.
  • Design analysis and tradeoff studies: Evaluation of different design concepts and decisions made on selected designs.
  • Requirements traceability: Relationship between user requirements, weapon system technical requirements, design capabilities, and test results.
  • Logistics support analysis and planning: Leveraging design information to perform logistics analysis and planning activities that will positively influence weapon system reliability, maintainability, and supportability.
  • Long-term data access and controls.

The Defense Acquisition Guidebook states that to the greatest practical extent, programs should use existing Government enterprise IDEs; program-unique IDEs are disfavored due to high infrastructure cost and because multiple program-unique IDEs inhibit access, sharing and reuse of data across programs. Program-unique IDEs may violate 40 U.S.C. § 11312, which requires that the heads of executive agencies identify information system investments that would result in shared benefits or costs for other federal agencies for “national security systems” to the extent practicable. Program-unique IDEs may also violate Section 2867 of the NDAA for FY 2012 (Pub. L. No. 112-81), that prohibits the obligation of funding for a “data server farm” or “data center” unless approved by the Chief Information Officer of the Department of Defense. In contrast, program-unique IDEs are encouraged by the DoD Open Systems Architecture Contract Guidebook for Program Managers.

If after analyzing the statutory restrictions summarized in the preceding paragraph the program office concludes that neither restriction precludes the creation of a program-unique repository run by a contractor on its own servers, the program office must carefully determine what will be its Concept of Operations for that IDE. Like Julius Ceasar’s Gaul, the IDE will consist of three parts:

  • The environment consisting of a web-based platform,
  • The data residing within that environment, and
  • The IP rights the contractor will grant to the program office to the environment as well as to the data that will reside within that environment.

2. How To Properly Implement That Concept In An RFP

Although the parties may allocate the terms and conditions in a contract that must memorialize each of the parts of an IDE to different sections of the RFP consistent with the UCF, that approach is not particularly user-friendly. The reason why is because it assumes that a user of the contract years hence will be able to find all those proverbial “needles-in-the-haystack” scattered throughout the contract and be able to put them together in an integrated—pun intended—fashion in order to understand how all those terms and conditions relate to each other.

Therefore, a program office should only use that approach if each section of the contract that discusses a topic relating to the IDE will cross-reference all other relevant sections of the contract. In the alternative, all of those terms and conditions may be located in a single location in the contract. That approach has the benefit of making it easier for any user of the contract years hence to find quickly those terms and conditions. That is the approach discussed below.

Invariably, each offeror will have their own unique proposed IDE that it believes will best satisfy the program office’s needs, and one offeror’s proposed IDE may be technically superior to another offeror’s proposed IDE. It is therefore inadvisable for program offices to include into Section L of the RFP a requirement that offerors submit proposals against a “cookie-cutter” IDE. Conversely, the program office needs to accurately identify its IDE requirements in order to comply with a fundamental principle of government contracting stated above: In a competitive environment an RFP must provide for the submission of proposals based upon a common understanding of the agency’s requirements.

Accordingly, the program office must identify in Section L of the RFP what additional CDRLs the offeror must deliver to implement its proposed IDE and what IDE-related topics the offeror must address in an Appendix to the Section J IP Rights Attachment to its Model Contract. The program office must also identify in Section M of the RFP what evaluation criteria it will use to determine the technical acceptability of each offeror’s unique proposed IDE relative to the three concepts described above.

Therefore, Section L should require offerors to submit the following documents as part of their proposed Model Contracts:

a. Exhibit A.

Offerors should be required to submit the following four CDRLs, tailored consistent with their unique solution:

(1). A Software Product Specification (SPS) (DI-IPSC-81441A). The purpose of this CDRL is to require the offeror to deliver the computer software needed to instantiate the “environment”. It should require delivery of the source code to any modifications the offeror intends to make to any commercial computer software (e.g., Microsoft SharePoint®) to create the IDE. If the program office will not be procuring those commercial computer software applications under separate contracts, this CDRL should also require the delivery of the executable code to those commercial computer software applications.

(2). A Software Version Description (SVD) (DI-IPSC-81442A). The purpose of this CDRL is to release, track and control software versions for configuration control purposes. In other words, it identifies all versions of commercial computer software the offeror intends to use to create the IDE, as well as all modifications the offeror intends to make to those software applications to customize the IDE for that specific acquisition program.

(3). A Database Design Description (DDD) (DI-IPSC-81437A). The purpose of this CDRL is to describe the design of the database that comprises the IDE. In other words, it provides the Government with a textual description of the IDE instantiation (i.e., the file folder structure/hierarchy, levels of access rights and privileges specified at the user level (e.g., administrator, guest, super-user) and at the data/deliverable level (e.g., ability to allow access to specific data/deliverables to selected users only based upon the classification level and level of IP rights associated with that data) into which the “data” will be deposited, search functions). The program office will then be in a position to carefully review and approve that structure to ensure that authorized users, who will create the data deposited into that IDE, will know precisely in which sub-sub-sub-subfolder they should deposit that specific document and so that authorized users can quickly find that proverbial “needle in the haystack”. If the program office does not mandate that disciplined approach from the date of contract award, during contract performance authorized users will create their own sub-sub-sub-subfolders and deposit data into those locations—making it virtually impossible for many other authorized users to find a specific document, and thereby defeating the purpose for which the IDE was created in the first place.

(4). A DAL (DI-MGMT-81453A). The purpose of this CDRL is to list all data the offeror will create during contract performance, including all “work-in-progress” data that will reside on the IDE.

b. Appendix B to Section J IP Rights Attachment.

Section L should require the offerors discuss the following topics in their proposed Appendix B:

(1). Purpose. In this subsection, the offeror shall insert a short statement that describes the purpose of the IDE—to provide a structured electronic collaborative environment the offeror will develop and maintain that will permit all contractor, subcontractor, government personnel, and advisory and assistance services contractors the ability to cost-effectively and securely create, view, annotate, manipulate, deposit/upload, retrieve/download, and exchange all data between those personnel created and utilized by those personnel during the period of performance of the contract.

(2). Definitions. In this subsection, the offeror shall define all terms used in this Appendix to the Section J IP Rights Attachment. Next, the offeror shall describe the software architecture of the “environment” into which the “data” will reside in both a narrative manner as well as in a pictorial depiction so that the reader can understand the relationship between the SPS, SVD, DDD, and DAL CDRLs. As stated in Section V.B.2.b.(1).(h). of this Handbook, the term “access” is vague. Accordingly, the offeror shall define that term in this subsection (e.g., the ability to view, print, download, annotate, and interact with all modified or archived versions of any data residing on the IDE), along with all other relevant terms (e.g., “IDE”, “authorized user”).

(3). Requirements. In this subsection, the offeror shall discuss the following topics:

(i). What the minimum capabilities of the IDE will be (e.g., internet accessible by using a standard web browser application, navigation, data exchange, data interaction, error-checking protocols, archive library, error-checking protocols).

(ii). How the offeror will configure the IDE consistent with the relationship between the four CDRLs described above.

(iii). How the costs the offeror will incur to develop and maintain the “environment”—including the costs incurred to acquire the commercial software licenses and modify that software to create the “environment”—will be allocable to the contract. If, for example, the IDE will be supporting a single program, Section B of the offeror’s Model Contract should include a separate CLIN so that the program office will have visibility into how much it will be paying the offeror to develop and maintain that IDE for the entire period of performance of the contract. In contrast, if the IDE will be implemented via an advisory and assistance services contract supporting multiple ACAT I/II/III programs, it will probably be too unwieldy to acquire funding from those programs and then obligate that funding onto that CLIN on a regular basis. Accordingly, the offeror shall allocate the costs of developing and maintaining the IDE on an equitable basis to the CLINs under which the services are being provided to support the multiple programs in question.

(iv). As stated in the DoD Open Systems Architecture Contract Guidebook for Program Managers, “a requirement for an IDE is not a substitute for having formal technical data and software delivery requirements.” Accordingly, in this subsection the offeror shall identify all types of data that will reside on the IDE, including but not limited to all draft/work-in-progress data generated in performance of the contract, all data listed on the DAL, all data delivered under other CDRLs, and all data utilized in the performance of the contract that is not a CDRL listed in Exhibit A.

(v). In this subsection, the offeror shall state that all data it or its subcontractors deposit/upload into the IDE will be classified as “deliverables” when so deposited/uploaded, and that it will notify the designated Government officials by email when an item of data has been electronically deposited/uploaded into the IDE. It shall also state that as of the date of contact award the Contracting Officer has, pursuant to DFARS 252.227-7027 (Deferred Ordering of Technical Data or Computer Software) ordered all technical data and computer software that the contractor will list on the DAL during the period of performance of the contract. Accordingly, the offeror will electronically deposit/upload that technical data and computer software within a specified period of time after that data has been created.

(vi). In this subsection, the offeror shall explain what procedures it will develop and maintain to protect data delivered to or stored in the environment from unauthorized release or disclosure and to control the release of data from the environment to authorized users consistent with FAR 52.204-21 (Basic Safeguarding of Covered Contractor Information Systems), DFARS 252.204-7012 (Safeguarding Covered Defense Information and Cyber Incident Reporting), the program’s Security Classification Guide, and the Government’s IP rights in that data. Those procedures shall include an explanation of how the offeror will ensure that restrictive markings will be affixed to all such data consistent with the terms and conditions of the contract, who will be authorized to “access” the data residing on the IDE consistent with the contractor’s proposed DDD CDRL—including any authentication procedures the contractor will implement to control “access” (e.g., various levels of access rights and privileges specified at the user level (e.g., administrator, guest, user, super-user) and at the data/deliverable level (e.g., ability to allow access to select users only)—and how those authorized users will obtain “access”. This subsection shall also state that the contracting officer will provide the contractor with the names of authorized users and the level of access authorized for each user.

(vii). If necessary, this subsection shall describe how the offeror will obtain use and non-disclosure agreements from all non-government employees to whom data will be released or disclosed if that data will be delivered with less than Unlimited Rights if the recipients’ contracts do not contain DFARS 252.227-7025.

(viii). In this subsection, the offeror shall identify during what periods authorized users will be able to “access” the data residing on the IDE (i.e., 24 hours per day, seven days per week, 365/366 calendar days per year), under what enumerated conditions authorized users will not be able to “access” that data (e.g., previously scheduled maintenance), and the maximum number of authorized users the IDE will be able to support simultaneously.

(ix). In this subsection, the offeror should state that it will deliver the SPS, SVD, DDD, and all data listed on DAL CDRLs that comprise the IDE.

(x). In this subsection, the offeror should state that, pursuant to DFARS 252.227-7027, it will image the IDE—both the “environment” as well as the “data” residing within that “environment”—and deliver that instantiation to the Contracting Officer upon request. The purpose of this section is to ensure that, well prior to contract closeout, the program office receives a copy of the IDE. The program office will then be able to include that IDE into the Bidders’ Library for the follow-on competitive acquisition, and provide that IDE to the awardee of that follow-on contract to sustain the weapon system(s) for which the IDE was established in the first place.

(xi). In this subsection, the offeror should indemnify, save, and hold harmless the Government, and its officers, employees, agents, and representatives acting for the Government, against every claim or liability, including costs and expenses resulting from or as a consequence of, an unlawful release or disclosure of any item of data via the IDE.

(xii). If the offeror will be depositing into the IDE final versions of data the contract requires to be delivered as CDRLs, in this subsection the offeror should describe how that data will be received, inspected and accepted by the program office.

(xiii). In this subsection, the offeror shall identify what training (e.g., classroom, on-line) and help desk support it will provide to authorized users of the IDE.

(4). Remedies. Congress has not granted any court the power to order a contractor to reinstate “access” to authorized users of the IDE where, e.g., the contractor has unilaterally shut off access. Nor can the parties to a government contract confer that power upon any court. Since such an agreement between the parties would be illusory, the program office should instead require the offeror propose a monetary remedy. (Given the ubiquitous establishment by DoD contractors of IDEs on behalf of program offices over the years, a contractor’s IT department should be in possession of sufficient information to estimate with a reasonable degree of accuracy what would be the duration of outages due to, e.g., previously scheduled maintenance.) The amount of that monetary remedy should be proportionate to the importance to the program office of that IDE to its need to (1) monitor the performance of the offeror and its subcontractors of the contract in real-time, and (2) acquire an image of that IDE upon request. This section shall also identify any circumstances under which the offeror will not be liable to the Government if unauthorized users are unable to “access” the “data” residing within the “environment” (e.g., previously scheduled maintenance).

(5). Restrictive Markings. This section shall state that, unless otherwise expressly authorized by the contract, the offeror shall not affix any nonconforming restrictive marking (e.g., “proprietary”, “competition sensitive”) to any data it or its subcontractors deposit/upload into the IDE. It shall also state that the contracting officer will resolve any nonconforming or unjustified markings on any data the offeror or its subcontractors affix to any data deposited/uploaded into the IDE in accordance with DFARS 252.227-7013 (Rights in Technical Data—Non-Commercial Items), DFARS 252.227-7014 (Rights in Computer Software—Non-Commercial Items), DFARS 252.227-7019 (Validation of Asserted Restrictions—Computer Software), and DFARS 252.227-7037 (Validation of Restrictive Markings on Technical Data).

(6). IP Rights. The preceding discussion has described how to memorialize in enforceable contract language two of the three essential parts of an IDE: The environment (i.e., the contractor data repository itself) and the data that will reside within that electronic repository. Accordingly, this subsection should identify the third part of an IDE, namely, what IP rights the offeror will grant to the program office to all data that will reside within that environment.

To that end, in this section the offeror shall “map” what IP rights it will grant to the SPS (that requires the delivery of the software applications that comprise the integrated digital/data environment), SVD (that identifies all versions of that software that create that environment), DDD (that identifies the file folder structure/hierarchy of the IDE), and DAL CDRLs. This section shall also state that the Government will acquire IP rights to all draft/work-in-progress technical data and computer software equivalent to the IP rights it will receive to the final product, that the Government will acquire Unlimited Rights to all data listed on the DAL, that the IP rights the Government will acquire to all data delivered pursuant to a CDRL listed in Exhibit A are described in the IP Rights Attachment, and what IP rights the Government will acquire to all noncommercial technical data and computer software, and all contract administration data, utilized in the performance of the contract that is not a CDRL deliverable that the offeror or any of its subcontractors deposits/uploads into the IDE.

(7). Identification of commercial technical data, computer software, and computer software documentation. In this section, the Offeror shall create and populate Tables 4 (which lists all commercial technical data, computer software, and computer software documentation the offeror will use to create the IDE) and 5 (which lists all commercial technical data, computer software, and computer software documentation the offeror will deposit/upload into the IDE that is not listed in Table 2 of its IP Rights Attachment). The format of those tables—and its corresponding Section L instructions for filling-in those tables—will be the same as for Table 2 described in Section V.D.5.g.(2) above. This section shall also state that the offeror shall not add, delete, or replace any such data it or any of its subcontractors deposit/upload into the IDE unless the contract has been modified to delete or replace the applicable license(s) from Appendix B of the IP Rights Attachment. The content of that Appendix B—and its corresponding Section L instructions—will be the same type of content as that contained in Appendix A.

In sum, the program office must memorialize the IDE product baseline in an Appendix to the Section J IP Rights Attachment that describes the environment, all data that will reside within that environment, and the IP rights the Government will acquire to all data that will reside within that environment. To achieve this objective—and to evaluate during source selection offerors’ proposed CDRLs and Section J IP Rights Attachment Appendix—the Contracting Officer will need the assistance of three types of acquisition professionals:

  • Program office personnel who will be using the IDE (e.g., program managers, engineers, product support personnel, supply chain personnel, quality assurance personnel, life-cycle logisticians, engineering data managers).
  • Information technology professionals familiar with the capabilities of the software applications that will constitute the IDE.
  • Program attorneys possessing extensive government contract transactional and trial experience who can memorialize the environment, the data that will reside within that environment, and the IP rights to the data that will reside within that environment in enforceable contract language understandable by those possessing only a high school degree.

As suggested by the complexity of the above discussion, this is not a job for amateurs.

F. Prior to Final RFP Release

In accordance with FAR 15.201, in order to foster transparency with its industry partners the program office should release a draft RFP and invite potential offerors to submit written comments on the IP provisions contained therein. The program office should also convene an Industry Day, Pre-Proposal Conference, or both, devoted solely to IP rights, and ensure that potential offerors’ in-house counsel attend. During that/those events, the program office should brief potential offerors on the following topics:

  • The IP rights provisions in the RFP; e.g., asking potential offerors what specific portions of Section M contain evaluation criteria that explain how the Government will evaluate IP rights proposed by offerors.
  • The pedigree of those provisions; e.g., the Government concluded that its minimum needs for IP rights to CDRL A0XX is Unlimited Rights because the CDRL contains data necessary for OMIT purposes, the Government concluded its minimum needs for IP rights to CDRL A0YY is Government Purpose Rights because the program’s CDD required the program acquire that type of IP rights to that deliverable.

By implementing this two-pronged approach, the program office will have:

  • Conducted appropriate market research by giving potential offerors the opportunity to raise—and hopefully resolve—their legitimate concerns while educating them regarding the program office’s minimum needs, and
  • Reduced the potential for bid protests regarding those RFP provisions.

For example, the RFP may have indicated that the program office’s minimum needs include acquiring Unlimited Rights to CDRL A0XX that contains form, fit, and function data as the Government is entitled to receive pursuant to 10 U.S.C. § 2320. In response, a potential offeror might point out to the program office that that CDRL also requires the delivery of detailed manufacturing process data it developed exclusively at private expense. Upon becoming aware of this fact, the program office might realize that, although it needs delivery of that detailed manufacturing process data, it does not need to acquire Unlimited Rights to that technical data. Therefore, the program office may decide to solve this problem by first deleting the requirement for delivery of such technical data under CDRL A0XX (while retaining the form, fit, and function information in that CDRL and its associated Unlimited Rights license). Next, the program office would move the requirement to deliver that detailed manufacturing process data to a new CDRL (CDRL A0YY)—and then acquire Limited Rights to CDRL A0YY to accommodate that potential offeror’s reasonable concerns while at the same time satisfying the Government’s (revised) minimum needs.

In a similar manner, a program office could split up technical data contained within a particular CDRL that describes multiple subsystems into multiple CDRLs based upon the weapon system’s WBS, so that each CDRL describes only that technical data associated with a particular major system, subsystem, or component. In either case, the result will be the same in that one of the steps described in Section V.B.2.b.(1).(g).(ii). above will still be satisfied: The program office will have baselined all contents of a specific CDRL to a single level of IP rights to the maximum extent practicable.

G. During Source Selection

1. General Guidance

Upon receipt of offerors’ proposals, the SSEB should evaluate those proposals in accordance with the Sections B/I/J/K/L/M/Exhibit A provisions described above. If the SSA establishes a competitive range and opens discussions, the SSEB should have discussions with offerors regarding any weaknesses, significant weaknesses, or deficiencies in their proposal regarding this matter. If an offeror asserts that it will be delivering a particular CDRL with less than the minimum level of IP rights specified in Section L, the SSEB may need to request that the offeror provide support for its position, amend the RFP to change the Government’s minimum needs, or notify the offeror that its proposal is technically unacceptable consistent with 10 U.S.C. § 2320 and the CICA. If the Government decides that its needs are different from those IP rights described in the RFP, the Contracting Officer must amend the RFP consistent with its revised requirements.

Occasionally, an offeror may “overachieve”. Specifically, the offeror may propose to deliver more content in a CDRL deliverable than is required by the DD Form 1423—but in so doing “underachieve” by proposing a lower level of IP rights in technical data and computer software than is required by the RFP because the offeror wants to restrict the use, release or disclosure of that additional content. The offeror, however, may not realize that by attempting to obtain a strength assessment under a particular Technical subfactor for proposing that additional content, it may very well have injected a feature into its proposal the program office would assess as a deficiency under a different Technical subfactor. The reason why is because the offeror is now proposing to deliver a lower level of IP rights in technical data or computer software than the RFP indicates are the program office’s minimum needs. There are at least two ways to fix this problem. First, during discussions, the Contracting Officer can suggest to the offeror that it delete that additional proposed content and propose to deliver technical data and computer software IP rights consistent with the program office’s minimum needs specified in the RFP. In the alternative, if the program office believes that additional content is necessary, the Contracting Officer must amend the RFP to require delivery of that additional CDRL content and if necessary modify the level of technical data and computer software IP rights identified as the Government’s minimum needs for that CDRL.

2. Specific Guidance

FAR 15.308 states that the SSA must base their award decision on a comparative assessment of proposals against all source selection criteria in the RFP. Since this general principle applies to the acquisition of technical data and computer software IP rights, the SSEB must analyze whether all portions of the offeror’s proposal are consistent with each other insofar as the level of rights in technical data and computer software proposed are concerned. Assuming the SSEB has structured its RFP in a manner similar to that described above, the following decision tree will assist the SSEB in completing an integrated assessment of an offeror’s proposed MOSA and IP rights offering:

a. Evaluating the Offeror’s Technical Approach

(1). To determine the extent to which the offeror’s technical approach is based upon MOSA principles, for all supply and services acquisitions, carefully review the offeror’s proposed WBS in its Contract Volume to identify what major system components are identified in that proposed WBS and the extent to which the offeror’s technical approach as described in its Technical Volume is consistent with the program’s SEP. Next, the SSEB should determine what major system interfaces—between the major system platform and a major system component, between major system components, and between major system platforms—the offeror identifies in its Contract Volume and discusses in its Technical Volume to determine the extent to which those interfaces will contain physical, logical, and functional characteristics sufficient for a competitor to be able to incrementally add, remove, or replace major system components throughout the life-cycle of that major system platform.

(2). For software-intensive supply acquisitions, carefully review the offeror’s SAD contained in the Technical Volume of its proposal. Understand which major system components (in this case, software items or software units)—including OSS—reside in which locations of the offeror’s proposed architecture and the purposes (functionality) for which those components are being used in that architecture (e.g., during development, in delivered code, and for use on which systems and in which geographic locations). Create a list of those components for use when completing step (9) below.

(3). Verify that all text in the offeror’s IP Rights Attachment (see Appendix A (“Relevant Excerpts from GPS IIIF RFP”) Attachment 5) contained in the Contract Volume of its proposal is identical to that contained in the IP Rights Attachment in the RFP.

(4). Verify that the offeror has properly filled-in all cells in Tables 1 and 3 in its IP Rights Attachment and determine whether the noncommercial IP rights proposed in Table 1 satisfy the program office’s minimum needs as specified in Section L of the RFP.

(a). Evaluate whether the proposed IP rights contain any deficiencies.

The following explanation of how the Government would determine whether the offeror’s proposal satisfies the Government’s minimum needs is based upon the provisions in Appendix A of this Handbook. In that case, Section M-4.2.4.3.a of the RFP included in Appendix A states the Government will evaluate the extent to which the offeror’s proposed IP rights meet the Government’s minimum needs as specified in the RFP. Accordingly, offerors should first carefully read Section L-6.3.4.1.6.b of that RFP, which stated the pedigree of the Government’s minimum needs and directed the offeror’s attention to the IP Rights Attachment of that RFP in Section J (i.e., Attachment 5). In turn, Table 1 of Attachment 5—when read in conjunction with Section L-6.3.4.1.6.a.1)—states the Government’s minimum license needs for, e.g., CDRL A010 (Interface Control Documents/Interface Specifications) are Unlimited Rights.

The GAO has held that clearly delineated solicitation requirements constitute a minimum need of the Government, that clearly stated solicitation requirements are considered material to the needs of the Government, and that a proposal that fails to conform to material terms and conditions of the RFP with respect to the Government’s stated need for “IP rights” is unacceptable and cannot form the basis for award. Section M-4.1.1.b.2) of the RFP in Appendix A of this Handbook restates the definition of a “deficiency” lifted from FAR 15.001: A material failure of the proposal to meet a Government requirement. And Section M-4.2.4.3.a.2) of that RFP stated that the Government would assign a “deficiency” assessment each time an offeror proposed to deliver IP rights to any technical data that constituted, e.g., form, fit, and function data. Since CDRL A010 contains that type of technical data, the provisions in that RFP have put all offerors on express notice of precisely what will happen if an offeror proposes to deliver a lower level of IP rights than Unlimited Rights to CDRL A010 to the Government: The Government will assess that feature of the offeror’s proposal associated with Section M-4.2.4.3.a evaluation criteria as a deficiency.

Section M-4.1.1 Table 2 of that RFP states that any deficiency in the offeror’s proposal will result in the Government assigning a “Red/Unacceptable” rating to that aspect of the offeror’s proposal under the Technical Subfactor in which various evaluation criteria is located (in this case, Subfactor 4 (Program Management)), thereby rendering that proposal unawardable. Accordingly, the offeror’s business decision to propose to deliver to the Government anything less than Unlimited Rights to CDRL A010 will render that offeror’s proposal unawardable on that basis alone irrespective of whether the SSA’s tradeoff analysis would have resulted in that offeror becoming the awardee based upon its otherwise technically superior approach or its comparatively lower MPC.

In short, these provisions of the RFP contained in Appendix A foster transparency between the program office and its industry partners regarding precisely what will be the ramifications of the offeror’s decision to propose less than Unlimited Rights to CDRL A010. This assumes, of course, that the offeror has asked their in-house counsel to review those provisions prior to drafting their proposal—and that in-house counsel has carefully reviewed those provisions.

(b). Evaluate whether the proposed IP rights contain any flaws.

Even if the offeror’s proposed licenses satisfy the Government’s minimum needs—i.e., they do not contain any deficiencies similar to that described above—those licenses may contain various flaws that increase the risk of unsuccessful contract performance. In general, there are two types of flaws: (1) weaknesses, defined as a flaw in the proposal that increases the risk of unsuccessful contract performance, and (2) significant weaknesses, defined as a flaw in the proposal that appreciably increases the risk of unsuccessful contract performance. (Section V.G.2.a.(8) of this Handbook provides examples of such flaws.) FAR 15.306(d)(3) requires that the Government identify such flaws in an offeror’s proposal and then—if the SSA decides to establish a competitive range and conduct discussions—bring the existence of significant weaknesses (and deficiencies) to the offeror’s attention during discussions.

(5). Verify that the licenses for all commercial item or COTS software applications described in the offeror’s proposed SAD are included in the appendix to the offeror’s IP Rights Attachment.

(6). Verify that the offeror has mapped all commercial item or COTS licenses to the proper CDRLs and CLINs in Table 2 of that Attachment.

(7). Analyze whether the proposed “commercial item” or “COTS” is truly a “commercial item” or “COTS.” The Government is required to acquire commercial items or COTS items if those items satisfy its needs. As a result, some offerors may claim that a certain item of technical data or computer software it proposes to deliver as part of a CDRL is a “COTS” item, a “commercial item”, or “commercial computer software” such that the program office should accept the terms and conditions of the proposed commercial license. Before agreeing with the offeror, the SSEB should carefully determine whether the technical data or computer software the offeror proposes to deliver with various use, release disclosure restrictions in the proposed license is in fact a “COTS” item, a “commercial item”, or “commercial computer software” by using the definitions of those terms and the questions provided in Section II.D of this Handbook. The danger of the SSEB agreeing with the offeror’s determination that the technical data or computer software is in fact a “COTS” item, a “commercial item”, or “commercial computer software” without carefully analyzing the pedigree of that determination is that the program office may agree to commercial license restrictions when in fact it should have agreed to a noncommercial license (e.g., Unlimited Rights).

If after performing the analysis described in Section II.D of this Handbook the SSEB concludes that portions of the technical data or computer software in the deliverable do not satisfy the definition of a “COTS” item, a “commercial item”, or “commercial computer software”, consistent with MOSA principles, the SSEB should then ask the offeror whether the major system components (in this case software items or software units) that will contain those portions are physically segregable from those portions that do satisfy any of those definitions. If so, the program office should acquire the standard commercial license to those portions that satisfy any of those definitions and an appropriate noncommercial license (e.g., Unlimited) to the major system components that do not satisfy any of those definitions. To ensure releasability of all portions of the major system component to the same entities for the same purposes for the same period, the scope of those licenses must be identical to each other. If, however—in contravention of MOSA principles—the offeror failed to physically segregate major system components that satisfy any of those definitions from major system components that do not satisfy any of those definitions, the program office should acquire an IP license (or licenses) to all portions of the deliverable the scope of which are identical to each other, in order to satisfy its minimum use, release, and disclosure needs.

(8). Carefully read each COTS license to determine whether it will satisfy the program office’s needs and whether any terms or conditions in the license are inconsistent with Federal procurement law. If they are not, the SSEB must point out that fact to the offeror during discussions and modify the order of precedence clause in the IP Rights Attachment accordingly.

To assist the reader in understanding how this concept applies, consider the following examples. A license provision that would violate federal criminal laws—e.g., those that apply to the dissemination of classified information—would be one that states that foreign persons will perform software maintenance of a commercial software application. The reason why that provision would violate Federal procurement law would be because, according to the offeror’s proposed SAD, that software application will reside in a Sensitive Compartmented Information Facility (SCIF)—which therefore means the resulting contract will contain a patent (obvious) ambiguity because the DD Form 254 (“Department of Defense Contract Security Classification Specification”) in the offeror’s proposed Contract Volume will prohibit foreign persons from entering that facility.

In a similar manner, we provide for the reader’s consideration the following four examples of license provisions that would be incompatible with user needs:

  • A provision that states that the customer may only use the commercial software application in the country where purchased when, according to the offeror’s proposed SAD, that application will be embedded into a weapon system that will be installed in countries other than the U.S.
  • A provision that requires the customer to remove, uninstall, and return software to the contractor if the program office breaches the terms of the license. Compliance with those provisions could very well require the Air Force to declare a space vehicle non-operational so that the Air Force will be in substantial compliance with those terms/conditions since it may not be physically possible to uninstall and return that software to the contractor given the orbits within which those space vehicles reside. With respect to a control segment, since removal is physically possible, the Air Force would have to declare that system non-operational until the situation was resolved either by (1) obtaining the contractor’s permission to continue using the software, or (2) requiring the contractor to replace that software application with another one along with an appropriate license for that application. Such a provision should be nullified in the resulting contract prior to award such that the contractor’s and—if the software application was licensed from a subcontractor—its subcontractor’s remedy for that breach will be limited to monetary damages (versus retaining language in the IP license that incorrectly states a court could issue an injunction against the Air Force ordering it to uninstall the software and return that software to the contractor).
  • A provision that states that functionality in the commercial item software inhibits operation of the weapon system within which that software resides (e.g., the periodic need to enter in a license code, the presence of a physical key or similar device to enforce licensing limitations). Such a provision would violate a compliance document—specifically, SMC-S-012, Appendix B, section B.2(5)(b)—which states that one criteria for evaluating reusable software products would be the lack of such functionality in the proposed reusable software product.
  • A provision that states the commercial software application is not designed or intended for use in weapon systems, for aircraft navigation purposes, or safety-of-life applications. Such a disclaimer may be nothing more than another example of our litigious society. On the other hand, it could be a warning to the program office that the developer has little faith in the stability and integrity of that software—in which case, why would the program office want to purchase it for use in those critical applications? The only way for an SSEB to determine whether that provision in the proposed license should be classified as a deficiency, weakness, or significant weakness would be to ask the following questions:
    • According to the offeror’s proposed SAD and SDD, at which locations in the contractor’s architecture will that software reside – on the periphery or at its heart?
    • Does the history of that software indicate it is sufficiently robust to satisfy the requirements in the performance specification/system requirements document and related compliance/reference documents?
    • If the SSEB initially determines the software is sufficiently robust prior to award, but after award the Government later determines that was not the case, how difficult will it be for the contractor to switch-out that software with a replacement or develop source code from scratch to overcome those inadequacies?

An offeror’s proposed use of OSS poses additional licensing issues that the SSEB must carefully analyze during source selection. For example, some OSS licenses (e.g., earlier versions of the GNU General Public License) require distribution of modifications to that OSS under the same terms as the license of the original software. If the program office wants the offeror to modify that software to perform successfully the contract, it would not be possible to comply with those license terms for to do so might violate Federal procurement law (e.g., export control laws, the program’s Security Classification Guide).

(9). Evaluate the offeror’s DFARS 252.227-7017 certification/representation.

If Section L of the RFP only permitted offerors to insert the phrase “See Attachment X” (“X” identifying the IP Rights Attachment) and sign the representation as recommended above, that provision will be consistent with that Attachment. If, however, Section L permitted offerors to include assertions in that provision, those assertions deserve heightened scrutiny by the SSEB.

The reason why is because, the offeror’s offer will inevitably incorporate by reference FAR 52.204-19 (Incorporation by Reference of Representations and Certifications) and FAR 52.215-8 (Order of Precedence—Uniform Contract Format). While the former clause incorporates by reference into the contract all of the offeror’s completed Section K provisions, the latter clause states that where a conflict exists between the Offeror’s completed Section K provisions (including DFARS 252.227-7017) and a Section J attachment (like the IP Rights Attachment), the Offeror’s completed Section K provisions take precedence.

In other words, if any of the offeror’s assertions relates to an item of technical data or computer software any CDRL in Exhibit A requires to be delivered to the Government, the contract will permit the offeror to affix the restrictive markings described in its DFARS 252.227-7017 certification/representation to portions of that CDRL notwithstanding the IP licenses the offeror’s IP Rights Attachment stated it would deliver to all content to be delivered as part of that CDRL. Accordingly, it is imperative that the SSEB carefully evaluate whether (1) the offeror followed to-the-letter the Section L instructions provided above for such situations, and (2) the offeror’s assertions are consistent with its completed IP Rights Attachment.

b. Evaluating the Offeror’s Proposed Costs/Prices

As stated at the beginning of this Handbook, the development and acquisition of IP requires money. That fact brings us to the subject of how the SSEB should evaluate an offeror’s proposed costs/prices for the technical data, computer software, and contract administration information it will deliver to the Government as well as its proposed costs/prices for the rights to that IP contained in that offeror’s Cost/Price Volume.

The GAO has held that, where an offeror fails to propose a price where the RFP requires a price be proposed, that failure to conform to material terms and conditions of the RFP means the proposal is unacceptable and may not form the basis for award. Therefore, if the RFP requires offerors to propose a price for the technical data, computer software, and contract administration information they will deliver to the Government as well as the IP rights they propose to deliver to the Government to that IP, the SSEB must determine whether the offerors have done so. The extent of that evaluation depends in great part upon whether the RFP required offerors to propose IP and associated license rights under cost-reimbursable CLINs or firm-fixed-price CLINs.

If the RFP required the offeror to propose pricing for those items under fixed-price CLINs, the SSEB must verify that the offeror has done so in its IP Rights Attachment and in Section B of its proposed Model Contract. In contrast, if the RFP requires the offeror propose the costs of those items under a cost-reimbursable CLIN (or CLINs), the SSEB must verify that the offeror has proposed costs in the Basis of Estimates (BOE) the offeror proposed in its Cost/Price Volume for both CLINs—which presumably are associated with the identical software applications described in its SAD. The SSEB must then perform a cost realism analysis of the offeror’s proposed costs for those CLINs costs and make upward adjustments to the offeror’s proposed costs, if appropriate. The SSEB should also verify that the costs proposed in the offeror’s Cost/Price Volume are identical to those proposed in its IP Rights Attachment.

In addition, the SSEB should determine the fairness and reasonableness (and if necessary, the price/cost realism) of the proposed cost of the data itself in addition to the cost/price of the IP rights to that data. As indicated in Sections V.D.2. and V.D.5.g., the proposed cost of the data may be obtained by adding all amounts the offeror has identified in Block 18 of each proposed CDRL.

If after receipt of initial proposals the program office realizes that a particular CDRL will be expensive and in retrospect does not need that CDRL, after the SSA establishes the competitive range the Contracting Officer can amend the RFP to delete that CDRL from Exhibit A. In a similar fashion, if after award the program office decides it made a mistake and no longer needs the CDRL, it can request a deductive change proposal from the contractor to delete that CDRL from the contract. To be sure, negotiations between the parties must commence with the current estimates of what the cost would have been to produce that CDRL—not the original proposal estimates the contractor typed into BLK 18 prior to award. Nevertheless, a contractor’s deductive change proposal that asserts the current cost of that CDRL is far less than what it proposed—especially if only a short period has elapsed between the date of award and the date the Government receives the contractor’s deductive change proposal—would arguably lack credibility.

This final part of the SSEB’s evaluation is not complete, however. The reason why is because the GAO has repeatedly held that an evaluation of an offeror’s technical approach must be consistent with its cost/price evaluation. What that means in this case is that the SSEB must ensure that its evaluation of the offeror’s proposed licenses described in its Technical and Contracts Volumes is consistent with its evaluation of the offeror’s proposed costs/prices in its Cost/Price Volume.

Accordingly, after assigning a weakness or significant weakness to that aspect of an offeror’s Technical Volume associated with a proposed IP license the SSEB concludes contains flaws that increase or appreciably increase the risk of contract performance, the SSEB may need to—in the case of cost-reimbursement contracts—“dollarize” those weaknesses or significant weaknesses and then adjust upward that offeror’s proposed cost contained in its Cost/Price Volume to account for the risk of unsuccessful contract performance those restrictions impose on the Government’s ability to use, release, or disclose that technical data and computer software outside the Government. SSAs would then use those discriminating assessments and resulting adjectival ratings, along with (if applicable) the SSEB’s MPC resulting from upward adjustments to offeror’s proposed costs contained in the offeror’s Cost/Price Volume to complete their tradeoff analysis consistent with the relative ranking of evaluation factors in Section M of the RFP to decide which offeror’s proposal represents the “best value” to the Government. (In contrast, if an RFP requires the agency to perform a price realism analysis in order to award a fixed-price-type contract, FAR 15.404-1(d)(3) prohibits the agency from “dollarizing” weaknesses and significant weaknesses and adjusting upward offerors’ proposed prices.) Given these GAO bid protest decisions, it would be inappropriate to contend that “dollarizing” weaknesses or significant weaknesses in such a manner and then adding the results of those upward adjustments to the SSEB’s most probable cost calculations constitutes improper “double-counting”—for an agency is not precluded from considering an element of a proposal under more than one evaluation criterion where the element is relevant and reasonably related to each criterion under which it is considered.

H. Sole Source Contracts

1. Establish Data and IP Rights Requirements

As one commentator has recently stated,

“[t]he starting point in any valuation is to carefully define the property being appraised, requiring clear boundaries and an understanding of the [IP] rights included and excluded from the valuation. This may seem like a trivial distinction, but it is not.”[27]

In other words, in order to establish its data and IP rights requirements, the program office should first use the same disciplined approach to drafting an acquisition strategy and the RFP described in Sections V.B-D for acquiring IP rights in technical data and computer software sole source as it would in a competitive environment. The reason why is because the proverbial horse must be put before the cart: The future benefits the program office will receive by acquiring that data and its associated IP rights cannot be quantified in terms of a fair and reasonable price until one first defines what that price is supposed to reflect.

2. Understand The Offeror’s Proposed System and Software Architecture

Irrespective of whether the offeror proposes to deliver noncommercial or commercial technical data or computer software, the program office should require the offeror to identify where—consistent with MOSA principles—each major system component to be delivered as part of the major system platform will reside as depicted in its proposed WBS, SSDD, SAD, and SDD. The reason why is two-fold. First, to facilitate mapping of licenses to deliverables for the reasons described above, if the offeror can prove it developed a particular major system component exclusively at private expense, the Government may need to (1) create a new CDRL requiring the delivery of items developed exclusively at private expense separate from the existing CDRL that requires the delivery of all remaining components to be delivered as part of the major system platform, and (2) modify the Section J IP Rights Attachment so that it is clear what license(s) will apply to which software items delivered under which CDRL.

Second, the Government must ensure the offeror’s implementation of the funding rules was consistent with its proposed architecture. The reason why is because, if the offeror established an internal project charge code to allocate the cost of developing a particular item to an IR&D project but failed to use MOSA principles to segregate that item from all other items developed with mixed funding or developed exclusively at government expense in its architecture, it will be impossible for the offeror to partition all items delivered as part of the major system platform from each other as separate CDRL deliverables so that the appropriate markings are affixed to the appropriate parts of each deliverable. And if the offeror failed to develop its architecture using MOSA principles, the Government should take the position that in the aggregate the components to be delivered as part of the major system platform were developed with mixed funding—and therefore, the Government is entitled to receive Government Purpose Rights to all noncommercial technical data associated with those hardware components and all noncommercial computer software components that reside within that platform.

3. Justify The Award Of A Sole Source Contract

The Air Force Federal Acquisition Regulation Supplement (AFFARS) states that the contracting officer cannot issue an RFP to a sole-source offeror unless the appropriate official has approved a J&A authorizing the acquisition of supplies, services, or both, sole source. Although seven exceptions exist to the requirement to obtain full and open competition under the CICA, only one of those exceptions relates to the topic of IP rights in technical data and computer software. That exception applies when the DoD demonstrates the supplies or services required are available from only one or a limited number of responsible sources when it is likely that award to any other source would result in substantial duplication of cost to the Government that is not expected to be recovered through competition or unacceptable delays in fulfilling the agency’s requirements (FAR 6.302-1).

When attempting to rely upon that exception, some program offices assume that inclusion of a conclusory statement into their J&A such as “the IP rights are too expensive” will suffice to convince the approving official to sign that document. For various reasons, that assumption is incorrect. First, those statements are usually not supported by any rigorous analysis regarding (1) what specific items of technical data and computer software the program office is referring to, (2) what specific IP rights to those specific items of technical data and computer software the program office is referring to, or (3) the manner in which the program office calculated the value of those IP rights to those items of technical data or computer software. Second, FAR 6.302-1(b)(2) cautions that, although the existence of Limited Rights in data may make the supplies and services available from only one source, the mere existence of those IP rights does not in and of itself justify use of this exception.

In the alternative, some program offices assume that including other types of conclusory statements into their J&A like “the contractor refuses to sell IP rights to various items of technical data or computer software” will suffice. Based upon the holding in a recent CAFC decision, that assumption appears to be correct. In other words, if an owner of IP is unwilling to sell Government Purpose Rights to that IP sufficient for the Government to compete a follow-on acquisition, whatever may have been the potential increased costs that owner could charge for its IP or whether it could extract a “supra competitive price” is irrelevant. That holding merely reinforces the fact that a program office’s greatest leverage in acquiring sufficient IP rights to complete maintenance and sustainment for a weapon system exists when competing an EMD contract for the development of that system—assuming the program office carefully identified its minimum needs for IP rights and evaluated the IP rights proposed by offerors and their associated prices during source selection for that acquisition—than will probably ever be the case for the remainder of the life-cycle of that system.

In any event, if the program office intends to base its J&A in whole or in part upon the lack of IP rights in technical data and computer software sufficient to compete the acquisition of supplies and services needed by the program office, the J&A should include the following information consistent with the AFFARS J&A Template (March 2018), cited in AFFARS 5306.303-2(a)(http://farsite.hill.af.mil/vmaffara.htm):

a. Section V of the AFFARS J&A Template. J&As that are based upon a determination that the program office would incur a substantial duplication of cost were the supplies and services to be competed must include the rationale for the amount of cost that would be duplicated. Accordingly, this section of the Template should explain how the value of the technical data and computer software—and the associated IP rights—identified in Section IX of this Template is subsumed within the amount of duplicated cost identified in this section.

b. Section IX of the AFFARS J&A Template. Based upon the analysis performed consistent with Section III of this Handbook, this section of the Template should identify what specific items of technical data and computer software—and the associated IP rights—the program office would need to compete the acquisition of supplies and services sought to be procured. It should also describe the approaches the program office used to calculate the value of those IP rights associated with those items of technical data or computer software (see Section V.H.4.c. below), and identify what IP rights the program office procured under existing contracts (see Section V.B.2.e. above).

c. Section XI of the AFFARS J&A Template. This section of the Template must describe any actions taken or to be taken to foster competition for future acquisitions of the supplies or services being acquire. For example, if a follow-on competition is planned, the guidance provided for completing this section of the Template require the program office to

“state that the Government will attempt to acquire [IP] rights in technical data and computer software sufficient to compete follow-on acquisitions as a priced option in the contract action that is the subject of th[e] J&A, or (if applicable) state how the Government intends to challenge nonconforming markings on technical data and computer software delivered to it under previous contracts so those markings can be removed in order that the technical data and computer software may be used in support of a follow-on competitive acquisition. . . .”

As required by Implementation Directive for Better Buying Power 2.0, this section should also discuss how the program office will take advantage of Open Business Model (i.e., MOSA) practices to break vendor-lock to minimize future sole source requests. Finally, the program office should keep in mind that, in accordance with DFARS PGI 206.304(a)(S-70), if the planned actions described in this section are not completed, a subsequent J&A for the same supplies or services must be approved at one level above the approval authority for the previous J&A unless the previous justification was approved by the Senior Procurement Executive (SPE)(in which case the approval remains at the SPE level).

4. Negotiate A Fair And Reasonable Price For The IP Rights To Data

The program office should not commence negotiations over, or request pricing for, IP rights until the parties have arrived at a common understanding as to (1) the content of each CDRL the contractor will deliver, (2) the scope of the licenses that will apply to each CDRL, and (3) where each major system component to be delivered as part of the major system platform resides in the Offeror’s design of that platform. Once the parties have arrived at that common understanding, unless an exception applies to that acquisition, the offeror must provide certified cost or pricing data so that the Contracting Officer can determine the fairness and reasonableness of the proposed prices for the IP rights in technical data and computer software sought to be acquired.

FAR 2.101 defines “cost or pricing data”—whether certified or uncertified—as all facts that, as of the date of price agreement, or an earlier date agreed upon by the parties as close as practicable to the date of price agreement, prudent buyers and sellers would reasonably expect to affect price negotiations significantly. FAR 2.101 also states that that data are factual (not judgmental, although they include the data forming the basis for that judgment) and are “more than historical accounting data” as they are all facts that can be reasonably expected to contribute to the soundness of estimates of future costs and to the validity of costs already incurred. FAR 2.101 provides a non-inclusive list of type of cost or pricing data, e.g., vendor quotations, nonrecurring costs, data supporting projections of business prospects and objectives and related operations costs, estimated resources to attain business goals, and information on management decisions that could have a significant bearing on costs.

So what does this mean in the context of acquiring IP rights in technical data and computer software? It means that the contractor must provide cost or pricing data supporting its determination of the value of the IP rights to a specific item of technical data or computer software and—if the contracting officer will use that data to negotiate a fair and reasonable price for a noncommercial item the value of which exceeds $2,000,000—certify the accuracy, currency, and completeness of that data. Accordingly, we recommend that the contracting officer follow the process described below to obtain and then analyze that data in order to negotiate a fair and reasonable price for the specific level of IP rights to a specific item of technical data or computer software (e.g., CDRL) sought to be acquired. In this regard, the contracting officer may want to retain a third-party valuation analyst to verify the offeror’s valuation of that technical data or computer software. For further details, contact the National Association of Certified Valuators and Analysts (NACVA)(http://www.nacva.com/) or the Licensing Executives Society (U.S.A. and Canada), Inc. (http://www.lesusacanada.org/).

a. The contracting officer should require the offeror (or, if the owner of the IP in question is a subcontractor, its subcontractor) provide a copy of its written corporate policy for calculating the value of all IP in its corporate portfolio (e.g., patents, copyrights, trade secrets). The program office should also require the offeror to explain how it used that policy to calculate the value of the IP rights it proposes to deliver with the specific item of technical data or computer software at issue. If that policy exists but the offeror did not use that policy to calculate the proposed value, the program office should require the offeror explain why it did not use that policy in this case. If no such policy exists, the program office should require that the offeror affirmatively state that is the case.

b. The contracting officer should require the offeror (or subcontractor, if the owner of the IP in question is a subcontractor) provide a copy of all financial statements (consolidated balance sheets) that summarize the value of all IP in its portfolio irrespective of whether the offeror included those financial statements in any of its U.S. Securities and Exchange Commission (SEC) filings. The program office should then require the offeror to (1) identify where the value of all IP in its portfolio is contained in those financial statements or equivalent information (e.g., as intangible assets), and (2) explain how if at all it isolated the proposed price for the value of the IP rights it proposes to deliver with that specific item of technical data or computer software at issue from the total value of all IP within that portfolio reflected in the offeror’s financial statements (consolidated balance sheets) or equivalent information. If the former is not subsumed within the latter, the program office should require the offeror explain why that is the case.

If, however, the offeror does not summarize the value of all IP in its portfolio on its financial statements (consolidated balance sheets), the program office should require that the offeror explain why the offeror is apparently taking an inconsistent position: On the one hand, the offeror is proposing the Government pay it a potentially substantial price the offeror believes accurately reflects the value to the offeror to sell or otherwise furnish the rights to that IP to the Government. But on the other hand, the offeror’s financial statements upon which its prospective and current shareholders rely to make investment decisions completely ignore the value of that IP to the company.

c. The recent increase in mergers and acquisitions in the defense industry create an opportunity in certain situations for the Government to gain greater visibility into what an offeror believes is the value of a specific item of IP the Government now wants to procure than would otherwise be the case. The reason why is because the parties to a merger or acquisition must calculate a fair and reasonable price for the target company or asset being acquired and then, in accordance with Financial Accounting Standards Board (FASB) Accounting Standards Codification (ASC) 805-20-25 (Business Combinations; Identifiable Assets and Liabilities, and any Noncontrolling Interest; Recognition) and ASC 820 (Fair Value Measurements), allocate the purchase price among the monetary assets, tangible assets, intangible assets, and IP to be acquired.

What this means is that, as part of due diligence, all assets acquired in an acquisition—current assets, property, plant and equipment, IP[28], intangible assets (e.g., goodwill)—must be identified, valued, and allocated for accounting purposes. The relevance of that historical IP valuation to any future negotiation between the Government and the new owner of that IP would depend upon various factors, including but not limited to, (1) to what extent did the due diligence analysis establish (and provide the basis for) calculating the value of the specific item of IP the Government now wants to procure, (2) how long ago that due diligence was performed, and (3) how the parties agreed to structure the transaction in order to allocate the purchase price among classes of assets on Internal Revenue Service (IRS) Form 8594 (Asset Acquisition Statement) each party will submit to the IRS as part of their respective Federal income tax returns.

Accordingly, if an offeror proposing to sell or otherwise relinquish its rights in a certain item of IP it purchased from another company, the contracting officer should request that the offeror provide any due diligence analysis performed during the merger and acquisition process that calculated the value of all IP in the acquired company’s portfolio. The contracting officer should then require the offeror to identify where if at all it isolated (allocated) the value of the specific item of IP the Government now seeks to procure from the offeror from the value of all other IP in the acquired company’s portfolio.

We hasten to add that the offeror remains free to explain to the Government the weight (if any) the Government should give to that “historical accounting data” when determining the current value of that IP for purposes of the Government acquiring whatever type of IP rights it now seeks to acquire from the offeror. But given the definition of cost or pricing data in FAR2.101 provided above, it would be passing strange for an offeror to refuse outright to provide such data to the contracting officer during negotiations on grounds it is irrelevant. A reasonable inference could be drawn from such refusal that, if the offeror would have provided that IP valuation to the contracting officer, that valuation would have been adverse to the offeror’s position.

d. Valuation of IP is a very complex subject—and it becomes even more complicated when one attempts to calculate the value of noncommercial technical data and computer software developed for military applications for which the marketplace is at best limited. There is no statute, regulation, or policy applicable to DoD contracts mandating that the parties utilize a specific approach for calculating a fair and reasonable price for IP rights in technical data and computer software delivered under DoD contracts.

Over the years, the accounting profession has settled on three general methods of calculating the value of IP: The market approach, the cost approach, and the income approach. Accordingly, the contracting officer should use one of those three approaches to calculate the value of the IP rights sought to be acquired to specific items of IP. The discussion of those approaches—listed in descending order of preference for the reasons described below—is intended only to provide the reader with a very basic understanding and should not be considered a comprehensive treatment of this very complicated subject.[29]

(1). The market approach. This approach estimates a value based upon an analysis of the sales and prices of guideline technical data or computer software. To implement this approach, the program office would (a) determine the criteria for selecting comparable uncontrolled (arms’-length) transactions (CUT), (b) convert CUT prices to pricing metrics (e.g., price per drawing, price per line of code) that could be applied to the technical data or computer software at issue, (c) compare the CUT intangible assets to the technical data or computer software at issue, (d) select subject-specific pricing metrics derived from the CUT intangible assets, and finally (e) apply the selected pricing metric to the subject intangible asset to estimate a value.

This approach is particularly applicable where relevant CUT data exists. That data may be in the offeror’s possession or in Government or commercial databases (e.g., SEC filings, GSA Federal Supply Schedules, company press releases, analyst reports, news articles, trade or industry journals, scholarly or academic publications, court decisions, KtMINE©, Royalty Connection™, RoyaltySource®, RoyaltyStat® LLC, Licensing Economics Review, IPRA, Inc.). When establishing and applying pricing metrics, the program office should consider various elements of comparison like the scope of IP rights granted (e.g., geographic or territorial restrictions, duration, purpose restrictions), special financing terms or arrangements, the existence or absence of arms’-length conditions, economic conditions existing in the secondary market at the time the comparable transactions occurred, the industry within which the guideline intangible asset was used, who is responsible for continued development/commercialization/protection, and the inclusion of other assets in the sale or license of a portfolio of assets.

DFARS 215.404-1(b)(i) now states that, in the absence of adequate price competition in response to the RFP, pricing based on market prices is the preferred method to establish a fair and reasonable price for both commercial and noncommercial items. In other words, the market approach is the first one the parties should use to establish such a price. DFARS 215.401 defines the term “market prices” as current prices established in the course of ordinary trade between buyers and sellers free to bargain and that can be substantiated through competition or from sources independent of the offerors.

If information obtained through market research is insufficient to determine price reasonableness, the contracting officer shall consider information submitted by the offeror of recent purchase prices paid by the Government and commercial customers for the same or similar commercial items under comparable terms and conditions if the contracting officer is satisfied that the prices previously paid remain a valid reference for comparison.[30] If the offeror is unable to provide such information for both commercial and noncommercial items, the contracting officer should request the offeror submit information on prices paid for the same or similar items sold under different terms and conditions, prices paid for similar levels of work or effort on related products or services, prices paid for alternative solutions or approaches, and other relevant information. When evaluating this information, the contracting officer shall consider materially differing terms and conditions, quantities, and market and economic forces using the following factors:

  • Market prices
  • Age of data
    • Whether data is too old to be relevant depends on the industry, product maturity, economic factors, and various other considerations
    • Pending sales may be relevant if it is probable at the anticipated price and the sale could reasonably be expected to materially influence the contracting officer’s determination of price reasonableness.
  • Volume and compleness of transaction data: A sufficient number of transactions to represent the range of relevant sales to all types of customers, date, quantity sold, part number, part nomenclatures, sales price, and customer.
  • Nature of transactions: Terms and conditions, data, quantity sold, sale price, unique requirements, the type of customer, related agreements, warranties, key product technical specifications, maintenance agreements, and preferred customer rewards.

For both commercial and noncommercial items, the contractor shall also consider catalog prices if they are regularly maintained and supported by relevant sales data.

(2). The cost approach. FAR 15.404-1(a) states that cost analysis shall be used to evaluate the reasonableness of individual cost elements when certified cost or pricing data are required, and may be used to evaluate data other that certified cost or pricing data to determine cost reasonableness or cost realism when a fair and reasonable price cannot be determined through price analysis alone for commercial or noncommercial items. To that end, the cost approach calculates the cost to create an exact duplicate or replica of the technical data or computer software at current prices (“reproduction cost new”) less depreciation, the cost to create the functional equivalent at current prices (“replacement cost new”) less depreciation, or the cost the contractor incurred when creating the technical data or computer software (“actual costs”) less depreciation. This approach is particularly applicable for a highly specialized intangible asset that does not normally exchange in a secondary market—and is the approach discussed in the ASPM.

Irrespective of what type of cost method is used, the calculation should account for the following cost elements: direct costs (material, labor, overhead), indirect costs (material, labor, overhead), developer’s profit, and entrepreneurial incentive (opportunity cost). The cost approach provides a reasonable value indication for a tangible asset when it includes all of these cost elements and when the analysis has been adjusted for all applicable forms of obsolescence (physical deterioration, functional obsolescence, and economic obsolescence). In the case of computer software, when using the “reproduction cost new” or “replacement cost new” method the program office may choose to use various software development effort estimating models (e.g., COCOMO® II, KPLAN, SEER-SEM).

Even when a cost analysis is not required due to the contracting officer’s inability to obtain sufficient data to perform such an analysis, in the context of defense contracting, the “actual cost” approach would still be particularly useful for two reasons. First, DFARS 252.227-7019(b) and 252.227-7037(c) require that contractors and subcontractors at all tiers maintain records sufficient to justify the validity of markings that impose restrictions on the Government’s ability to use, release or disclose technical data or computer software delivered or required to be delivered under the contract or subcontract. Those records would include:

  • Written corporate policies that authorize the establishment of an IR&D project (e.g., its purpose, its budget, the specific internal project charge code to which employees’ time should be charged when developing that particular item of technical data or computer software). As stated above, to be properly classified as IR&D, both the cost principles (FAR 31.205-18(a)) and the Cost Accounting Standards (CAS 9904.420-30(a)(6)) state that purpose cannot relate to performing any express requirement of a government contract.
  • Contemporaneous documentation that demonstrates that senior company officials followed those written corporate policies when initiating that project (e.g., the signed and dated memorandum from a senior company official).
  • Accounting records contained in the contractor’s timekeeping systems demonstrating employees actually charging their time to that IR&D project along with those employees’ labor rates.
  • An identification of where the item or component described by that technical data (or, for software-intensive systems, the software item/software subroutine) is identified in the offeror’s proposed WBS and (for software-intensive systems) in its proposed SAD.
  • Engineering notebooks.
  • Drawing archives.
  • IR&D reports.
  • Technical papers and reports.

Put another way, such records—which are the quintessential type of “historical accounting data” referred to in the definition of “cost or pricing data” mentioned above—constitute contemporaneous documentation that the offeror or its subcontractor created years if not decades prior to the Government and the offeror commencing negotiations to arrive at a fair and reasonable price. Courts invariably give greater weight to contemporaneous documentation than documents created during litigation. In a similar manner, a program office should give such records greater weight than documents the offeror or its subcontractor created for the first time ever in response to the RFP. Conversely, if an offeror would refuse to submit such contemporaneous documentation, the Government could draw adverse inferences from the contractor’s refusal to produce such records; i.e., if the contractor would have submitted such cost or pricing data to the Government, that data would have proved the contractor did not develop the technical data or computer software at issue at private expense.

Second, the offeror has the burden of proving that a particular item of technical data associated with a major weapon system (i.e., ACAT I), subsystem, or component was developed exclusively at private expense unless the major weapon system or a component of a subsystem was acquired as a commercial item. As described in Section V.B.2.b.(1).(g).(iii). of this Handbook, this burden means the program office should require that the offeror demonstrate that it tracked the allocation of private and government funds to the development of the noncommercial item, component or process it accomplished with those funds and broke or separated the accounting trail for development of those technologies to indirect cost pools (e.g., IR&D), costs not allocated to a government contract, or any combination thereof. If it can do so, the offeror will have proved that it developed a particular noncommercial item, component or process (or all items, components or processes) described in a particular CDRL exclusively at private expense. The offeror must also demonstrate that its assertion that it developed the data exclusively at private expense is consistent with any EVM data submitted to the Government under any Government contract.

If the contractor cannot sustain its burden of proof in this regard by means of the types of records described above, the Government may presume that the Government has already paid those costs. Under those circumstances, the offeror should be willing to sell Unlimited Rights associated with that technical data to the Government at zero cost. In contrast, if the item, component, or process to which that technical data pertains is a commercial item or COTS, the Government must presume that the offeror developed that item of technical data or computer software exclusively at private expense unless the Government can demonstrate that it contributed to the development of the item, component or process in question.

(3). The income approach. Given the preference in the DFARS for first using the market approach and then the cost approach, it would seem reasonable to conclude the opposite is the case: In DoD, the income approach is the least-favored approach. That said, when neither the market nor the cost approaches are viable, the income approach is the only one that remains.

The income approach analyzes the present value of future estimated net income the technical data or computer software may generate for whatever remaining expected useful life that technical data or computer software may have. When using this approach, the contracting officer should (a) determine from whose perspective should it value the projected future net income to be generated by the technical data or computer software, (b) identify the length of time during which the net income is measured and the frequency of the income measurement, and finally (c) select the appropriate yield capitalization rate (present value discount rate) or direct capitalization rate (conversion of a perpetual income flow to present value). In doing so, the contracting officer should use the following factors: market evidence, the risk associated with the offeror achieving the income projection, consistency with the income measured projected in the analysis, forward-looking, and consistency with the expected term of the income projection.

In addition, the contracting officer should also obtain any business plans (e.g., discounted cash flow analyses, ROI analyses) the offeror ever created documenting that offeror’s profit expectations regarding the future revenue stream it expected to receive from the development of that specific item of IP. Although the offeror remains free to explain to the Government the weight (if any) the Government should give to that “historical accounting data” when determining the current value of that IP for purposes of the Government acquiring whatever type of IP rights it now seeks to acquire from the offeror for that specific item of IP, the offeror cannot reasonably claim that such data is not encompassed by the definition of cost or pricing data in FAR 2.101 provided above. Therefore, if the offeror admits it performed such analyses but refuses to submit such contemporaneous documentation to the Government, the Government may draw adverse inferences from the offeror’s refusal to produce such records.

It may be difficult for a program office to conceive how it could use any of the three methods described above to estimate the value of IP rights to a specific item of technical data acquired under a DoD contract. Accordingly, we provide the following not-too-hypothetical scenario for the reader’s consideration: A program office wants to award a sole-source follow-on contract to the incumbent to acquire additional receivers, some of which will be of the identical configuration as the program office procured under the existing contract and some of which will be of a configuration that features improved capabilities. Although receivers procured under the existing contract came with a warranty, the contract also contained provisions permitting the program office to direct the contractor to perform out-of-warranty repairs based upon a price-per-repair rate included in the contract. The incumbent performed out-of-warranty repairs during the performance of the contract. As a result, both parties know precisely how many repairs occurred each year of contract performance and precisely how much each repair cost the program office.

Under the follow-on contract, the program office wants to acquire Government Purpose Rights to a TDP that would constitute a full design disclosure. As a result, the program office will be able to provide that TDP to offerors as government-furnished-information in order to compete depot-level maintenance of those receivers. If the program office acquires that level of IP rights to that technical data, however, the remaining value to the owner of that IP may be negligible. The reason why that is the case is because the contractor will no longer be in a sole-source position to gain the profit it would have otherwise received had the program office continued to have it perform those out-of-warranty repairs under the follow-on contract.

As a starting point, therefore, the parties could use the income approach to calculate the remaining expected useful life of that technical data. First, the parties would extrapolate data supporting projections of business prospects cost or pricing data (i.e., the historical repair incidence rate) to calculate the total quantity of future out-of-warranty repairs the incumbent would have otherwise performed under the follow-on contract on identical-configuration receivers each year after the warranty for those receivers had expired. Second, since no historical data exists for the repair-incidence-rate for improved-capability receivers, the parties would perform a regression analysis to determine the probable repair-incidence-rate for out-of-warranty repairs the incumbent would have otherwise performed under the follow-on contract for those receivers each year after the warranty for those receivers had expired. Third, the parties would agree as to the profit percentage applicable to those out-of-warranty repairs the contractor would have otherwise performed each year. Fourth, the parties would multiply that percentage by the total number of out-of-warranty repairs the incumbent would have otherwise performed under the contract each year for both types of receivers. Fifth, the parties would discount that sum to present value for each year. The result will be a quantification of the profit (net income) it is likely the incumbent would have otherwise received were it to have performed all out-of-warranty repairs under the follow-on contract as it did under the existing contract.

The accounting profession recommends use of the following factors when selecting which of the three approaches discussed above would be the most appropriate to use when calculating the value of a specific item of IP:

  • Quantity/quality of available data.
  • Access to available data.
  • Supply of relevant transactional data.
  • Type/nature of the intangible asset.
  • Industry conditions in which the intangible asset operates.
  • The bundle of IP rights included in the analysis.
  • Statutory/judicial/contractual/administrative requirements and considerations.
  • Informational needs of the customer.
  • Purpose/objective of the analysis.
  • Compliance with any relevant professional standards.
  • Professional judgment and experience of the analyst.
  • Instructions from legal counsel.

In short, when it comes to negotiating a fair and reasonable price for the value of IP rights under DoD contracts, the market method is preferred over the cost method which in turn is preferred over the income method. The market method looks to the present. In some cases, the cost method looks to the past. And the income method requires that the parties foretell the future.

I. Milestone B Certification

10 U.S.C. § 2366b states that that an ACAT I program may not receive Milestone B approval until the Milestone Decision Authority (MDA) makes various certifications and determinations. The importance of that milestone to acquisition programs is described in DoDI 5000.02 Change 3: Once the MDA makes those certifications and determinations, the cognizant DoD Component may enter into the EMD phase for that program, award contracts for EMD, and commit the required investment resources to that program. The purpose of those certifications and determinations is to ensure that:

  • all sources of risk (e.g., technology, engineering, integration, manufacturing, sustainment, cost) have been adequately mitigated to support a commitment to design for production,
  • validated capability requirements exist,
  • full funding in the FYDP exists,
  • compliance with affordability goals as demonstrated through an independent cost estimate for production/sustainment exists, and
  • framing assumptions central to shaping the program’s cost, schedule, and performance expectations have been identified.

10 U.S.C. §§ 2446a and 2446b state that before the MDA may approve the program entering Milestone B, they must determine that

  • In the case of a program that uses a MOSA,
    • The program incorporates clearly defined major system interfaces between the major system platform and major system components, between major system components, and between major system platforms,
    • Such major system interfaces are consistent with the widely supported and consensus-based standards that exist at the time of the milestone decision, unless such standards are unavailable or unsuitable for particular major system interfaces, and
    • The Government has arranged to obtain appropriate and necessary IP rights with respect to such major system interfaces upon completion of the major system platform, or
  • In the case of a program that does not use a MOSA, that the use of a MOSA is not practicable.

Similarly, 10 U.S.C. § 2366b states that one of the determinations that the MDA must make before they may authorize an ACAT I program to enter into Milestone B after December 12, 2018 is that the program has taken appropriate actions to negotiate and enter into a contract or contract options for the technical data required to support the program.

If a program implements the disciplined approach to acquiring IP and associated license rights described in the preceding sections of this Handbook, the MDA should have little difficulty making such determinations. The reason why is because the program office will be able to furnish the MDA all supporting documentation needed—e.g., the program’s CDD, the program’s SEP, the program’s acquisition strategy, the proposed contract to be awarded—to demonstrate that the program has satisfied the preconditions to obtaining Milestone B approval described above. Of course, if a program office fails to implement that disciplined approach, it puts their MDA between the proverbial rock and a hard space. Specifically, the MDA must either

  • Waive the applicability of these requirements if they determine that but for such a waiver the DoD would be unable to meet critical national security objectives and notifies the Congressional defense committees in writing within 30 days after the waiver is authorized, and review the program not less often then annually to determine the extent to which the program currently satisfies the certification and determination requirements in 10 U.S.C. § 2366b until such time as the MDA determines the program satisfies all such certification and determination requirements, or
  • Disapprove the program office’s request—in which case the program cannot enter Milestone B.

J. Post-Award.

1. CDRL Review Upon Delivery

“Examples like the Challenger explosion . . . demonstrate the states of complacency and familiarity we can fall into when it comes to dealing with large technological decisions. This is not to say that we should become paranoid about technology, but there is much to be said for a healthy skepticism among engineers and nonengineers alike. The most dramatic failures have occurred in a climate of overconfidence and carelessness, and the least we can learn from those incidents is to be more vigilant. Accidents and near accidents remain our surest reminders that engineering is a human endeavor that takes place in the context of other human endeavors, including calculated risk and celebration. None of the sane among us willfully wishes to place fellow human beings in imminent danger, but we sometimes minimize or forget what dangers lurk among our technological creations. The surest way for us to be vigilant is to be aware of past mistakes and thereby to be armed with the evidence of case studies to bolster, when need be, our arguments against the launching of a space shuttle on a cold winter morning. . . .”[31]

What is true in war and in systems engineering is true after award in the context of IP rights to technical data and computer software: Complacency kills. Moreover, like in war and in systems engineering, the root cause of such complacency in this context after award is usually attributable to a breakdown in discipline. Specifically, all of the program office’s hard work in negotiating IP rights in technical data and computer software prior to award will be for naught if it fails to ensure after award that the contractor is complying with the requirements of its contract relative to the IP rights in technical data and computer software the contractor ultimately delivers to the program office. By that time, the contractor may be experiencing “seller’s remorse” with respect to the IP rights in technical data and computer software it agreed prior to award to deliver to the program office after award.

The results of that breakdown in discipline in the program office usually manifest themselves in three ways. The first way is that program office negotiates away for a pittance after award via bilateral contract modifications to the IP rights it negotiated prior to award. Years later, the program office may regret acceding to the contractor’s demands. By that time, however, the program office will just have to live with those constraints on its ability to execute successfully the program. Of course, if the program office can no longer successfully execute the program due to that breakdown in discipline, the program manager and the Program Executive Officer may have to explain to their MDA why they ever permitted that situation to occur.

The second way for discipline to break down is for program office personnel to begin empathizing with the contractor’s complaints about the “proprietary” IP rights it freely agreed to relinquish prior to award associated with a specific item of technical data or computer software. Those personnel may then decide that this problem is so inconsequential that it must not get in the way of the parties achieving some allegedly critical milestone. In the alternative, those personnel conclude that the parties can sweep that problem under the proverbial rug or conclude that the parties can defer resolution of that problem to a more convenient time—which, of course, never occurs because those personnel then focus on meeting the next schedule-driven milestone.

Next, program office personnel enter into a verbal side agreement with the contractor relative to the level of IP rights associated with that item of technical data or computer software that is inconsistent with the express terms and conditions of the contract. Inevitably, those side agreements possess one or more of the following distinguishing features. First, those agreements may violate the U.S. Constitution because the program office never received consideration for relinquishing its IP rights without obtaining authority from Congress to do so. Second, those agreements may violate the CICA because the agreement may have surrendered Unlimited Rights in the types of technical data described in Section V.D.1.b of this Handbook to which the Government was otherwise entitled to receive pursuant to 10 U.S.C. § 2320 that are not in dispute. Third, the competition under which the program office ran the source selection may have been compromised because, had the contractor proposed the level of IP rights prior to award that it will now proposes to deliver after award, as discussed above, that fact “would have materially affected the source selection decision.” By this time, the contractor, having exploited the program office’s lack of discipline once, will seek to exploit it ad nauseam—so that reality will soon bear no relationship to the express terms and conditions of the contract.

This undisciplined approach to program management and proper contract administration is unwise at best, as it increases the probability that months or years hence, the program office will have to untie the Gordian Knot caused by mismarked CDRL deliverables or missing content in the CDRLs that it now desperately needs in order to successfully execute the program. (Of course, by that time the program office personnel who created this situation will have received more prestigious assignments, promotions, cash awards, and military decorations based in part upon false pretenses, i.e., the “success” they achieved in meeting that allegedly critical milestone.) Only those who have spent years of their professional career handling such issues can truly understand the time and effort the program office will need to expend to successfully bring reality back into alignment with the terms and conditions of the contract.

The third way for discipline to break down is for the program office to be so mesmerized by the content of a contractor’s CDRL deliverable that it forgets to check whether the contractor has properly marked its deliverable with the proper restrictive markings (assuming the contractor should have affixed any markings to that deliverable). There is only one way to solve this problem: The program manager, the product support manager, and the Contracting Officer must implement procedures that ensure that the first thing the program office’s initial recipient of a CDRL delivered by the contractor will not do is start reviewing the content of the CDRL for accuracy and completeness or (worse yet) immediately distribute those trade secrets to any non-Government employee in a manner that may not be authorized by the contract.

Instead, with respect to technical data the recipient should verify that the cover page of the CDRL contains IP rights restrictive legends identical to the restrictive markings required by the IP Rights Attachment described above for that CDRL. The recipient should then verify that no restrictive markings are included on any page of that CDRL that are inconsistent with the restrictive legends on that cover page. In a similar fashion, the recipient should ensure that, if the CDRL requires the delivery of computer software, all restrictive markings contained within that deliverable are identical to the restrictive legends required by the IP Rights Attachment described above for that CDRL. In this regard, we recommend the program office consult with the DoD’s Joint Tactical Networking Center (JTNC) regarding the use of its DoD Waveform Information Repository (IR) Data-Rights Analysis Objectives and Standard Operating Procedures (SOP) (Version 1.0 October 4, 2018) to scan the CDRL for any “nonconforming” or “unjustified” markings. For details regarding what are “nonconforming” and “unjustified” markings and how to handle those markings, see Section V.J.3 below.

Next, the recipient should read the licenses to understand precisely to whom they may furnish copies of that technical data and computer software for what purposes for what specified period. Then—and only then—should the recipient review the content of the CDRL for accuracy and completeness. Assuming the program office structured its IP Rights Attachment in a manner similar to that described above and trained its personnel to use the following decision tree, it should take the recipient of a CDRL less than 10 seconds to determine to whom that recipient can disclose that CDRL for what purpose(s) and for what period:

a. In what CDRL will the data in question be delivered?

b. Is that CDRL listed in Table 3 of the IP Rights Attachment? If the answer is yes, the recipient should carefully read the IP license contained in subsection c.(3) to learn the conditions under which they may use, release, or disclose that technical data or computer software outside the Government. If the answer is no, go to the next question.

c. Is that CDRL listed in Table 2 of the IP Rights Attachment? If the answer is no, then that CDRL contains no commercial item technical data or computer software in which case the recipient should skip to question d. If the answer is yes, does the IP license contained in Appendix A listed in Column 3 of that table associated with that CDRL encompass the technical data or computer software contained in that CDRL? If the answer is no, the CDRL must contain only noncommercial technical data or computer software, and the recipient should skip to the next question. If the answer is yes, the recipient should carefully read that license (or those licenses) and subsection c.(2) to determine to whom, for what purposes, for what duration of time, that commercial item technical data or software may be used, disclosed or released outside the Government. If (i) any technical data contained in that CDRL is marked in red ink as required by the IP Rights Attachment, but Table 2 did not list that CDRL, or (ii) the IP license listed in Column 3 of that Table for that CDRL does not encompass the technical data contained in that CDRL, the recipient should notify the PCO immediately.

d. Since the CDRL contains only noncommercial technical data or computer software, the recipient should skim down Column 1 of Table 1 of the IP Rights Attachment until they locates the CDRL number. Go across that corresponding row and read the cell in Column 4 associated with that CDRL. If that cell contains the word “Unlimited”, there should be no restrictive marking on the CDRL and the recipient may use, release or disclose that technical data or computer software to anyone for any purpose at any time. If, however, any IP restrictive markings are affixed to that CDRL, the recipient should notify the PCO immediately. If that cell contains the word “Government Purpose”, that term should be in the restrictive marking on the CDRL and the recipient may use, release or disclose that technical data or computer software to authorized persons for government purposes. If, however, those words are not in the restrictive marking on the CDRL, the recipient should notify the PCO immediately. If that cell contains the word “Limited” or “Restricted”, that term should be in the restrictive marking on the CDRL and the recipient may use, release or disclose that technical data or computer software, respectively, only to those persons outside the Government and for only those purposes described in the definition of those terms in DFARS 252.227-7013 and DFARS 252.227-7014, respectively. If, however, those words are not in the restrictive marking on the CDRL, the recipient should notify the PCO immediately.

2. Use, Release, And Disclosure Of Technical Data And Computer Software

The program office should use the following guidelines to determine whether it may release the technical data and computer software delivered under the awarded contract outside the Government.

Assuming that the technical data or computer software delivered to the program office is not subject to the Arms Export Control Act (e.g., a Distribution Statement “D” is not affixed to the cover page), and if that noncommercial technical data or software contains no restrictive markings, it is presumed to have been delivered with Unlimited Rights. The program office may therefore release that item outside the Government without restrictions.

Section II.C of this Handbook describes to whom, for what purposes, and for what period of time noncommercial technical data or computer software the Government may use, release, or disclose that item marked with Government Purpose Rights, Limited Rights, Restricted Rights, Specifically Negotiated Rights, or SBIR Rights restrictive markings outside the Government. The program office may only use, release and disclose commercial technical data and computer software in accordance with the terms and conditions of the license associated with those items. That is why the recipient of any CDRL should read the commercial licenses before reviewing the content of that CDRL for accuracy and completeness.

Finally, the program office should ensure that all conditions described in the NDA between its “covered Government support contractor” and the contractor who created that CDRL are satisfied prior to releasing or disclosing any CDRL to that “covered Government support contractor” to which is affixed “Limited Rights” or “Restricted Rights” restrictive markings or commercial technical data the content of which the Government did not acquire “Unrestricted Rights”. Of course, this condition only applies if the Government did not obtain a waiver of that requirement prior to award from the contractor who created that CDRL.

3. Identifying And Correcting Improperly Marked CDRLs

For the reasons described above, it is imperative that the program office ensure that proper markings are affixed to CDRLs delivered to it by the contractor. In this regard, a “nonconforming” marking is one that does not contain the following terms: “Unlimited Rights”, “Government Purpose Rights”, “Limited Rights”, “Restricted Rights”, or “Special License Rights”. (Examples of nonconforming markings include the terms “proprietary” and “competition sensitive.”) In contrast, an “unjustified” marking is one that is one that is described above (e.g., “Restricted”) but is not the level of IP rights to that CDRL the IP Rights Attachment described above required the contractor to deliver to the program office (e.g., “Unlimited”). If the program office discovers the existence of either situation, it should immediately notify the Contracting Officer so the Contracting Officer may take appropriate action.

Specifically, the Contracting Officer should notify the contractor and request it remove that nonconforming marking and redeliver that deliverable with conforming markings at its own expense. If the contractor fails to do so, within 60 days, the Government may ignore or, at the contractor’s expense, remove or correct that nonconforming marking. If the contract includes DFARS 252.227-7030 (Technical Data—Withholding of Payment), the Contracting Officer should also consider withholding payment of ten percent of the total contract price until such time as the contractor removes that nonconforming marking.

In contrast, if the contractor affixed an unjustified marking to the CDRL, the Contracting Officer must invoke the validation procedures described in DFARS 252.227-7019 and 252.227-7037. The reason why is—as recently stated by the ASBCA—because that assertion is simply the unilateral claim of a contractor regarding allocation of IP rights for noncommercial technical data or computer software. Specifically, the Contracting Officer may first submit a prechallenge request for information to the contractor or subcontractor requesting that it provide a written explanation for any restrictions on the Government’s ability to use technical data or computer software. The request may include a statement of facts accompanied by supporting documentation. The contractor and subcontractor are required to have, maintain, and follow written procedures sufficient to assure that restrictive markings are used only when authorized by the terms of the contract, and maintain records sufficient to justify the validity of any restrictive markings on technical data or computer software. Accordingly, the type of records the Contracting Officer should request the contractor provide would include, but not necessarily be limited to, those records described in Section V.H.4 above.

Consistent with the funding rules described in Section V.B.2.b.(1).(g).(iii). above, the Contracting Officer should request that the contractor or subcontractor submit those records in a manner that facilitates analysis. For example, if computer software residing within a subsystem consists of 115 different software units, the Contracting Officer should request the contractor or subcontractor provide the supporting documentation described above in a 3-ring binder as follows: Tab 1 should identify the first software unit residing within that subsystem and provide a detailed written explanation of the facts upon which the asserted restriction is based. Immediately following that explanation should be the supporting documentation. The contractor or subcontractor would then use that format to populate Tabs 2 through 115 in that 3-ring binder. The written explanation should cross-reference specific pages in the memorandum and accounting records so that anyone reviewing the contents of any Tab could read the written explanation and quickly validate the basis of the contractor’s or subcontractor’s assertion that every single software unit currently residing within that subsystem was developed exclusively at private expense. If the name of a project changed over time, the written explanation should so state. If any of those 115 different software units were not developed exclusively at private expense, the contractor or subcontractor would identify those software units and then identify which of those items were developed with mixed funding or exclusively with government funds.

If the prechallenge request is associated with asserted restrictions affixed to technical data associated with a major weapon system (i.e., ACAT I), subsystem, or component, the request should also note that the contractor or subcontractor has the burden of proving the validity of its assertion that any item of technical data or computer software to which the asserted restriction applies were developed exclusively at private expense unless the major weapon system or a component of a subsystem was acquired as a commercial item. In contrast, if the technical data pertains to a commercial item or the computer software is a commercial item, then the Contracting Officer must presume that the contractor’s or subcontractor’s asserted restrictions are justified on the basis that the item, component, or process was developed exclusively at private expense unless the Contracting Officer has information to the contrary.

In any case, if the Contracting Officer has reasonable grounds to question the validity of an assertion, the Contracting Officer may make a formal challenge to the “unjustified” restrictive marking. The program office has three years from the date the contractor delivers the technical data or computer software to the program office, or three years following final payment under the contract, whichever is later, to challenge the validity of a restrictive marking affixed to that data or software. The written challenge must state the basis for the challenge, require the contractor to respond with 60 days and provide justification for the assertion based upon records kept that are reasonably available to the contractor in sufficient detail to enable the Contracting Officer to determine the validity of the asserted restrictions, and state that a Contracting Officer’s final decision or decision by a court or the ASBCA shall serve as justification for the asserted restriction. The contractor’s response to the Contracting Officer’s challenge is considered a claim under the Contract Disputes Act, which must be certified by the contractor.

If the contractor fails to respond to the challenge, or the Contracting Officer determines that the contractor’s written explanation for the asserted restriction is unjustified, the Contracting Officer shall issue a final decision pertaining to the validity of the asserted restriction. If, however, the Contracting Officer determines the contractor’s written explanation validates the claimed asserted restriction, the Contracting Officer shall issue a final decision validating the asserted restriction. If the Contracting Officer’s final decision denies the validity of the asserted restriction, the Government must still honor that restriction for 90 days or one year from the date of that decision to allow the contractor to appeal to the ASBCA or the COFC, respectively. Between the date that final decision is issued, and the periods specified above, only the Secretary of the Air Force is authorized to determine that urgent or compelling circumstances do not permit awaiting the filing of suit—and if the Secretary determines those circumstances exist, they must notify the contractor accordingly. If the contractor appeals that final decision to the ASBCA or the COFC, the contractor has the burden on appeal of establishing the validity of its asserted restrictions.

After that period, the Government may strike, correct, or ignore the restrictive marking. If upon final disposition of that litigation the Contracting Officer’s decision is sustained, the restrictive marking shall be cancelled, corrected, or ignored, and if that restriction was not substantially justified, the contractor shall be liable to pay the Government its costs of reviewing the asserted restriction and the fees and other expenses incurred by the Government in challenging the restriction unless special circumstances would make such a payment unjust. Conversely, if the Contracting Officer’s decision is not sustained, the Government shall be bound by the asserted restriction and if the Government’s challenge was not made in good faith, the Government shall be liable to pay the contractor fees and other expenses incurred by the contractor in defending the restriction.

When reviewing the contractor’s response to either the Contracting Officer’s prechallenge request for information or to a formal challenge that provided the information described in Section V.H.4 above, the Contracting Officer should compare that information with information in the program office’s possession listed in Section V.B.2.e. above. The following hypothetical examples are provided for the reader’s consideration:

  • The noncommercial technical data in question—a full design disclosure TDP containing detailed manufacturing process data for a component—is affixed with a Limited Rights restrictive marking. The SOW and a CDRL in the contract required the contractor to develop and deliver that TDP to the Government. The contract incorporated by reference DFARS 252.227-7013, and included a WBS written to the level of that component consistent with Section 2.1 of the program’s SEP. The contractor’s substantiating records indicate that it allocated all costs of the development of the component’s TDP to an IR&D project, contrary to FAR 31.205-18. However, the contractor’s EVM data indicate that the contractor incurred costs to develop that component during contract performance—which means that at least part (if not all) of the costs the contractor incurred to develop the TDP for that component were funded by the Government. Unless the parties otherwise agreed in the contract prior to award, the Government acquired at minimum Government Purpose Rights to that TDP.
  • The commercial technical data in question—an ICD—is affixed with a restrictive marking. As an ICD, that commercial technical data contains form, fit, and function data (e.g., data that describes the physical characteristics of a 120V AC electrical plug including the dimensions of each prong and their spatial relationship to each other). The contract under which the contractor delivered that technical data incorporated by reference DFARS 252.227-7015. Unless the parties otherwise agreed in the contract prior to award, the Government is entitled to Unrestricted Rights in that technical data.
  • A contract required the contractor to develop a noncommercial software-intensive system in accordance with MOSA principles. That major system platform is comprised of 328 noncommercial major system components (in this case, software units), 200 COTS major system components, and 75 OSS major system components. The SOW and CDRL in the contract required the contractor to develop and deliver this software-intensive system, including major system ICDs, a SSDD that contains a full identification of the system and the software residing therein, a SAD that described the relationship between all noncommercial, COTS, and OSS major system components residing within the system, and an SDD that identified all software units residing within all software items residing within all CSCIs. The WBS appended to the contract identified all such components at the appropriate level of indenture. The contractor’s substantiating records demonstrate it created 28 of those noncommercial major system components prior to award, the development of those components was not specifically required in the performance of any government contract ever awarded to it by any Federal agency since the contractor or any of its predecessors in interest came into existence. Those records prove the contractor properly allocated the costs to develop those components to an IR&D project—including the costs to develop the major system ICDs between some of those 28 noncommercial components. The contractor’s EVM data submitted during contract performance indicate the costs to develop the remaining 300 noncommercial major system components were developed exclusively with Government funds. Unless the parties otherwise agreed in the contract prior to award, the Government acquired Government Purpose Rights to all major system ICDs between all noncommercial, COTS, and OSS major system components in the systems’ software architecture, Unlimited Rights to 300 noncommercial major system components, Restricted Rights to the remaining 28 noncommercial major system components, and commercial IP licenses to the remaining 200 COTS and 75 OSS major system components residing within the system.

4. Delivery Of Technical Data/Software Created During Contract Performance That Was Not Expressly Identified In The Contract

If the Deferred Ordering clause (DFARS 252.227-7027) is contained in the contract, the program office may require the contractor to deliver any data or software to the program office, not expressly identified in the contract but generated in the performance of the contract or any subcontract, anytime during performance of the contract or within three years after acceptance of all items (other than technical data or computer software). If that clause is not included in the contract and the data or software is not the subject of a CDRL, the program office will not be able to require the delivery of that data or software under the Changes Clause.

5. Correction Of Defective Technical Data Or Computer Software

With respect to technical data, if the program office discovers that the technical data delivered by the contractor is defective, the program office has three years to obtain the remedies described in DFARS 252.246-7001 (Warranty of Data) from the date of delivery if that clause was included in the contract. Those remedies include requiring the contractor to correct or replace at the contractor's expense the nonconforming technical data, a downward adjustment of the price of that technical data, or correcting or replacing the nonconforming technical data and charging the cost to the contractor. With respect to computer software delivered under a fixed-price contract, the program office receives only that warranty for which it bargained under the contract; if it did not purchase an express warranty, its remedies are limited to those described in FAR 52.246-2 (Inspection of Supplies – Fixed Price): Latent defects, gross mistakes amounting to fraud, or fraud. With respect to computer software delivered under a cost-reimbursable or time-and-materials/labor-hour contract, FAR 52.246-3 (Inspection of Supplies—Cost-Reimbursement), FAR 52.246-6 (Inspection—Time-and-Material and Labor-Hour), and FAR 52.246-8 (Inspection of Research and Development—Cost-Reimbursement), state that if the program office discovers within six months of delivery (or other period specified by the contract) that the computer software delivered is defective, it may require the contractor to replace or correct nonconforming computer software at no increase in fee (although in most cases it will have to pay the contractor the costs it incurred to correct those defects).

6. Changes In Requirements

If requirements change after award so that the program office must modify the contract to require the contractor to deliver additional CDRL items (i.e., additional items of technical data or computer software) or additional CDRL content in pre-existing CDRLs, the program office should revise Exhibit A and the IP Rights Attachment to add those items into the contract. The program office should then obtain cost and pricing data for the IP rights in technical data and computer software for those items, require the contractor to revise their DFARS 252.227-7017 certification/representation and provide copies of any applicable commercial licenses, review those licenses for consistency with the Government’s minimum needs, and bilaterally modify the contract accordingly. For details, see Section V.J. of this Handbook.

7. Post-Award Analysis Of IP Rights In Technical Data And Computer Software

Occasionally, the program office may need to analyze the IP rights in technical data and computer software it purchased under one or a myriad of contracts over the past decade (or more) because it failed to use an approach similar to that recommended above to expressly identify its technical data and computer software IP rights requirements under those contracts prior to award. Instead, the program office merely incorporated by reference standard FAR or DFARS clauses—or even worse, failed to include the DFARS 252.227-7017 certification/representation into Section K of the RFP.

The circumstances under which the program office may need to perform that analysis include: (1) determining whether the program office acquired sufficient IP rights in technical data or computer software to compete follow-on acquisitions or, conversely, (2) whether the program office may be forced to acquire supplies/services sole-source because it did not acquire sufficient IP rights in technical data or computer software to compete that acquisition. Those circumstances may also include determining whether the program office may release technical data or computer software to covered government support contractors so those contractors can advise the Government regarding the accuracy and completeness of that technical data or computer software. The types of documents the program office will need to perform that analysis include, but are not limited to, the sources of information listed in Sections V.B.2.e. and V.H.4.c.(2) of this Handbook.

If the Government did not use the disciplined approach described in Section V above to acquire various IP rights under multiple contracts over the past decade (or more), the analysis described above can literally take months to complete. Similarly, if the program office must use litigation to get the contractor to remove an “unjustified” marking after implementing the formal challenge procedures, that litigation could take as long as 9.5 years to resolve. (Of course, after the litigation has run its course, the value of that technical data or computer software to all parties may be negligible.) Thus, the benefits of structuring the RFP using the approach recommended above are three-fold. First, that approach will facilitate proper acquisition planning. Second, it will reduce the probability that the program office must perform a complicated technical data/computer software IP rights analysis years after contract award. Third, it will reduce the probability that litigation may be necessary to resolve a dispute between the contractor and the Government regarding what IP rights the Government actually purchased under those multiple contracts.

VI. Epilogue

Recently, an advisory panel responsible for making recommendations to Congress regarding the streamlining and codifying of acquisition regulations summarized the problem and the solution described in greater detail above:

“[a]cquisition of [IP] rights as part of weapon systems development has changed in recent years. If a weapon system is to be sustained through a combination of commercial and organic support, access to intellectual property (IP) rights that allow component repair—and in some cases, competition to provide those capabilities—is crucial. [footnote omitted] Appropriate planning, funding, and contracting for government acquisition of necessary IP is best accomplished up front, not as an afterthought. Requesting a complete data package might not be cost effective either. Instead, the government should consider obtaining [IP] rights to those specific portions and for the specific purposes (e.g., organic depot maintenance/acceptance testing versus detailed design/material data required to enable a future reprocurement of the component) of the system it foresees acquiring in the future.”[32]

Although complicated statutes and regulations govern the proper acquisition and enforcement of IP rights in technical data and computer software, anyone can master those resources by taking the time to understand “why” IP and IP rights must be acquired, “what” IP and IP rights must be acquired, when” IP and IP rights may be acquired, and “how” IP and IP rights may be acquired. Moreover, this topic becomes relatively easy to understand when one keeps in mind the following principles discussed above. First, a program office acquires only a license—not ownership—to use, release and disclose technical data or computer software outside the Government. Second, a program office needs to carefully determine during formulation of an acquisition strategy who will need to use technical data and computer software delivered after award for what specific purpose it intends to use, release or disclose that technical data or computer software for what specified period. Third, if a program office carefully structures licensing provisions in its RFP it can more effectively evaluate offerors’ proposals prior to award and ensure delivery of the appropriate licenses after award. If you keep these principles in mind, you will enhance competition and increase SMC’s ability to develop, produce and sustain the space system and its subsystems over their life-cycle thereby helping to achieve SMC’s mission as described in SMC’s Strategic Plan (2018): To deliver resilient, affordable and sustainable space capabilities for the nation.

Appendix A

Relevant Excerpts from GPS IIIF RFP

Appendix B

Relevant Excerpts from GPS OCX Phase B RFP

Appendix C

Relevant Excerpts from GPS SE&I Follow-On RFP

  1. Ralph C. Nash, Intellectual Property: Obtaining More Rights in Technical Data and Computer Software: A Steady Erosion of Contractor Rights, 26 Nash & Cibinic Rep. ¶ 5 (Jan. 2012).

  2. Elisabeth Bumiller, We Have Met the Enemy and He Is PowerPoint, N.Y. Times, Apr. 27, 2010, at A1, http://www.nytimes.com/2010/04/27/world/27powerpoint.html.

  3. Sandra I. Erwin, Intellectual Property Fights Par for the Course in F-35 Program, National Defense (Sept. 8, 2016), http://www.nationaldefensemagazine.org/articles/2016/9/8/intellectual-property-fights-par-for-the-course-in-f-35-program.

  4. Tim Reyes, Retrospective: A Speech by Wernher von Braun on Management, Medium, Sept. 18, 1962)(Address by Dr. Wernher von Braun, Director, George C. Marshall Space Flight Center, U.S. National Aeronautics and Space Administration (NASA), Huntsville, Alabama, at the Sixteenth National Conference on the Management of Research, French Lick, Indiana), https://medium.com/@telluric/dr-wernher-von-braun-director-96eeae675528 (emphasis added).

  5. The definition of the term “trade secret” varies depending upon whether one is discussing, e.g., the Trade Secrets Act (18 U.S.C. § 1905), the Freedom of Information Act (5 U.S.C. § 552(b)(4)), or the Uniform Trade Secrets Act codified by most states (e.g., Cal. Civ. Code Ann. § 3426.1(d) (Deering’s 2018)). When using that term in this Handbook, the authors are using the definition of “trade secret” in the Economic Espionage Act of 1996, as amended by the Defend Trade Secrets Act of 2016, because that definition is the only one codified in Federal law, i.e., “all forms and types of financial, business, scientific, technical, economic, or engineering information, including patterns, plans, compilations, program devices, formulas, designs, prototypes, methods, techniques, processes, procedures, programs, or codes, whether tangible or intangible, and whether or how stored, compiled, or memorialized physically, electronically, graphically, photographically, or in writing if [ ] the owner thereof has taken reasonable measures to keep such information secret[ ] and the information derives independent economic value, actual or potential, from not being generally known to, and not being readily ascertainable through proper means by, another person who can obtain economic value from the disclosure or use of the information”. 18 U.S.C. § 1839(3).

  6. In brief, copyright protection provides authors exclusive rights to their original works of authorshipe.g., literary works, musical works (including any accompanying words), dramatic works (including any accompanying music), pantomimes and choreographic works, pictorial, graphic, and sculptural works, motion pictures and other audiovisual works, sound recordings, architectural works—fixed in any tangible medium of expression, now known or later developed, from which they can be perceived, reproduced, or otherwise communicated, either directly or with the aid of a machine or device. In no case, however, does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work. 17 U.S.C. § 102.

  7. Frank Kendall III, Getting Defense Acquisition Right 71 (2017)(emphasis added), https://dod.defense.gov/Portals/1/Documents/pubs/Getting-Acquisition-Right-Jan2017.pdf.

  8. Compare, e.g., U.S. Dep’t of Def., Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs (January 2017), http://www.acq.osd.mil/se/docs/2017-RIO.pdf; U.S. Dep’t of Def., DoD Program Manager’s Guidebook for Integrating the Cybersecurity Risk Management Framework (RMF) into the System Acquisition Lifecycle (Version 1.0 Sept. 2015), https://www.dau.mil/tools/Lists/DAUTools/Attachments/37/DoD%20-%20Guidebook,%20Cybersecurity%20Risk%20Management%20Framework,%20v1.08,%20Sep%202015.pdf; U.S. Dep’t of Def., Guidelines for Creating and Maintaining a Competitive Environment for Supplies and Services in the Department of Defense (Aug. 2014), http://bbp.dau.mil/docs/BBP%202-0%20Competition%20Guidelines%20(Published%2022%20Aug%202014).pdf; U.S. Dep’t of Def., Defense Acquisition Guidebook, https://www.dau.mil/tools/dag; U.S. Dep’t of Def., Product Support Manager Guidebook (Apr. 2016), https://www.dau.mil/tools/t/Product-Support-Manager-(PSM)-Guidebook; U.S. Dep’t of Navy, Software Criteria and Guidance for Systems Engineering Technical Reviews (SETR): Supplement to Guidebook for Acquisition of Naval Software Intensive Systems (Version 1.0, Sept. 2010), http://www.secnav.navy.mil/rda/OneSource/Documents/Program%20Assistance%20and%20Tools/Handbooks,%20Guides%20and%20Reports/Page%205/supplementtoguidebook.pdf; U.S. Dep’t of Navy, Guidebook for Acquisition of Naval Software Intensive Systems (Version 1.0, Sept. 2008), http://www.acqnotes.com/Attachments/Guidebook-for-Acquisition-of-Naval-Software-Intensive-Systems-Sept-2008.pdf; U.S. Dep’t of Air Force, United States Air Force Weapon Systems Software Management Guidebook (Version 1, 15 Aug. 2008)(abridged version), http://www.acqnotes.com/Attachments/USAF%20Weapon%20System%20Sofware%20Management%20Guide.pdf; U.S. Dep’t of Army, Army Data & Data Rights (D&DR) Guide: A Reference for Planning and Performing Data Acquisition and Data Management Activities Throughout the DoD Life Cycle (1st ed. Aug. 2015), https://www.acq.osd.mil/dpap/cpic/cp/docs/Army_Data_and_Data_Rights_Guide_1st_Edition_4_Aug_2015.pdf; CENDI Secretariat, Frequently Asked Questions about Copyright and Computer Software: Issues Affecting the U.S. Government with Special Emphasis on Open Source Software (CENDI/09-1) (Oct. 10, 2010 Revision), https://cendi.gov/publications/09-1FAQ_OpenSourceSoftware_FINAL_110109.pdf; U.S. Small Business Administration, Small Business Innovation Research (SBIR) Program Policy Directive (Feb. 24, 2014), http://sbir.gov/sites/default/files/sbir_pd_with_1-8-14_amendments_2-24-14.pdf; U.S. Dep’t of Air Force, Air Force Materiel Command, Air Force Materiel Command JA Data Rights Handbook (May 2010).

  9. See, e.g., James G. MCEwen, David S. Block, Richard M. Gray & John T. Lucas, IP and Technology in Government Contracts: Procurement and Partnering at the Federal and State Level (2015-2016 ed.); Ralph C. Nash, Jr. & Leonard Rawicz, Intellectual Property in Government Contracts (6th ed. 2008).

  10. The Defense Acquisition University (DAU) offers training on this subject via the following courses:

    Course Number

    Course Title

    Method of Instruction

    ACQ 101

    Fundamentals of Systems Acquisition Management

    Online

    ACQ 202

    Intermediate Systems Acquisition, Part A

    Online

    ACQ 370

    Acquisition Law

    Resident

    CLE 012

    DoD Open Systems Architecture (OSA)

    Online

    CLE 068

    Intellectual Property and Data Rights

    Online

    CLM 071

    Introduction to Data Management

    Online

    CLM 072

    Data Management Strategy Development

    Online

    CLM 073

    Data Management Planning System

    Online

    CLM 075

    Data Acquisition

    Online

    CLM 076

    Data Markings

    Online

    CLM 077

    Data Management Protection and Storage

    Online

    LOG 215

    Technical Data Management

    Online

    PMT 401

    Program Manager Course

    Resident

    For details, see http://www.dau.mil/training/default.aspx. On November 3, 2017, the Assistant Secretary of Defense (Logistics & Materiel Readiness (ASD(L&MR)) issued a memorandum stating that effective October 1, 2018, CLE 068 will be a required course for the Defense Acquisition Workforce Improvement Act Life Cycle Logistics Level II certification.

  11. 10 U.S.C. §§ 2302, 2305, 2320, 2321, 2322a, 2386, 2439.

  12. Policy Letter, Assistant Secretary of Defense (Logistics & Materiel Readiness (ASD(L&MR), subject: Life-Cycle Sustainment Plan Outline Version 2.0 (19 Jan. 2017), https://www.dau.mil/tools/Lists/DAUTools/Attachments/12/LCSP%20Plan%20Outline%20Version%202.0%20-%2019%20Jan%202017.pdf; Policy Letter, Under Secretary of Defense (Acquisition, Technology & Logistics)(USD(AT&L), subject: Implementation Directive for Better Buying Power 3.0—Achieving Dominant Capabilities through Technical Excellence and Innovation (9 Apr. 2015), http://www.acq.osd.mil/fo/docs/betterBuyingPower3.0(9Apr15).pdf; Policy Letter, USD(AT&L), subject: Implementation Directive for Better Buying Power 2.0—Achieving Greater Efficiency and Productivity in Defense Spending (24 Apr. 2013), http://bbp.dau.mil/docs/USD(AT&L)%20BBP%202.0%20Implementation%20Directive%20(24%20April%202013).pdf; Policy Letter, USD(T&L), subject: Better Buying Power 2.0: Continuing the Pursuit for Greater Efficiency and Productivity in Defense Spending (13 Nov. 2012), http://www.acq.osd.mil/fo/docs/USD(ATL)%20Signed%20Memo%20to%20Workforce%20BBP%202%200%20(13%20Nov%2012)%20with%20attachments.pdf; Policy Letter, Principal Deputy Under Secretary of Defense (Acquisition, Technology & Logistics)(PD(USD(AT&L), subject: Document Streamlining—Program Strategies and Systems Engineering Plan (20 Apr. 2011), http://www.acq.osd.mil/se/docs/PDUSD-ATLMemo-Expected-Bus-Practice-TDS_AS_SEP-20Apr11.pdf; enclosing Technology Development Strategy/Acquisition Strategy Sample Outline (20 Apr. 2011), http://www.acq.osd.mil/se/docs/PDUSD-Approved-TDS_AS_Outline-04-20-2011.pdf; Policy Letter, Deputy Assistant Secretary of Defense (Systems Engineering)(DASD(SE), Systems Engineering Plan (SEP) Outline (Version 3.0 12 May 2017), https://www.dau.mil/cop/stm/_layouts/15/WopiFrame.aspx?sourcedoc=/cop/stm/DAU%20Sponsored%20Documents/SEP%20Outline%20Version%203.0%2020170512.docx&action=default; Policy Letter, USD(AT&L), subject: Implementation Directive for Better Buying Power—Obtaining Greater Efficiency and Productivity in Defense Spending (3 Nov. 2010), http://www.acq.osd.mil/fo/docs/USD(AT&L)_Implementation_Directive_Better_Buying_Power_110310.pdf; Policy Letter, USD(AT&L), subject: Better Buying Power: Guidance for Obtaining Greater Efficiency and Productivity in Defense Spending (14 Sept. 2010), http://www.acq.osd.mil/fo/docs/USD_ATL_Guidance_Memo_September_14_2010_FINAL.PDF; Policy Letter, Acting USD(AT&L), subject: Technology Development Strategy and Acquisition Strategy Documents (20 Aug. 2010), http://www.secnav.navy.mil/rda/Policy/2010%20Policy%20Memoranda/technologydeelopmentstrategyandacquisitionstrategydocuments.pdf; Policy Letter, USD(AT&L), subject: Data Management and Technical Data Rights (19 July 2007), http://www.acq.osd.mil/log/mr/.mr_library.html/Data_mngmt_policy_ATL_19Jul07-4365-ATL_signed2.pdf; Policy Letter, Department of Defense (DoD) Chief Information Officer (CIO), subject: Clarifying Guidance Regarding Open Source Software (OSS) (16 Oct. 2009), http://dodcio.defense.gov/Portals/0/Documents/FOSS/2009OSS.pdf; Policy Letter, Secretary of the Air Force, subject: Data Rights and Acquisition Strategy (3 May 2006), https://www.dau.mil/cop/DM/DAU%20Sponsored%20Documents/SECAF%20Memo%20Data%20Rights%20and%20Acquisition%20Strategy%203%20May%2006.pdf; Policy Letter, Air Force Service Acquisition Executive, subject: Present a Competitive Acquisition Strategy at Each Program Milestone (26 Aug. 2011), http://bbp.dau.mil/docs/Present%20a%20Competitive%20Acquisition%20Strategy%20(CAS)%20at%20Each%20Program%20Milestone.pdf.

  13. U.S. Dep’t of Def., Dir. 5000.01, The Defense Acquisition System, (12 May 2003), http://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodd/500001p.pdf [hereinafter DoDD 5000.01]; U.S. Dep’t of Def., Instr. 5000.02, Operation of the Defense Acquisition System (7 Jan. 2015), Change 3 (10 Aug. 2017) [hereinafter DoDI 5000.02 Change 3], http://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/500002_dodi_2015.pdf?ver=2017-08-11-170656-430; U.S. Dep’t of Def., Instr. 5000.74, Defense Acquisition of Services (5 Jan. 2016), Change 1 (5 Oct. 2017) [hereinafter DoDI 5000.74 Change 1], http://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/500074p.pdf?ver=2017-10-05-073243-807; U.S. Dep’t of Def. Instr., 5000.75, Business Systems Requirements and Acquisition (2 Feb. 2017) [hereinafter DoDI 5000.75], http://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/500075_dodi_2017.pdf; U.S. Dep’t of Def. Instr., 5230.24, Distribution Statements on Technical Documents (23 Aug. 2012)(incorporating Change 2 effective 1 Nov. 2017), http://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/523024p.pdf; U.S. Dep’t of Def. Instr., 8320.02, Sharing Data, Information, and Information Technology (IT) Services in the Department of Defense (5 Aug. 2013), http://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodi/832002p.pdf; U.S. Dep’t of Def., Manual 4120.24-M, Defense Standardization Program (DSP) Procedures (24 Sept. 2014(incorporating Change 1 effective 13 Dec. 2017), http://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodm/412024m.pdf; U.S. Dep’t of Def., Manual 5010.12-M, Procedures for the Acquisition and Management of Technical Data (May 1993); http://www.esd.whs.mil/Portals/54/Documents/DD/issuances/dodm/501012m.pdf [hereinafter DoD 5010.12-M]; U.S. Dep’t of Def. MIL-HDBK-502A, Product Support Analysis (8 Mar. 2013), http://quicksearch.dla.mil/qsDocDetails.aspx?ident_number=201462 [hereinafter MIL-HDBK-502A]; U.S. Dep’t of Air Force, Manual TO 00-5-3, Technical Manual, Methods and Procedures: AF Technical Order Life Cycle Management (1 Apr. 2016), http://www.tinker.af.mil/Portals/106/Documents/Technical%20Orders/AFD-082216-00-5-3.pdf; U.S. Dep’t of Air Force, Instr. 61-201, Management of Scientific and Technical Information (STINFO) (29 Jan. 2016), http://static.e-publishing.af.mil/production/1/saf_aq/publication/afi61-201/afi61-201.pdf; U.S. Dep’t of Air Force, Instr. 63-101/20-101, Integrated Life Cycle Management (9 May 2017) [hereinafter AFI63-101/20-101], http://static.e-publishing.af.mil/production/1/saf_aq/publication/afi63-101_20-101/afi63-101_20-101.pdf; U.S. Dep’t Of Air Force, Pamphlet 63-128, Integrated Life Cycle Management (10 July 2014) [hereinafter AFPAM63-128], http://static.e-publishing.af.mil/production/1/saf_aq/publication/afpam63-128/afpam63-128.pdf; U.S. Dep’t of Air Force, Space and Missile Systems Center (SMC), Instr. 62-109, SMC Configuration Management (CM) Process (24 May 2017) [hereinafter SMCI62-109], http://static.e-publishing.af.mil/production/1/smc/publication/smci62-109/smci_62-109.pdf; U.S. Dep’t of Air Force, SMC, Instr. 63-104, Software Acquisition Instruction (26 May 2009) [hereinafter SMCI63-104], http://static.e-publishing.af.mil/production/1/smc/publication/smci63-104/smci63-104.pdf.

  14. Institute for Defense Analyses, Department of Defense Access to Intellectual Property for Weapon Systems Sustainment 17 (May 2017), http://www.dtic.mil/dtic/tr/fulltext/u2/1038450.pdf.

  15. Before the reader jumps to the erroneous conclusion that this statement would make Chicken Little proud, we recommend the reader read Phillip Swarts, Missing Flight Data Contributed to Accident that Made AC-130J Unusable, Air Force Times, June 13-20, 2016, at 13, https://www.airforcetimes.com/story/military/2016/06/04/missing-flight-data-contributed-accident-made-ac-130j-unusable/85316098/.

  16. On July 16, 2017, the House Armed Services Committee issued its Committee Report to accompany its proposed National Defense Authorization Bill for Fiscal Year (FY) 2018 (H.R. 2810, 115th Cong. (2017)). When providing the rationale for a provision in that bill (Section 812) relating to the acquisition of IP rights in technical data by DoD that ultimately became Section 835 of the FY 2018 National Defense Authorization Act (NDAA) (Pub. L. No. 115-91), the Report stated that[we] urge[ ] program managers when seeking technical data to consider the particular data that is required, the level of detail necessary, the purpose for which it will be used, with whom the government needs to share it, and for how long the government needs it. . . .H.R. Rep. No. 115-200, at 165 (2017) (emphasis added).

  17. See generally U.S. Dep’t of Def., Department of Defense Guidebook for Acquiring Commercial Items, Part A: Commercial Item Determination (Jan. 2018), https://www.acq.osd.mil/dpap/cpic/cp/docs/Guidebook_Part_A_Commercial_Item_Determination_20180129.pdf.

  18. The objective of the U.S. Air Force Unmanned Aerospace Systems (UAS) Command and Control (C2) Standard Initiative (UCI) is to establish an open standard set of messages for machine-to-machine, mission-level C2 for airborne systems enabling interoperability and easy integration of new services and reuse of services between programs, thereby decreasing acquisition and operational costs of UAS. The UCI language is defined by a message set derived from an XML schema and are intended to standardize communication between a postulated Common Mission Control Center (CMCC), current and next-generation of UASs and Unmanned Aerial Vehicles (UAV), and other external uses. They are not intended to standardize the low-level C2 interfaces that exist between current generation UAVs and their ground station. The UCI standard is currently being used by several government/industry programs and is owned by the U.S. Air Force. The initial governing body is composed of the original industry consortium members. For further information, see https://www.vdl.afrl.af.mil/programs/oam/uci.php (last visited October 10, 2018).

    In a similar manner, the objective of the U.S. Air Force’s Open Mission System (OMS) initiative is to develop industry consensus for a non-proprietary mission system architectural standard that enables affordable technical refresh and insertion, simplified mission systems integration, service reuse and interoperability, and competition across the life cycle. Industry partners developed and agree upon a set of open key interfaces and architectural guidelines to achieve the objective of the OMS initiative. For further information, see https://www.vdl.afrl.af.mil/programs/uci/oms.php (last visited October 10, 2018).

  19. Memorandum, Commander, Air Force Space Command, subject: UCI Planning and Implementation Guidance (TS//SCI//SAP) AFSPC/CC Memo, 7 April 2017 (U//FOUO), Space Battle Management, Command and Control (BMC2) Operational Prototype Program Endorsement) (10 Jan. 2018) [hereinafter AFSPC/CC Memorandum].

  20. See also U.S. Dep’t of Def., DoD Open Systems Architecture Contract Guidebook for Program Managers (v.1.1, June 2013), https://www.dau.mil/cop/pm/_layouts/15/WopiFrame.aspx?sourcedoc=/cop/pm/DAU%20Sponsored%20Documents/DoD%20Open%20System%20Architecture%20(OSA)%20Contract%20Guidebook%20for%20Program%20Managers-version%201.1-%20June%20%202013.pdf&action=default; U.S. Dep’t of Air Force, Standard Process for Implementing Open Systems Architecture (Version 1.0 Feb. 2017); The Open Group™ Future Airborne Capability Environment (FACE™) Contract Guide: Guidance in Writing Solicitations and Proposals with FACE™ Requirements (Version 1.0 December 2014), http://www.opengroup.org/face/information#published; U.S. Dep’t of Navy, Naval Open Architecture Contract Guidebook for Program Managers (Version 2.0, 30 June 2010), http://www.dtic.mil/dtic/tr/fulltext/u2/a550060.pdf; North Atlantic Treaty Organization (NATO) Standardization Agency (NSA), Standardization Agreement 4586 (Edition 4), Standard Interfaces of Unmanned Aircraft (UA) Control System (UCS) for NATO UAV Interoperability—Interface Control Document (5 Apr. 2017).

  21. AFSPC/CC Memorandum, supra, at note 19.

  22. Joseph T. Hallinan, Why We Make Mistakes: How We Look Without Seeing, Forget Things In Seconds, and are All Pretty Sure We Are Way Above Average 189 (2009). Accord Walter Isaacson, Steve Jobs 80 (2011) (identifying the “defining precept of Jobs’s design philosophy[ as] ‘Simplicity is the ultimate sophistication’”).

  23. Matthew S. Simchak, Protecting Rights in Technical Data and Computer Software: Applying The Ten Practical Rules and Their Corollaries, 33 Pub. Cont. L.J. 139, 148 (Fall 2003).

  24. 2 U.S. NASA, Report to the President by the Presidential Commission on the Space Shuttle Challenger Accident, Appendix F (“Personal Observations on Reliability of Shuttle” by R.P. Feynman) p. F-5 (June 6, 1986)(“[f]or a successful technology, reality must take precedence over public relations, for nature cannot be fooled”), http://history.nasa.gov/rogersrep/v2appf.htm.

  25. A DID is a form that defines the intended use, preparation instructions and content and format requirements for a specific data product. The ASSIST database (https://assist.dla.mil/online/login/mainframe.cfm) is the official source for DoD specifications and standards (e.g., DIDs). If one does not know the Document ID number for a DID (e.g., “DI-IPSC-81441A”) or the words in the title of the DID (e.g., “Software Product Specification”), we recommend the reader consult the DID Selector in the ASSIST database. That resource helps users locate active DIDs that have been identified for priority consideration by subject matter experts within each Military Department. Users may search for DIDs that will require the delivery of data or computer software to efficiently and cost effectively operate and support weapons systems throughout their acquisition and logistics life-cycle by Product Support Elements, by common WBS elements, or by Standardization Areas.

  26. 1 U.S. Dep’t of Def., Armed Services Pricing Manual § 9.5 (p. 9-29)(1986) [hereinafter ASPM], http://www.library.dau.mil/ASPM_v1_1986.pdf. In 1996, FAR 15.404-1(a)(7) replaced the ASPM with the Contract Pricing Reference Guides. Since, however, those Guides no longer include the detailed information found in the ASPM, the ASPM remains a useful reference for SSEBs to use when analyzing whether an offeror’s estimated total price for a proposed CDRL is fair and reasonable (and if necessary, realistic).

  27. Russell L. Parr, Intellectual Property: Valuation, Exploitation, and Infringement Damages 132 (5th ed. 2018).

  28. See, e.g., Midaxo®, M&A Academy Comprehensive Due Diligence Checklist Excel® spreadsheet, Legal Due Diligence Tab, “R&D & Software” Rows 150-188, http://info.midaxo.com/e1t/c/*W1gj3SK2y6lHMW595mWt3tT8q-0/*N2mhcYQWQMK_W5ByXLK8nqtBw0/5/f18dQhb0Sq5J8X-ft7W8cT7z_51vPb-N5sqSg_vLChwVsgWvd5711pQW5r8vwP3mm44rW5y5Lpm3MxVkHW8mHrFV8tBNs8W1qftmS6TLjJkW8pC3-Y1kkTkgW6cDMb-66P9VsVQfnmS8rZpywW3MxmnX3PnXqxW3qcjNq4cs7t0W4kr5qD5124H6W47_j1Q6lBQpBW5klsvy6bMX3wW6vGSSV2HVTVLW4DqHqz6dgmw3W4yv2r03LmJLKW20Y98h1YfY8XW5hkTxh5mg0ggW3XYLLm3SYkDTW5VSntZ5K_zXKW3lj2tv3blhRkW6fCWGM5vQslTN5v7vMGR8lvhW8vq4Qk3-cXVFW5LY-DC3GZ-hcM_3zk8GLMmFW3sbDQn8znYdnVLktbN3ZL4SdW5kfCJH3TXQMqW3S0mBT5DGNQjW3x8GFv5v6SsXVLdB9732CH-CN8d66_lk8xjrW7KvtPT6cw56dW6hz0s82bzNQYW5_rBl46wlYh1N567_GnL6fhdW567YXf4J3dnGW714h8Z1ny0SCW9jjp5p90lk07W5CwsYD8kqrNQW7L9PMy7vQ2pSW3G6crC13fYwcMcTSRKcSqFvf6V88Pp02 (last visited October 10, 2018).

  29. Financial Accounting Standards Board, (FASB) Accounting Standards Codification (ASC) 805-20-25 (Recognition) [hereinafter FASB ASC], https://asc.fasb.org/section&trid=2899170 (last visited October 10, 2018); FASB ASC 820-10-55-3 (Valuation Techniques), https://asc.fasb.org/section&trid=2155964 (last visited October 10, 2018); American Institute of Certified Public Accountants (AICPA), Statement on Standards for Valuation Services: Valuation of a Business, Business Ownership Interest, Security, or Intangible Asset § 31 (p. 16)(June 2007); Intellectual Property: Valuation, Exploitation, and Infringement Damages, supra, note 27 at 67-154; Robert F. Reilly & Robert P. Schweihs, Guide to Intangible Asset Valuation 4-5, 220-228, 236, 258-259, 271-272, 305-306, 311, 315-317, 404-405, 408-409, 583-584, 590-593, 684-686 (rev. ed. 2014).

  30. See generally, U.S. Dep’t of Def., Department of Defense Guidebook for Acquiring Commercial Items, Part B: Pricing Commercial Items (Jan. 2018), https://www.acq.osd.mil/dpap/cpic/cp/docs/Guidebook_Part_B_Commercial_Item_Pricing_20180126.pdf.

  31. Henry Petroski, To Engineer is Human: The Role of Failure in Successful Design 231-232 (1992) (emphasis added).

  32. 2 U.S. Dep’t of Def., Report of the Advisory Panel on Streamlining and Codifying Acquisition Regulations 49-50 (June 2018)(emphasis added), https://section809panel.org/wp-content/uploads/2018/06/Sec809Panel_Vol2-Report_June18.pdf.

+Notes
+Bookmarks