What Contractors Need to Know About DoD’s New IP Guidebook

Earlier this year, the Department of Defense (DoD) published an “Intellectual Property Guidebook for DoD Acquisition.” It is the culmination of many years of work and the most insightful data rights guidance out of the Department in at least two decades. Private practitioners may not agree with every characterization of the law and data rights regulations, but the IP Guidebook is particularly commendable for its transparency into DoD’s strategic framework for IP negotiations. Although written for government acquisition professionals, it should be mandatory reading for anyone delivering proprietary technology to DoD or defense contractors.

Here are a few key takeaways for contractors:

1. Expect More “Use Case” and “VATEP” Solicitations.

DoD’s IP strategy is built largely around the ideal of competitive, interest-based negotiations early in the acquisition lifecycle.[1] To facilitate such negotiations, DoD has experimented in recent years with different solicitation criteria encouraging offerors to propose broader rights in data deliverables than those required by the DoD Federal Acquisition Regulation Supplement (DFARS), with the stated hope that competitive forces will drive down prices. Of these techniques, the IP Guidebook specifically endorses “Use Cases” and a Value-Added Total Evaluated Price (VATEP) as two best practices, often used in tandem.

The concept of “use cases” appears throughout the IP Guidebook. The goal is to focus DoD program teams on the specific data deliverables and associate license rights they need, and on what timeline, to fulfill mission objectives. Well-drafted use cases account for What (data is needed), Why (i.e., to accomplish what specific task), Who (needs to use the data, e.g., the entire Government, a government depot, third-party integrator, or support contractors), Where (the data will reside and be used), When (the data will be used, e.g., daily or in a contingency, now or 20 years in the future), and How (the data will be used beyond the core task, e.g., additive manufacturing, competition, or reprocurement). The IP Guidebook offers the following example: “Engine [technical data] is needed to conduct scheduled maintenance by active-duty maintainers in CONUS and OCONUS locations every 250 flight hours for the life of the system.”

By incorporating these functional needs into a solicitation, DoD can – at least in theory – avoid overbroad demands and pay only for the data rights it needs. It can also open the door further to priced options and contingency-based springing licenses, both of which are suggested by the IP Guidebook for appropriate circumstances. If done well, use cases can also pass the ball to industry to develop creative licenses that better protect commercial interests while meeting the government’s specific mission needs.

Often in practice, a solicitation will state a number of use cases for which the agency has determined it needs certain data rights, whether those are traditional government purpose rights or a specifically negotiated license defined in the solicitation. The offeror is required to identify all data deliverables that may be necessary to perform a given use case and any data rights restrictions (e.g., limited rights, restricted rights) they or their suppliers assert for data in those deliverables. In some cases, offerors may be asked to propose a price to grant the Government’s desired rights in lieu of those restrictions, and those proposed prices may be included in the offeror’s overall evaluated price. Or a solicitation may adopt a VATEP process specifying other evaluated price adjustments that will be made for granting certain rights. If the offeror declines to propose a price or otherwise grant such rights, it may receive weaknesses or lose strengths in qualitative evaluation criteria.

Contractors should be prepared to see more data rights use cases in solicitations going forward. When responding, it is important to think comprehensively about the data necessary to perform a use case and any data rights assertions that could apply. Once under contract, it can be difficult to make new assertions affecting an agreed-upon use case, even if arising out of new information such as turnover in the supply chain.

Contractors should also think early about how to price such licenses and be prepared to support the reasonableness of their pricing. DoD has been working for several years to develop best practices for valuing IP rights, which the IP Guidebook discusses briefly without endorsing any particular method. Be careful of a tendency to reduce the value of an IP license to the costs incurred developing the underlying asset – what the IP Guidebook refers to as the “Cost” method of valuation. Industry, by contrast, more often looks to the costs a competitor would likely incur developing the IP asset or a suitable alternative rather than the costs actually incurred by the original developer. The IP Guidebook recognizes other methods, such as “Income” or “Market” based methods or some hybrid between them, may be appropriate. Choosing the right method often depends heavily on the circumstances and may warrant a third-party valuation assessment.

2. Beware Form, Fit, and Function Data and OMIT Data overreach in the name of MOSA.

Also factoring heavily into DoD’s IP acquisition strategy is its embrace of modular open systems approaches, or MOSA. MOSA is primarily a design philosophy emphasizing the use of segregable components that can be upgraded or replaced without affecting the system as a whole. But to fully enable MOSA, the interfaces linking various modules must either be designed to a common standard or provided to DoD with sufficient data rights to plug and play. In theory, MOSA can better protect contractor IP by confining it to black boxes and refocusing data rights needs on the interfaces between those boxes, a point the IP Guidebook emphasizes. The difficulty in execution, however, lies in reasonably defining the edges of those black boxes without encroaching on private developments.

DoD has proposed (but not yet implemented) many MOSA-related updates to its data rights regulations. These include defining new categories of data such as “interface implementation data” in which the Government will receive at least government purpose rights. Such data would, presumably, be something other than the existing categories of “form, fit, and function data” and data “necessary for installation, operation, maintenance or training purposes (other than detailed manufacturing or process data),” otherwise known as “OMIT data,” in which the Government receives unlimited rights regardless of development funding. The IP Guidebook makes no secret that DoD intends to leverage its rights in form, fit and function data and OMIT data – and expand each category to include interface-related data – to achieve its MOSA goals while it waits for the regulatory changes to unfold.

Such an approach risks overreach. Per the current regulations, form, fit, and function data describe “required overall physical, functional, and performance characteristics” only “to the extent necessary to permit identification of physically and functionally interchangeable items.” They describe the physical boundaries of an item (form and fit) and what it does (function), so one may identify a replacement part, but they do not describe in detail how the item communicates with or acts upon other parts, not how one might go about decoupling or reintegrating it within the system. OMIT data, on the other hand, include only the data “necessary” to operate, maintain, or install an item or to train a user to do the same and expressly exclude “detailed manufacturing or process data,” sometimes called “DMPD.” These excluded DMPD describe “the steps, sequences, and conditions of manufacturing, processing, or assembly used by a manufacturer to produce an item or component or to perform a process.” By contrast, true OMIT data include things like owner’s manuals, user’s manuals, and installation guides, but the category does not encompass data sufficiently detailed to enable someone to reproduce an item or perform a proprietary process, which rightfully may be protected by the contractor if developed at private expense. By definition, there should be no overlap between DMPD and OMIT data and very little if any overlap between DMPD and form, fit, and function data, yet DoD in recent years has often blended the categories.

The IP Guidebook adds to this confusion by suggesting both form, fit, and function data and OMIT data can include DMPD. This is not merely a semantic distinction, as confusion of the categories results in a data rights grab (which may or may not be intended) by redefining form, fit, and function data and OMIT data more broadly than the regulations. Take this example from the IP Guidebook: “DMPD for some physical part should have dimension and tolerance information and that same dimension and tolerance information would also be necessary in [form, fit, and function] data and therefore receives Unlimited Rights.” Yet physical dimensions and tolerances are not DMPD; sure, a manufacturer needs to know the dimensions of the parts it is making, but those data do not “describe the steps, sequences, and conditions of manufacturing, processing or assembly.” Similarly, the IP Guidebook refers to data that “is necessary for OMIT purposes but is also DMPD used for detailed manufacturing or process,” but it does not explain how detailed manufacturing information could be “necessary” to operate, maintain, or install an item. In addition, OMIT data as a category, to the extent it has any foundation in the statutory or regulatory text, excludes DMPD by definition.[2]

Contractors should take careful note of the examples DoD offers in its IP Guidebook. As form, fit and function data, it lists engineering drawings such as “Design/Interface control-type drawings,” configuration management, SysML/UML models, interface control documents, depot maintenance work requirements, technical bulletins for disassembly and reassembly, repair and overhaul procedures, and engineering data for provisioning. As OMIT data, it lists Level of Repair Analyses; Failure Mode, Effects, and Criticality Analyses; bills of materiel; provisioning data; test incident reports; “diagrams, XML, schematics”; “quality reports, quality deficiency reports”; and “Modeling & Simulation referent data.” Some of these documents may contain data properly characterized as form, fit, and function data or OMIT data, but often they will contain much more. Beware attempts at overreach in the name of MOSA.

3. DoD wants to resolve data rights disputes earlier in the contracting lifecycle.

DoD has often voiced frustration with the sometimes lengthy process of resolving disagreements over the validity of data rights assertions. The IP Guidebook recommends two solutions: incorporate data rights into solicitation evaluation criteria, as discussed above, or begin challenging data rights assertions prior to contract award. Both seek to leverage competitive forces and the Government’s relative bargaining power early in the contracting lifecycle to drive more favorable data rights outcomes.

The IP Guidebook admits pre-award challenges are discouraged by the DFARS, which advises waiting until contract performance unless earlier resolution is “essential for successful completion” of the procurement. DFARS 227.7103-13(b); DFARS 227.7203-13(d)(1). And the IP Guidebook acknowledges that burdening the contract award process with data rights challenges can cause significant delays. But it nevertheless encourages contracting officers to take advantage of the Government’s greater “leverage and freedom to maneuver prior to awarding a contract” where they can, particularly in sole-source acquisitions.

When it comes to data rights assertions and potential validation challenges, a good rule for contractors is to stay ready so you don’t have to get ready. Contractors should maintain records of development at private expense in organized, centralized, easy-to-access files, exempted from records destruction policies. This is especially true if facing more pre-award challenges, which for practical purposes may move more quickly and with less leniency in deadlines than post-delivery challenges.

4. Other Transactions (OTs)

When DoD issued its most recent OT Guide, in July 2023, it removed an appendix of “Intellectual Property Considerations” in anticipation that the guidance would be covered in the then-forthcoming IP Guidebook. And in that respect, the IP Guidebook delivers: it incorporates much of the same guidance from the prior OT Guide, with only minor revisions. Still, there are a few highlights worth mentioning, especially as OTs step into the forefront of DoD acquisition.

• OT Funds are Not “Government Funds” for Purposes of the DFARS. The DFARS data rights clauses grant rights to the Government based on the extent to which an item, component, process, or software was developed at private expense or with Government funds, not whether it was developed under any particular contract. The Armed Services Board of Contract Appeals has held that federal funds provided under a grant or cooperative agreement are not “Government funds” as defined in the DFARS because such agreements are not “contracts” – indeed, they are expressly excluded from the definition of “contract” in the Federal Acquisition Regulation (FAR). The Boeing Co., ASBCA No. 60373, 18-1 BCA ¶ 37,112. There is no similar express exclusion for OTs, but the same principle logically extends to them as well. This fact is recognized in the IP Guidebook, which unambiguously adopts the position that OT funding is not Government funding for purposes of the DFARS data rights funding test. This does not mean, of course, that the Government does not have rights in data related to items, components, processes, or software developed under OTs (or grants or cooperative agreements); it merely means that those rights are defined by the specific OT (or grant or cooperative agreement) and not superseded by a later award of a DFARS-based procurement contract.

• Authorization and Consent. In most FAR-based contracts, the Government expressly authorizes and consents to the contractor’s infringement of any U.S. patent embodied in or necessary to produce accepted end items or comply with contract directions. See FAR 27.201-2(a)(1); FAR 52.227-1. Contracts for research and development (R&D) work go even further and expressly authorize and consent to infringement of any U.S. patent in the performance the contract. See FAR 27.201-2(a)(2); FAR 52.227-1, Alt. I. This protects the contractor (and the Government) from work stoppages in the event of a third-party infringement lawsuit. Without authorization and consent, a potentially infringing contractor may be enjoined from contract performance by a federal court. The IP Guidebook recognizes this risk; but, even though DoD OTs for prototype projects are, almost by definition, for R&D work, the IP Guidebook stops short of recommending broad authorization and consent in OT agreements. This unfortunately has resulted in many contracting officers expressly withholding authorization and consent, on the often misguided assumption that doing so reduces risk to the Government. Contractors should beware of and push back on such clauses.
• IP Indemnity. In a similar vein, contractors acting with the Government’s authorization and consent are sometimes asked to indemnify the Government for damages resulting from any patent infringement. The FAR limits such indemnification only to contracts for commercial products or commercial services, where, in theory, the contractor is better positioned to absorb the risk of infringement. Yet, for noncommercial supplies and services – like those provided under many OTs – the FAR does not require or even recommend indemnification. Again, the IP Guidebook mentions this allocation of risk but does not clearly discourage agreements officers from requiring indemnification where it is not appropriate. Much to the contrary, the IP Guidebook appears to recommend broad adoption of indemnity clauses by noting they “mitigate the [Government’s] risk of extra costs caused by infringement of a third-party owned patent,” without also explaining that they pass those costs onto the contractor and thus promote risk aversion in agreements that are meant for innovation. Contractors should beware of these clauses as well and push back where they are not appropriate.
• Sometimes consistency with the DFARS can be helpful. Too often, agreements officers seek to avoid familiar and well-tested data rights provisions simply because they are in the DFARS. This can have unintended consequences and cause unnecessary confusion. The IP Guidebook thankfully recognizes this and discourages agreements officers from modifying definitions of well-known terms such as “limited rights” or “government purpose rights,” or from incorporating DFARS data rights clauses by number while modifying their text. Similarly, the IP Guidebook cautions agreements officers that bespoke marking requirements can hinder widespread data utilization and increase compliance risk where OT-related data needs to be disseminated and stored in the larger DoD data ecosystem.

5. DoD is interested in your data, not your patents.

For a text on IP acquisition strategies, the IP Guidebook has amazingly little to say about patents. They appear rarely and mostly in passing, and they are meaningfully discussed only in connection with OTs (and even that is brief). Yet the omission is not altogether surprising or likely inadvertent: DoD is much more focused on acquiring data and data rights than it is on acquiring rights in patents. When the Government does not have the data or data rights to do something, it has little option but contract with the vendor who does or pay someone for an alternative. But when the Government does not have rights in a patent, it can just go ahead and do whatever it was going to do anyway, so long as it reasonably compensates the patent owner (and in practice even that assumes the patent owner diligently seeks compensation under 28 U.S.C. § 1498). Add the fact that the Government typically receives a broad license in any patents made in the performance of a government contract, and you can see why securing patent licenses is less of a concern to DoD acquisition teams. The scant treatment of patents in the IP Guidebook seems to confirm as much.

6. DoD is reluctant to set rules for licensing commercial data.

The IP Guidebook also has very little to say about acquiring commercial technical data or commercial computer software. In this case, though, that is not because DoD is not focused on accessing commercial technologies or licensing commercial IP. More likely it reflects a decision that DoD should strive to adopt and respond to commercial best practices as they evolve, much like other consumers in the commercial marketplace, without the burden of extensive bureaucratic guidance. For the most part, DoD acquires only those technical data that other commercial customers receive and, where appropriate, must protect them as proprietary (with some exceptions). And, for the most part, DoD acquires commercial computer software on whatever licensing terms are used in the commercial marketplace at the time, unless federal law or specific user needs require otherwise. The IP Guidebook declines to expand on – or thereby risk confining – these guiding principles.

[1] In addition to the IP Guidebook, this is captured in official acquisition policy in DoD Instruction 5010.44, IP Acquisition and Licensing, available here.

[2] See 10 U.S.C. § 3771(b)(3)(C) (listing categories of data exempt from protections for private development, including specifically data “necessary for operations, maintenance, installation, or training (other than detailed manufacturing or process data…)”; DFARS 252.227-7013(b)(1)(v) (same, identifying the category as data “necessary for installation, operation, maintenance, or training purposes (other than detailed manufacturing or process data)”).