Your rights in technical data and software are at greater risk today than at any time during the last 25 years. The Department of Defense (“DOD”) is proposing the authority to rewrite commercial software licenses in ways never before seen and guaranteed to be rejected by your software suppliers, as well as proposing authority to pressure you – in the guise of “specially negotiated license rights” — to negotiate away your most valuable intellectual property rights while increasing your data delivery obligations. And the DOD is doing this in plain view, if you know what to look for.
That is the first purpose of this article: to tell you where to look and how to break DOD’s code, see through its camouflage, translate its happy talk, pull back the curtain, etc. – apt metaphors for being able to recognize the crucial differences between what you now are seeing and hearing from DOD and what its words really mean. The second purpose is to suggest (at the end) practical steps you should consider taking immediately to address the DOD’s actions and diminish your risk.
How We Got Here
In June 1995, after years of discussions with industry, DOD issued a comprehensive and equitable rewrite of the Defense Federal Acquisition Regulation Supplement (“DFARS”) addressing rights in technical data and in noncommercial computer software and software documentation. 1995 was about the high water mark of the DOD’s professed affection for commercial items, including software, and DOD’s respect for contractors’ technical data investments. Regrettably, the water has been draining away ever since; and with it the DOD’s fidelity to the core principals of those enlightened regulations and their contract clauses (our familiar friends at 252.227-7013 & -7014). And things quickly will be getting much worse for industry’s rights in data, unless industry understands what is happening right now and pushes back on DOD’s proposed regulations and legislative agenda.
Let us look at two overarching principals of the 1995 regulations that are most at risk – i.e., embracing commercial software and protecting private investment.
First, in 1995 DOD took the remarkable step of eliminating any DFARS clause for commercial computer software. There is none to be found. This makes a great deal of sense if one’s goal is – as DOD’s was — to encourage innovative private-sector software developers to offer their clever advanced technology to the DOD. How better to do this than by eliminating contract clauses alien to the commercial world. Instead, commercial computer software “shall be acquired under the licenses customarily provided to the public unless such licenses are inconsistent with Federal procurement law or do not otherwise satisfy user needs.” DFARS 227.7202-1(a)(emphasis added). The “unless” in that sentence leaves room for mischief, but DOD largely has confined this exception to rejecting commercial license terms that conflict with sovereign rights. One really cannot, for example, litigate government contract disputes through AAA arbitration applying California law.
The DOD correspondingly imposed clear limits on what contracting activities could do to infringe commercial software rights: “Offerors and contractors shall not be required to —
Relinquish to, or otherwise provide, the Government rights to use, modify, reproduce, release, perform, display, or disclose commercial computer software or commercial computer software documentation except for a transfer of rights mutually agreed upon. DFARS 227.7202-1(c)(emphasis added). These common sense and longstanding rules are in jeopardy.
The second overarching principle was for DOD to acquire only the noncommercial technical data and software “necessary to satisfy agency needs” (e.g., 227.7103-1(a)) while respecting contractors’ private investment by precluding overt government coercion. This is seen in DFARS 227.7103-1(c), which essentially quotes verbatim the prohibitions of DOD’s main data rights statute, 10 USC §2320(A)(2)(h):
Offerors shall not be required, either as a condition of being responsive to a solicitation or as a condition for award, to sell or otherwise relinquish to the Government any rights in technical data related to items, components or processes developed at private expense….[227.7103-1(c)].
Congress provided only limited exceptions to these preclusions and only for technical data, not software, allowing for unlimited government rights in “form, fit, and function data” (defined fairly[1]) and technical data “necessary for installation, operation, maintenance, or training [OMIT] purposes….” Recognizing, however, that government personnel inevitably would attempt to construe the definition of OMIT so expansively as to swallow all technical data, Congress wisely excluded contractors’ most important technical data from omit – their “detailed manufacturing or process data [DPMD]” — which are “the steps, sequences, and conditions of manufacturing, processing or assembly used by the manufacturer to produce an item or component or to perform a process.” DFARS 252.227-7013(a).
All this worked well, more or less, for about 20 years. Then the DOD got restive. No matter what you hear from DOD upper echelons, the facts on the ground are the DOD views your statutory and common sense rights – accruing because of your time, money, and talent — to assert limited or restricted rights as “vendor lock,” harmful to DOD.
“Vendor lock?” What a truly curious, pejorative phrase to describe what the rest of the free world calls innovation and free enterprise. Think of it this way: If any DOD Secretary, Admiral, or General had developed the world’s fastest computer — worth millions of dollars in future sales and licensing — in her garage, on her own time, with her own money (and some borrowed from her spouse’s 401K), blood, sweat and tears, and without a dime being paid to her under a DOD contract, do you think the Secretary, Admiral, or General would happily agree that doing exactly what the data rights statutes and regulations permit her (and your company) to do in these circumstances – restrict the government’s rights in the software and control its use – is “vendor lock” to be remedied? Or agree the government should have the right to eliminate her future competitive position, not to mention future income, by asserting unlimited or government purpose rights in her software; or force her to give up her vested rights as a condition of doing business with the government? Oh, hell no. But that is the result DOD has been creeping toward, so far without success but with undaunted ambition.
For example, during the past five years various DOD entities have embarked on the following unsuccessful efforts:
- RFP provisions requiring giving up rights as a condition of award.
- A congressional push to grant DOD a perpetual right to order delivery of data or software DOD forgets to include as a deliverable (would they forget an airplane?) and pay you only the cost of reproduction.
- Contract clauses attempting to grant OMIT rights in software, directly contrary to law. (See “Data Rights Assault: What in the H (clause) Is Going On Here? Air Force Overreaching On OMIT Data,” The Government Contractor FEATURE COMMENT, January 2018.)
- Lobbying Congress to eliminate due process protections when the government challenges your data rights assertions by permitting the DOD to disseminate your data and software pending a dispute and allowing contractors only a damage right.
- Lobbying Congress for the right to give your most closely held trade secrets – e., all your detailed limited-rights manufacturing and process data – to your most vicious competitors whenever DMPD might be deemed useful for OMIT purposes. (See “The Data Rights Black Hole: DOD Lobbies Congress to Eliminate Proprietary Rights in Your Most Valuable Trade Secrets – Your Detailed Manufacturing And Process Data,” Morrison & Foerster Government Contracts Insights, April 2020.)
Foreshadowing The Future
Tired of being rebuffed, DOD is taking a more nuanced approach, as described in an October 2019 DOD Instruction that should be required reading for contractors’ proposal teams. It is “DOD INSTRUCTION 5010.44 INTELLECTUAL PROPERTY (IP) ACQUISITION AND LICENSING Originating Component: Office of the Under Secretary of Defense for Acquisition and Sustainment Effective: October 16, 2019.” This is a well-written roadmap for how DOD is going to pursue acquisition of rights in contractors’ data and software, and reflects incremental gains DOD has achieved with Congress.
Although its Policy Statement appears at first to be neutral and balanced, it subtly sets the stage for DOD’s aggressive actions that follow and are now pending, as we will see:
1.2. POLICY. Weapon and information systems acquired by DoD in support of the warfighter are, and will be, increasingly dependent on technology for its operation, maintenance, modernization, and sustainment. Acquiring and licensing the appropriate IP is vital for ensuring the systems will remain functional, sustainable, upgradable and affordable. Because balancing the interests of the U.S. Government and industry in IP can be difficult, early and effective understanding, planning, and communications between the U.S. Government and industry is critical, as is ensuring delivery, acceptance, and management of the necessary IP deliverables (e.g., technical data and computer software), with appropriate license rights. The DoD requires fair treatment of IP owners, and seeks to create conditions that encourage technologically advanced solutions to meet DoD needs. [Emphases added]
DOD’s Goals and Their Effects
Instruction 5010.44’s “goals” to implement this policy are more overt. Here are two, for example:
- Integrate IP planning fully into acquisition strategies and product support strategies to protect core DoD interests over the entire life cycle.
- Use all available techniques early in the acquisition process for identifying, acquiring, licensing, and enforcing the U.S. Government’s rights to IP necessary to support operation, maintenance, modernization, and sustainment.
Contractor Translation: The emphasized portions are easily translated into real-world acquisition activity and consequences: DOD solicitations increasingly will focus as much on data and software needed for long-term support, maintenance, and upgrades as it will (and largely does today) on IP for current operations. This means increased pressure in competitive proposals to provide broad rights in source code and manufacturing and process data, and at a low price.
Much of this pressure will come from contractor management pushing to lower the company’s price for relinquishing its data rights: “We have to go low; our competitors will, and we will lose.” The problem with this common view not only is it often is incorrect, but also it almost always either is short-sighted or is not based on thoughtful (or any) consideration of the long-term loss of value and market share resulting from giving up valuable rights.
Have you evaluated the value of your data and software? If not, you should start. And the best practice would be to retain an independent third party to make the assessment. The reason you should is that the DOD understands the contractor mindset for low-balling, and will be prepared to advance valuations to support low dollars for your rights. This will put contractors at a disadvantage if they have not done contrasting analyses. DOD is not hiding its ball, as seen in another of DOD’s goal:
Acquire the necessary IP deliverables and associated license rights at fair and reasonable prices. Improve… financial analysis and valuation practices for determining fair and reasonable prices and appropriate needs for IP and IP rights in order to develop program budgets and evaluate proposals.
The FAR Council is evaluating various valuation approaches now, such as Cost (replacement or reproduction cost); Market (comparable sales); or Income (predicted future income stream). Contractor and FAR Council beware, however: the Defense Contract Audit Agency never met an income or market value it liked: “I can’t audit that, it’s too speculative. Tell me instead what it cost to develop and let me see your records?”
Increased Data Rights Pricing Pressure In Negotiations
This pressure is greatest for major weapon systems, due to Section 835 of the 2018 NDAA, which became translated into 10 U.S.C. §2349:
The Secretary of Defense shall ensure, to the maximum extent practicable, that the Department of Defense, before selecting a contractor for the engineering and manufacturing development of a major weapon system, production of a major weapon system, or sustainment of a major weapon system, negotiates a price for technical data to be delivered under a contract for such development, production, or sustainment.
This pressure, however, certainly will not be limited to major weapon systems. This is evident in DFARS Case 2018-DO71, addressing a range of proposed changes to negotiating prices for IP, including negotiating pricing per §867 of the 2019 NDAA:
DFARS Case 2018-D071, Draft Proposed Rule, DFARS 207.106:
(vi) Identify, to the maximum extent practicable, the estimated cost for technical data, computer software, and associated license rights as required by FAR 7.105(b)(14)(iii) and summarize how the contracting officer intends to negotiate a price for the data, software, and license rights. See 215.470(a) regarding the negotiation of a price for the data, software, and license rights.
In turn, these are the proposed revisions to 215.470(a):
[The contracting officer shall]DoD requires [that offerors provide] estimates of the prices of data [and associated license rights] …. [To the maximum extent practicable, before making a source selection decision … the contracting officer shall negotiate a price for data (including technical data and computer software) and associated license rights … for the development, production, or sustainment of a system, subsystem, or component; or services…. [S]uch negotiations should be based upon the use of appropriate intellectual property valuation practices and standards.]
In other words, the DOD will be asking you to put a price on your rights – one it can pit against your competitors.
A New Twist On Specially Negotiated Rights: De Facto Mandatory Negotiations
Another of DOD’s stated goals is to increase the use of specially negotiated rights:
Negotiate specialized provisions for IP deliverables and associated license rights whenever doing so will more effectively balance DoD and industry interests than the standard or customary license rights. This is most effective early in the life cycle, when competition is more likely.
Specially negotiated rights were intended originally to permit flexibility where the DOD previously had none – e.g., giving up unlimited rights. The current perspective is very different; it is intended to get around the 10 USC §2320 preclusion on forcing contractors to give up rights, and doing it when competitive pressures on contractors are the greatest. “Who’s forcing?” asks the CO: “We’re negotiating and paying for rights.”
Those negotiations are on the way, in the form of DFARS Case 2018-D071 proposed revisions to 227.7102-2, Rights in technical data:
(b)(1) [The parties should negotiate special license rights whenever doing so will more equitably address the parties’ interests than the standard license rights provided in the clause. To the maximum extent practicable, if either party desires a special license, the parties shall enter into good faith negotiations]If additional rights are needed, contracting activities must negotiate with the contractor to determine if there are acceptable terms for transferring such rights. [However, the licensor is not obligated to provide the Government greater rights, and the contracting officer is not required to accept lesser rights, than the rights provided in the standard grant of license.]
Well, you say, “That final caveat looks good, and we can decline to negotiate.” In theory, yes, but will you decline in a major procurement? The DOD is counting on you not to. And DOD is emphasizing its ability to bring you to the negotiating table by reiterating what essentially are mandatory negotiations, via another change to the regulations – DFARS 227.7103-5 “Government rights”:
[To the maximum extent practicable, n]Negotiate specific licenses when[whenever doing so will more equitably address the parties’ interests than the standard license rights provided in the clause.] the parties agree to modify the standard license rights granted to the Government or when the Government wants to obtain rights in data in which it does not have rights. [If either party desires a special license, the parties shall enter into good faith negotiations to determine if there are acceptable terms for transferring such rights….] [DFARS Case 2018-D071, emphasis added]
More Rigorous Delivery Requirements
One of the most common misconceptions held by government and contractor personnel is that the data rights clauses require delivery of the data and software for which they define rights. The clauses do nothing of the sort. There is not a word about delivery in them. (See “Taking The Mystery Out of Data Rights,” Briefing Papers 18-8, July 2018.) This makes sense, because the purpose of the clauses is only to define license rights received by the government. If the government requires delivery of technical data or software, it has to specify those things as deliverables just like any other deliverable under a government contract.
Likely because of this misunderstanding, the government has tended to be lax in identifying data deliverables, and even sometimes lax in including “deferred ordering” clauses, such as DFARS 252.227-7027, that would allow the government to order data or software generated in the performance of the contract.
The DOD, understandably, is trying to focus contracting officers and the acquisition corps on the importance of specifying data deliverables. This is reflected in another of DOD’s goals as well as in recent solicitations. Here is the goal:
Identify and match data deliverables with the license rights in those deliverables. Data or software deliverables are of no value unless and until the license rights to use it are attached, and the U.S. Government actually obtains and accepts those deliverables.
Contractor Translation: This means contractors increasingly will be required to create a proposal table that (1) lists all data and software deliverables – for you and all your subcontractors – with (2) their corresponding rights identified, (3) tied to a specific CLIN and CDRL, and with (4) copies of all prime and subcontractor commercial computer software licenses attached.
Your commercial software suppliers also may be required by the RFP to provide noncommercial rights, alien (and often unacceptable) to their business. This will be very difficult for your commercial software suppliers, and there is more bad news in store.
Assault On Commercial Computer Software
Each of the changes proposed above is also being made to the DOD regulations applicable to noncommercial computer software. That is typical practice at DOD; whenever changes are made to the technical data regulations, the DOD strives for consistency in the software regulations. What is atypical is applying those changes to commercial computer software. Recall, the original intent of the DFARS was to eliminate any clause for commercial computer software, but rather to rely principally on contractors’ standard commercial licenses. If the government wanted different rights, it had to negotiate for them but rarely did. And when it did, it typically was to eliminate clauses inconsistent with the sovereign’s rights – e.g., disputes & indemnity.
Now, there is a significant shift in DOD’s emphasis and drive, reflected in two contemplated revisions under Case 2018-D071 and Case 2018-D018. The former anticipates “mandatory” negotiations to modify commercial licenses, while the latter for the first time imposes noncommercial principles on commercial software. Here are excerpts from the cases:
Mandatory Negotiations
Case 2018-D071: 227.7202-3 Rights in commercial computer software or commercial computer software documentation.
(b) [The parties should negotiate special license rights whenever doing so will more equitably address the parties’ interests than the standard license rights provided in the license customarily provided to the public.]If the Government has a need for rights not conveyed under the license customarily provided to the public, the Government must negotiate with the contractor [To the maximum extent practicable, if either party desires a special license, the parties shall enter into good faith negotiations ]to determine if there are acceptable terms for transferring such rights. The specific rights granted to the Government shall be enumerated in the contract license agreement or an addendum thereto [and shall, support the Government’s product support strategy (e.g., as described in the life cycle sustainment plan)]
Noncommercial Rights Applied To Commercial Software
- Case 2018-D018: 227.7202 Commercial computer software and commercial computer software documentation.
227.7202-1 Policy.
[(d) When establishing contract requirements and negotiation objectives to meet agency needs, the Government shall consider the factors identified in 227.7203-2(b) and (c), adapted as appropriate for commercial computer software and computer software documentation.]
Let us pause here for a moment. This sounds innocuous. It is not. DFARS 227.7203-2 has never been applied to commercial software, and for good reason. It has nothing to do with commercial software, until now. And it includes terms that are unknown in commercial software agreements that assuredly will be unacceptable to commercial software suppliers. Think about the consternation that will be created by the bolded portions of the proposed 227.7203-2:
227.7203-2 Acquisition of noncommercial computer software and computer software documentation [and associated rights].
[(2)(i) [The CO]… must address the acquisition at appropriate times in the life cycle of all computer software, related data, and associated license rights necessary to—
(A) Reproduce, build, or recompile the software from its source code and required software libraries;
(B) Conduct required computer software testing; and
(C) Deploy computer programs on relevant system hardware.
(ii) Needs determinations should be made as early as practicable, preferably before or during a competitive phase (10 U.S.C. 2322a).]
Pulling This Together: What All Contractors Should Do Today
These proposals invite action by contractors and their industry groups, such as the Aerospace Industries Association, to comment on the pending changes, challenge them, and work with congressional liaisons to explain why the proposals are contrary to the very things DOD needs – innovation, private investment, and engaging commercial software suppliers.
They also invite internal education for contractor personnel, allowing them to recognize issues when they first arise, raise them with management, and resist them appropriately when necessary. Here are suggestions for actions contractors can take immediately:
- Revisit with your contracts team some of the basics of data rights – g., what is technical data vs. software; what the DFARS data rights clauses do (rights of use) and not do (delivery).
- Carefully review RFPs promptly for any data rights clauses other than the standard DFARS/FAR clauses, bearing in mind
- The government properly can request offerors to relinquish Limited or Restricted rights and provide Government Purpose Rights (GPR) or Unlimited rights, and may create an incentive for doing so in exchange for payment by the government – typically a paid option to deliver data and software with GPR. But it cannot require relinquishment as a condition of being responsive or eligible for award.
- Do not panic if you see a clause requesting a priced option for giving up data rights and providing GPR or Unlimited rights.
- Do not assume your competitors are going to provide those rights at no cost or low cost.
- Do get an independent, unbiased (meaning from outside the company) assessment of the value of the data rights you will be giving up. You then can fairly assess what you have to gain from winning the contract compared to what you will lose in future value for losing data rights.
- Consider (and price) strategies that provide GPR or Unlimited rights in the option or out years, or after a certain volume of production. By those times you might have recouped or significantly diminished the loss of IP value, and you might also have secured a position as a longer-term incumbent.
- Remember, the government cannot downgrade your evaluation for declining to give up Limited or Restricted rights – i.e., declining to provide GPR or Unlimited rights when you otherwise can assert Limited or Restricted rights.
- The government, however, can evaluate you more favorably if you elect to provide GPR or Unlimited rights.
- The government can require contractors to deliver DMPD as OMIT data, which an agency can reasonably define; but the DMPD must still be subject to Limited rights.
- That is, the government cannot require GPR or Unlimited rights in DMPD, or downgrade you for declining to provide those rights.
- Be mindful of timelines for raising protest issues: Challenges to the terms of an RFP must be raised prior to the time for submission of initial proposals.
- Your personnel must be attuned to this timing – and to these data rights issues – so these matters can get raised to legal and management in sufficient time to make informed decisions about how best to resist the clauses.
[1] Form, fit, and function data means technical data that describes the required overall physical, functional, and performance characteristics (along with the qualification requirements, if applicable) of an item, component, or process to the extent necessary to permit identification of physically and functionally interchangeable items. DFARS 252.227-7013(a)(11).