The GAO’s decision last week, denying in part and dismissing in part Sikorsky Aircraft Corporation’s much-watched protest of the Air Force’s solicitation to replace the UH-1N helicopter, deals an early (if light) blow to contractors in their fight against the Air Force’s recent data rights grab. Followers of this blog and readers of the Government Contractor will recall we raised concerns in January about overbroad data rights provisions in recent Air Force solicitations. The GAO, in Sikorsky Aircraft Corp., B-416027; B-416027.2, May 22, 2018, ultimately endorsed one such provision requiring broad delivery of both technical data and software necessary for operations, maintenance, installation, and training activities (defined in the solicitation as “OMIT Data”), but Sikorsky’s protest did not go down without first getting an important concession from the Air Force. This concession, and the GAO’s discussion of whether OMIT Data includes source code, are the key takeaways from Sikorsky, and we will discuss them in some length here. Before we do, some stage-setting is appropriate, in particular because the clauses at issue are confusing.
For more than 20 years, contractors and government personnel have used “OMIT data” as a familiar shorthand for the data called out in DFARS 252.227-7013(b)(1)(v) as “Necessary for installation, operation, maintenance, or training purposes (other than detailed manufacturing or process data),” and, importantly, in which the Government is entitled to unlimited rights. In this parlance, OMIT data by definition include neither “detailed manufacturing or process data” (DMPD) nor computer software. Unsurprisingly, the Air Force caused some consternation recently when it bucked this convention and began including in its solicitations for major weapons systems a provision defining “OMIT Data” to include all types of computer software and, in some cases, DMPD. (We distinguish this OMIT Data, specially defined by the Air Force, and the colloquial OMIT data.) Sikorsky was the first to file a formal challenge.
As reflected in the GAO’s decision, the Air Force gets away with its definition by relying on a distinction between the Government’s right to order delivery of technical data and software – which is not covered by the data rights clauses, but rather is determined by the unique and independent delivery requirements of each solicitation or contract, unbound by regulation – and the Government’s right to use technical data and software, which is addressed at length in the DFARS data rights clauses. In other words, the data rights clauses articulate license rights of use, but not delivery requirements. Delivery requirements are covered elsewhere in contracts. Thus, if the Air Force defines OMIT Data broadly but requires only its delivery, there is no formal conflict with the data rights regulations; a conflict would occur if the Air Force demanded unlimited rights in DMPD or in computer software, as distinguished from demanding their delivery subject to the correct rights provided in the data rights clauses. Such a demand would violate DFARS 227.7103-1(c) and 10 U.S.C. § 2320(a)(2)(H). That said, one hardly can blame a seasoned contractor for assuming that an H clause requiring delivery of DMPD or software as OMIT data also correspondingly requires unlimited rights in them, particularly given the fact that “OMIT data” is synonymous with a subset of Unlimited Rights Data.
Indeed, the Air Force’s clauses as originally drafted did not address only the scope of delivery, but also required broad rights in OMIT Data – bringing us to the Air Force’s key concession. Before Sikorsky filed its protest, the OMIT Data clause in the UH-1N replacement contract (and similar clauses in other Air Force procurements) were at best ambiguous (and questionably legal) regarding whether they required offerors to relinquish government purpose rights or even unlimited rights in OMIT Data that were DMPD or noncommercial computer software developed at private expense – two categories in which contractors by regulation may assert limited or restricted rights. But after Sikorsky correctly challenged this aspect of the solicitation, the Air Force sent a letter to all offerors clarifying that its provision did not require contractors to give up more than limited or restricted rights in these specific types of OMIT Data, leaving Sikorsky’s protest on this ground academic.
Nonetheless, this concession is, as a practical matter, a significant victory for contractors. One should fairly assume the Air Force will not in the future be promulgating these H clauses in a way that suggests relinquishing limited or restricted rights if they are properly asserted.
With this key portion of Sikorsky’s protest knocked out, the GAO marched through the remaining grounds, dismissing one as an untimely challenge to the terms of the solicitation and dismissing another two as premature challenges to the agency’s evaluation, leaving only two grounds surviving to a decision on their merits. One, examining whether the solicitation distinguished OMIT Data at the CDRL or data item level (the GAO found the latter), is of little interest outside the UH-1N replacement solicitation. The other, however, warrants discussion.
As noted above, industry long has used “OMIT data” to refer to a subset of Unlimited Rights Data that necessarily excludes DMPD. Sikorsky argued that it reasonably read this exclusion into the Air Force’s definition of OMIT Data, in particular given the solicitation’s qualification that OMIT Data “includes technical data and software used in the installation and deinstallation, and disassembly and reassembly, at the lowest practicable segregable level that does not require detailed manufacturing or process data.” Sikorsky also argued this exclusion extended by analogy to source code. The GAO disagreed with Sikorsky on both.
The GAO first pointed to the distinction between the delivery requirements and use rights and reasoned that, because the regulations address only use rights (e.g., unlimited rights), excluding DMPD from the grant of unlimited rights in DFARS 252.227-7013(b)(1)(v) does not affect the Government’s right to order delivery of DMPD. Thus, when the Air Force defines OMIT Data as a category for delivery, it is not required by the data rights clauses to exclude DMPD. And even though the Air Force in fact did exclude DMPD related to installation and deinstallation, and disassembly and reassembly, the GAO noted it did not also do so for other OMIT activities, e.g., other maintenance or training and operations. Accordingly, the GAO found DMPD was not categorically excluded from delivery as OMIT Data.
The GAO also found that source code was not excluded, through a rather straightforward syllogism, although one with unexpected consequences: the solicitation requires delivery of OMIT Data, which it defines to include “computer software.” In turn, computer software is defined by regulation to include source code. Ergo, the solicitation’s OMIT Data includes source code. Once again, the GAO depends on the point that the delimitation of OMIT data in DFARS 252.227-7013(b)(1)(v) is irrelevant for the purposes of delivery. And the GAO noted that even if it were not so, this DFARS provision would not apply to computer software, as it applies exclusively to noncommercial technical data. According to the GAO, just because the Air Force decided to lump computer software into its definition of OMIT Data, it did not “treat computer software as though it were technical data.” Thus, even where the solicitation excluded delivery of DMPD for installation or assembly activities, that exclusion did not extend to source code because DMPD, as defined in regulation, is limited to technical data.
A careful reader might point out that it seems at least somewhat disingenuous for the GAO to discard so quickly the language of DFARS 252.227-7013(b)(1)(v) as applicable only to use rights, but then to rely on the definition of DMPD in that same regulation to dismiss Sikorsky’s understanding that the solicitation did not require delivery of source code. One may criticize the GAO’s method as unfairly formalistic: the result hinges on the solicitation’s expressly incorporating definitions from DFARS 252.227-7013, which defines “detailed manufacturing or process data” but not “OMIT data.” To be sure, this formal interpretation is reasonable, but is Sikorsky’s interpretation not also reasonable, at least enough to expose an ambiguity in the solicitation as to whether delivery of source code is required? According to the GAO, it is not.
We expect to see a surge in bid protests involving data rights issues, as the Department of Defense (and other agencies), at the direction of Congress, seeks greater rights in data to effect Open Systems Architecture or Approach and pushes the fight over the scope of delivery of and rights in technical data and software to the left in the timeline of the procurement process. The GAO, therefore, likely will become an increasingly important voice interpreting data rights regulations and clauses, a role it has played in past decades but from which it has been relatively absent for some time. Sikorsky indicates the GAO’s willingness to step into this role with strong, if unforgiving, respect for the formalism of the long-standing DFARS provisions.