United States: The Government Contractor: Unrecognized And Overt Pressure On Contractors' Data And Software Rights: Risks Posed By H Clauses, Innocuous Acronyms (IPT, IDE, SaaS, DAL), And The Cloud

FEATURE COMMENT: Unrecognized And Overt Pressure On Contractors' Data And Software Rights: The Risks Posed By H Clauses, Innocuous Acronyms (IPT, IDE, SaaS, DAL), And The Cloud

During the past several years, industry has seen various legislative and regulatory pushes by the Department of Defense (DOD) to acquire more and broader rights in technical data and all forms of computer software. Some of this will come to fruition soon in the form of long-awaited revisions to the Defense Federal Acquisition Regulation Supplement data rights clauses. These likely will include requirements for (1) contracting officers (COs) to identify the estimated costs to acquire data and software rights and to summarize how the CO intends to negotiate a price for them; (2) offerors to provide estimates of prices for data, software, or other license rights, which the CO will negotiate based upon "appropriate valuation practices and standards"; (3) COs to negotiate special license rights "early in the life cycle, when competition is more likely"; and (4) applying noncommercial software concepts to commercial computer software.

This emphasis on sorting out the anticipated costs and prices for data and software will inevitably lead to internal pressure within contractors to low-ball their proposed prices for intellectual property (IP) rights—assuming management even knows what the value of the IP is—or to give them up entirely: "This is a must-win competition. Bid low or we will lose." And so on.

But we do not have to await the effects of those pending developments, because subtle (or unrecognized) risks already exist and are increasing, in the familiar form of routine collaboration with DOD—i.e.:

• Integrated Product Teams (IPTs),
• Integrated Data Environments (IDEs),
• the Cloud,
• Software as a Service (SaaS), and
• Data Accession Lists (DALs).

Increasingly, there also are more aggressive and burdensome "H" clauses from contracting activities. So, let us explore these existing phenomena and consider how better to deal with them. First, some generally accepted definitions:

Data Accession List:

What These Have in Common and Their Risks—Although each of these things is different in nature and function, they all have in common at least two important circumstances from a data rights perspective. The first is access. That is, IPTs, IDEs, or a Government Cloud environment may well establish access (electronically or otherwise) to in-process technical data or computer software that may not be deliverables under the contract or may not be marked with the legends of the data rights clauses, or both. (DALs are somewhat different, so we will look into them a bit later.)

This is driven by the second circumstance—lack of knowledge. The employees who set up these data exchanges and who handle data and software typically are the least likely to know or care about data rights and contract clauses. IPTs, IDEs, and Cloud environments are not staffed and operated by attorneys or contract personnel but rather by engineers, technologists, and program staff. In turn, they will happily (and often obliviously) set up intranets or otherwise arrange for sharing in-process data or software developments with their Government counterparts. And their Government counterparts will happily accept them.

Unless someone knowledgeable is overseeing the process, however, this means the data or software may have been transferred or be available without limited or restricted rights legends or any other legend such as a copyright or "proprietary" marking. This also means the Government might assert that the data or software had been delivered to it, and delivered without any of the prescribed legends, resulting in the Government's obtaining unlimited rights. The clauses make this point: "The Government shall have unlimited rights in— ... (iv) Computer software or computer software documentation that ... has been released or disclosed by the Contractor or subcontractor without restriction." DFARS 252.227-7014(b)(1)(iv). Accord 252.227-7013(b)(1)(vii) (for technical data). "[T]he Government shall have unlimited rights in— ... (iv) All other data delivered under this contract unless provided otherwise for limited rights data or restricted computer software." FAR 52.227-14(b)(1)(iv).

What to Do?—The first thing to do is to educate key personnel about data rights. Whether you are a contractor or an agency, it is good business and smart to train your lead engineers, technologists, and program personnel about the fundamental aspects of the data rights clauses, what they do (only license rights) and do not do (provide ownership or delivery). You might point this out from the regulations, such as DFARS 227.7103-4, "License Rights":

1. Grant of license. The Government obtains rights in technical data, including a copyright license, under an irrevocable license granted or obtained for the Government by the contractor. The contractor or licensor retains all rights in the data not granted to the Government.

Or from FAR 27.403:

Or from insightful materials from well-informed commentators, such as DeVecchio, "Taking The Mystery Out Of Data Rights," 18-8 Briefing Papers 1 (July 2018).

After training, the next step is for contracts—including COs—or legal to establish clearly whether access by the customer constitutes delivery under the data rights clauses. This is appropriate because more often than not contract clauses pertaining to IPTs, IDEs, SaaS, or Cloud environments do not specifically address delivery or delivery rights. If they do not, or if there is ambiguity, contractors should propose or negotiate a delivery disclaimer. Here is an example:

Certainly, if there is delivery, however defined, both sides must agree on a clear process for the data and software to be marked correctly in accordance with the data rights clauses. Each data rights clause (FAR and DFARS) has its own unique legends for limited rights (technical data) and for restricted rights (software). There is no commercial software legend. There also are legends for Government purpose and specially negotiated rights under the DFARS, as well as the ability to mark with a copyright legend, although the FAR and DFARS procedures for copyright markings are different. Lastly, under the Federal Circuit's 2020 Boeing decision, a contractor may attach a company proprietary legend at least in conjunction with limited or restricted rights. See Boeing Co. v. Sec'y of the Air Force, 983 F.3d 1321 (Fed. Cir. 2020); 63 GC ¶ 8.

Marking in the Digital Age—When dinosaurs roamed the earth, drawings, blueprints, processes, and software flowcharts were on paper. The paper copies typically were marked with the correct limited or restricted rights legend. When digital arrived, these paper documents were "imaged," and thus the markings were on the electronic version. Now, however, technical data and software are created electronically in the first instance. How do these get marked at DOD in light of -7013(f)(1) or its software counterpart -7014(f)(1)?

DFARS 252.227-7013(f)(1). Contractors therefore must ensure the correct FAR/DFARS software markings are included electronically (e.g., boot screen, splash screen), as well as a copyright and proprietary legend as applicable.

There is a related concern with respect to SaaS. If proprietary technical data will be generated by the software and delivered under the contract, there is a reasonable probability the Government will assert unlimited rights in the data per FAR 52.227- 14(b)(1)(i) or DFARS 252.227-7013(a)(1)(iii). This means contractors and the Government need to consider the implications of this in advance of contracting; and if there is any question about it, they should consider a specifically negotiated license and associated markings to clarify the parties' rights. See DFARS 252.227-7013(b)(4); -7014(b)(4).

Reminder About the Data Accession List— Similarly, delivery issues are posed by apparently increasing requirements to provide a Data Accession List. Equally increasingly, agencies take the position that a DAL requires a contractor to deliver the technical data identified on the DAL. This usually is incorrect.

Let's back up to a fundamental point about delivery, and then go forward to the DAL. Fundamental point: None of the basic data rights clauses requires a contractor to deliver the technical data or computer software described by the clauses. As noted above, typically a DAL also "is not a requirement to deliver the data listed. The Government can use the list to order data from the list as cited in the contract."

Accordingly, if you are in performance, do not assume that the DAL creates a delivery right in the Government. Read (or, if you are the Government, write) the DAL clause in a request for proposals carefully to be sure it does or does not expressly include any delivery requirement. If it does, contractors should question it during the Q&A phase, challenging the language. Specifically, state in your Question that you understand the DAL does not supersede the CDRL nor override any delivery requirements of the contract or the data rights provisions.

And, just as with IPTs, IDEs, and the Cloud, educate your engineers, technologists, and program personnel that if the Government does ask for delivery of data or software, it only can be provided through the proper channels (e.g., contracts), confirmed by legal, and it must be correctly marked with a restrictive legend.

H Clause Developments—Another trend these days is contracting activities using more aggressive and burdensome "Section H" clauses. There are variations, but generally the ones posing the most practical difficulties for contractors are those that (1) tend to blur distinctions between what is deliverable vs. rights regarding Operation, Maintenance, Installation, & Training (OMIT) data; (2) seek unlimited rights in "use cases"; (3) define data rights by deliverables; and (4) require com-mercial software vendors (at all tiers) to agree to unique modifications of their license agreements.

The OMIT Clause—This variation requires delivery of all "OMIT Data" and defines the term to include detailed manufacturing or process data (DMPD) and computer software. By statute and regulation, however, those are not OMIT data for data rights purposes. So, one must read the clause closely to see whether it goes beyond delivery and transgresses into data rights.

Here is an example of one such clause: OMIT Data is defined for the purposes of this contract as all technical data, computer software, computer software documentation, computer data bases and graphics pertaining to [the subject of the acquisition] required to successfully conduct all operation, maintenance, installation, and training activities, regardless of whether such activities are performed by military, civilian, or contract personnel. "Operation" includes all procedures, guidance, and instructions for ground and inflight operating, handling, testing, emergency, utilization, familiarization, and functional use of the Aircraft .... Operation also includes all data to identify, catalog, stock, source, acquire, procure, replenish, package, handle, store, and transport of the ... aircraft system and [its] subsystems, assemblies, subassemblies, components, parts, and pieces. [Emphases added.]

reasonably could be read to cover source code as well as detailed manufacturing data. If this clause is only defining OMIT data for delivery and is not prescribing data rights in these OMIT data, the clause arguably is acceptable. An agency reasonably can identify those things it perceives as necessary OMIT items.

But if the clause requires unlimited data rights in OMIT data that the agency has defined to include computer software or DMPD, then the clause is illegal and should be challenged. Under 10 USCA § 3771(b)(3)(C) and its predecessor, Congress permitted DOD to obtain unlimited rights in OMIT data only with respect to technical data—not software—and to exclude from OMIT data "detailed manufacturing or process data." Thus, DFARS 252.227-7013(b)(1)(v) replicates § 3771, and there are no corresponding OMIT rights in the software clause, 252.227-7014.

The Use Case Variation—In this H clause, offerors are required to identify Government rights by subsystem/subassembly, with "Unlimited" rights assumed if no restriction is asserted in the proposal. This means, of course, that contractors and subcontractors must assiduously understand and assert their limited, restricted, specially negotiated, and Government purpose rights (GPR) at the lowest component level.

The solicitation also provides a list of "use cases," including those the Government asserts should be delivered with unlimited rights. And, if the offeror thinks a specific "use case" will require detailed manufacturing or process data, it must propose a price to grant GPR or a specifically negotiated license in such data to allow other contractors to perform the use case (essentially a limited GPR license).

Recall that 10 USCA § 3771(b)(8) prohibits DOD from requiring contractors, as a condition for being responsive to an RFP or for award, to "sell or otherwise relinquish to the United States any rights in technical data" the contractor is entitled properly to assert. Therefore, if you disagree with the solicitation's assertion of unlimited rights in a particular use case, you should expressly disagree with it in your proposal or the Q&A process and state the reasons why it is incorrect.

The Government can, however, ask you for a priced option to relinquish your data rights via GPR or a specifically negotiated license. Even if the Government cannot require you to name a price for your rights, there will be intense competitive pressures to do so, both internally and expressly in the solicitation's evaluation criteria. This means contractors should carefully consider the competitive consequences of giving up rights as well as the long-term dollar value loss of those rights.

Limited and restricted rights lawfully and fairly place the contractor in a sole-source position regarding those data and software, because they represent a contractor's trade secrets, developed with the contractor's talent, time, initiative, and private expense. In turn, this necessarily begs the question of what the contractor has done to value its rights in this valuable data and software. Yet, this is an area in which companies tend not to focus sufficiently or, if they do, tend to undervalue the intellectual property for the short-term goal of winning a contract. Industry should devote greater attention to valuation. DOD is. It increasingly will endeavor to figure out and place a negotiation value on contractors' data rights. This strongly suggests contractors should be doing the same.

The Multiple-Choice Commercial Software Clause—This H clause is one of the most burdensome for prime contractors, because it requires primes to negotiate difficult or unrealistic agreements with all of the prime's commercial software suppliers but that many suppliers will not even consider. Viewed another way, this type of clause is a burden-shifting provision, forcing the prime to do what should be the Government's work of reviewing and negotiating commercial software licenses, and doing this in the crucible of competitive procurements. It reflects the curious phenomenon of DOD claiming it embraces commercial software yet using clauses that dissuade or preclude commercial software vendors from doing business with DOD.

This clause offers three alternatives for a prime's and its vendors' commercial computer software licenses. One of the three must be met for any licenses that will be passed along to the Government:

Alt 1: Requires each supplier's End User License Agreement to be modified to comply with several conditions (sometimes dozens) supposedly necessary to avoid conflict with federal law and to meet specific Government needs.

This goes beyond the typical (and legitimate) Anti-deficiency Act or Contract Disputes Act concerns, but rather into specific program needs, e.g.: "The software license(s) shall not include any provisions that are inconsistent with 'Requirements' defined in any contract awarded as a result of this solicitation." Good luck: many commercial suppliers simply will not do this.

Alt 2: Requires a general statement that provisions inconsistent with federal procurement law, the contract, or DFARS 227.7202 ("Commercial computer software and commercial computer software documentation") are deemed null and void, while remaining terms remain in full force. A limited subset of the requirements in Alt 1 also must be met. The ambiguity in this language tends to make it more palatable to some suppliers.

Alt 3: The prime must obtain the licensor's consent to sever usage rights from the license and assign those rights to the Government "so as to permit the Government to operate any related software or system containing the software," while all other rights and obligations in the license remain with the contractor.

Really? Translated, this means the prime contractor remains the licensee for all purposes including liability and only assigns or otherwise transfers usage rights portions to the Government. In other words, the contractor is left holding the bag for any governmental misuse of or negligence regarding the suppliers' software. As odious as this is, Alternative 3 often is the only remaining viable alternative for a prime who needs a particular commercial software vendor that will not agree to Alternatives 1 and 2.

Conclusion—Contractors understandably focus attention on pending regulations and legislation affecting Government procurement. This is prudent; it is good business to anticipate or predict what may be coming and to consider how to prepare for it. There is, however, a range of ongoing activities within contractors as well a range of existing contract H clauses that warrant equal or greater attention by industry. Those activities and clauses do not require predictions or anticipation of their consequences. They pose current risks and practical difficulties here and now.

Because of the generality of this update, the information provided herein may not be applicable in all situations and should not be acted upon without specific legal advice based on particular situations.

© Morrison & Foerster LLP. All rights reserved