This is an edited and abridged version of a post that originally ran on the Anduril blog.
It would be difficult to find a more prophetic blog post in the history of technology commentary than Marc Andreessen’s 2011 “Why Software is Eating the World.” Over the past decade, software companies have driven the lion’s share of technological advancement of note and have dominated global markets. The Department of Defense (DoD) has not escaped Andreessen’s prognostication.
Indeed, it has become increasingly clear that software, not hardware, will power the pivotal military technology of the 21st century. But the defense market, being unfree at its core, has not undergone the same changes we’ve seen in the commercial space. As a result, legacy hardware providers still dominate the defense industry and capture nearly all of DoD’s major programs, and the DoD faces a host of challenges associated with the acquisition of software-defined military systems.
At the heart of this challenge is a paradox: The United States is brimming with the engineering talent required to build an arsenal of software-defined defense technologies (precision-guided, collaborative missiles) and software-enabled concepts of operation (swarms of unmanned systems, distributed air defense systems). But anachronistic acquisitions policies and practices, relics of a hardware-defined 20th century, have prevented DoD from fully tapping into this pool of human capital.
Among those anachronistic policies and practices are data rights – an arcane but crucial area of focus for the DoD as it encourages innovative companies to work on software-defined capabilities for national security. The existing data rights regime is not inherently bad: It simply is out of date. Developed in the 1980s, it continues to be tailored to a hardware-focused world. As a result, it is ill-suited to both the production of and market for advanced software development projects.
The DoD would benefit from piloting a new category of data rights for software programs. Such a proposal – outlined in greater detail below – must be designed to address both the government and industry’s frustrations with the current one-size-fits-all approach to data rights and would enhance national security by engaging the nation’s software base towards defense applications.
The status quo on data rights
When acquiring new technology, the DoD faces a greater array of considerations than typical consumers. Not only must the DoD worry about the price and the quality of the products it buys, but because it is often buying highly complex, specialized systems that fulfill national security functions, the DoD has to be especially careful of becoming overly reliant on individual companies for crucial capabilities (known as vendor lock-in) and thereby exposing itself to predatory pricing. This is an entirely understandable concern, given the DoD’s history of being bilked by major defense contractors, and its ultimate accountability to Congress and the American taxpayer.
As such, the DoD often attempts to mitigate this risk by demanding not only the rights to use new technology, but also data rights. These can include information on how to build the technology, such as “product design or maintenance data, computer databases… executable code, source code, code listings, design details,” etc. Acquisition officials can tailor custom data rights packages as they please – known as “specifically negotiated rights” – but in practice their options fall into a set of pre-baked licenses, which tend to be either too limited or too expansive to accommodate software projects.
Restricted rights
For noncommercial software that is first developed by a private party, the acquisition rules encourage (but do not require) the use of restricted rights.
Restricted rights are bizarre if seen in the context of modern software-industry practices, as they treat software like a physical widget rather than code that can be infinitely copied and decompiled at almost no cost. Specifically, the primary limitation on software provided with restricted rights is that it can only be installed on one computer. As long as the software stays on one computer, there are virtually no other restrictions on how the government can use, share, reverse engineer, or modify that software within the one-machine constraint.
It’s hard to overstate how strange this arrangement is to a modern software provider. Modern software is sometimes sold on an install basis (though it’s rare today in markets dominated by Software as a Service). However, the primary focus of almost every software license is to dictate appropriate uses of the software; to prevent reverse engineering, modification, or sharing of the core software source code; and to protect the developer’s hard work — the precise things that restricted rights do not regulate.
For these reasons, restricted rights are not commonly used for major software projects and, when they are used, they are unlikely to lead to good results for either the government or vendors.
Commercial licenses
For software that is effectively dual-use (i.e. offered both commercially and to the government without major modifications), the acquisition rules encourage (but do not require) the use of a standard commercial license.
This option is well suited to commoditized software – such as commercial word-processing or travel-booking software – but can be an awkward fit for proprietary commercial technology that needs to be adapted to defense applications. For example, suppose a vendor chooses to take an AI algorithm privately developed for computer-vision object detection and adapt it for military targeting or threat evaluation. That scenario implies a core commercial capability with material modifications to make it useful for military use.
What license terms should apply to that kind of software? This is exactly the type of question the DoD needs to answer if it hopes to leverage the latest commercial technology to fill critical gaps in our military capability. Commercial software licenses, notwithstanding their inherent flexibility, do not always provide a satisfactory answer to this question. And neither do the other standardized data rights categories discussed here.
Finally, for understandable reasons, many DoD programs see standard commercial license agreements as insufficient to their needs in acquiring these technologies. If the DoD becomes reliant upon a bespoke system with no commercial alternative to fulfill a crucial function, acquisition officials may see a heightened risk of vendor lock-in and price gouging. As such, commercial agreements are used far more rarely by the DoD for defense-focused software than their alternatives.
Unlimited rights and government purpose rights
Government purpose rights and unlimited rights agreements are the most common rights in military software solicitation and, accordingly I’ll spend the most time on them. These rights are not well suited to modern software projects. In fact, it would be difficult to come up with a data rights framework that is more likely to scare away modern software talent, software investment dollars, and software companies than government purpose rights or unlimited rights.
Government purpose rights afford the government – that is, the entire United States government, forevermore – the “rights to use, modify, reproduce, release, perform, display, or disclose technical data or computer software within the Government without restriction, to release or disclose technical data or computer software outside the Government, and to authorize persons to whom release has been made to use, modify, reproduce, perform, or display that technical data or computer software, provided that the recipient exercises such rights for Government purposes only.” (A “government purpose” is any activity where the U.S. government is a party. It is well established that the government can take software obtained with these rights from one contractor and simply give it to another contractor as part of a separate contract for similar work.)
Upon expiration of the five-year period, the government gains unlimited rights. Unlimited rights are similar to government purpose rights, but allow the government to share the software for any purpose whatsoever – including, should it choose to, sharing it with the vendor’s commercial competitors for pure commercial use.
Government purpose rights and unlimited rights come with the implicit threat that if the vendor underperforms or attempts to raise prices on their product, the government may hand the source code to another vendor to maintain, modify, and profit from. (A strange feature of data rights is that they are negotiated separately from deliverables, so that it is possible to have government purpose rights to software but no source code delivery, or vice versa. For this discussion I am assuming the government has requested source code with the rights, though there are some high-profile examples where it has failed to do so.) They also permit the government to take software provided for a specific use and a specific agency, and deploy it for a totally different use in a totally different government agency, and with a different vendor – without paying the original creator of the software any additional fees.
The problems with government purpose rights and unlimited rights
Understandably, acquisition officials use government purpose rights and unlimited rights as a blunt tool to prevent vendor lock-in and impose downward price pressure on software providers. However, these rights also have costs, encouraging gamesmanship and abuse by both vendors and the government – to the detriment of U.S. taxpayers and the American warfighter.
Vendors, for their part, can manipulate these superficially broad data rights frameworks to lock the government into their proprietary systems even when the vendor contributed relatively little to the overall solution. Government purpose rights and unlimited rights are tied directly to government funding, meaning that a vendor can work around these rights by self-funding a critical aspect of a piece of software and asserting proprietary rights to it. In a typical example, a vendor self-funds the development of a small-but-critical component of a larger government-funded system, and secures proprietary rights to that component. The vendor has effectively “locked in” the Government into its system, even though the vendor did not bear the balance of the risk and did not contribute the balance of the value in developing and fielding the larger system. The government is left with what it calls “Swiss cheese data rights” for a system it largely funded.
Just as common is the opposite scenario: The government, aware of the risk of lock-in, end-runs the “funding-focused” data rights regime and structures solicitations around expansive government purpose rights or unlimited rights from the get-go. While the government cannot legally require that a vendor provide government purpose rights to its self-funded proprietary systems, it can set up its solicitation so that vendors with proprietary systems simply fail to score well at the proposal stage of the solicitation – typically on scoring criteria such as vendor lock-in, which are then narrowly interpreted as a stand-in for the vendor’s willingness to provide government purpose or equivalent rights to the system. In doing so, the Government can effectively exclude vendors that offer proprietary solutions from ever winning such solicitations.
The problem with this approach is that, while it avoids vendor lock in, it destroys competition – which is the opposite of the desired effect. By structuring software solicitations around broad data rights agreements, the government virtually guarantees that many of the best software providers will opt out of competing for DoD contracts. With a few idiosyncratic exceptions, modern software companies will simply not work under expansive data rights agreements without a clear path to production.
The primary reason is simple economics: Modern software development is expensive. It requires fast and risky development cycles funded by internal research and development (IRAD) dollars. As a result, the software and computing industry spends a full order of magnitude more on IRAD than does the aerospace industry. Commercial software companies expect to recoup the significant sums of time and money associated with this IRAD through successful deployment of robust software across numerous customers. Profit margins for commercial software are higher than in other industries, which in turn supercharges IRAD, competition, and investment in the field of commercial software, generating a virtuous cycle that is responsible for much of the technology we take for granted today. The DoD should be aiming to recreate this virtuous cycle in its acquisitions.
To be sure, government purpose rights and unlimited rights agreements do not bother traditional defense contractors, who are used to building bespoke systems off cost-plus contracts. Traditional defense contractors are unable to compete in the commercial software market, and therefore perform very little true IRAD. They are used to having their development costs covered by U.S. taxpayers through hourly labor contracts. They are the greatest beneficiaries from the government’s insistence on expansive data rights, which effectively clear the field of competition from companies with more innovative IRAD and software deployment models.
Government purpose rights: a story in six parts
- The government solicits prototypes for a new military software capability in the field of AI (artificial intelligence). Company A comes to the table with path-making prototype software that it derived from its core commercial technology, developed at private expense, which it proposes to adapt quickly to military use.
- The Government is impressed with Company A’s proposal, and particularly its ability to deliver fast results using its existing technology. It awards Company A a $3M contract to prototype the new capability, but insists on government purpose rights to the prototype to ensure interoperability – one of the selection criteria around which it structured its RFP. This is a military capability, after all. This is communicated to the company’s sales team as a take-it-or-leave-it offer. Company A agrees, believing that there is a large market opportunity in the DoD that it can capture if it performs.
- The pilot goes swimmingly! The government loves Company A’s prototype and begins the long process of securing funding and issuing a solicitation to enter into a real production contract for the software. The government program team has gotten close to Company A’s engineers during the pilot, and together they celebrate the prospect of a long-term relationship to deliver modern technology to the DoD.
- An acquisition official outside of the program team is brought in to execute a production contract. Armed with government purpose rights to Company A’s software, the acquisition official proceeds to solicit proposals from the open market to build on Company A’s codebase. The acquisition official sees her mandate as finding the cheapest competent engineering team who will bid on the next phase of the project. The official is particularly impressed by proposals from legacy defense companies. As she tells her colleague, “Company A was an interesting partner for a pilot, but for real military work you can’t go wrong with a household name.”
- With multiple bids in hand, the acquisition official asks Company A to match the low-ball engineering rates from a legacy provider, a prospect that is unacceptable to Company A’s investors and shareholders trained in the commercial software market. Company A is forced to back out. The government program team raises concerns with cutting out Company A with the acquisition official but is overruled on legal grounds. The government cuts Company A out altogether and awards a program of record to the traditional defense contractor. The acquisition official is promoted, and transfers to a different agency.
- The large contractor takes over the program. Working on a cost-plus basis on someone else’s software, this contractor has little incentive to work quickly or productize the offering. Six years and $500M later, the program is a mess of cost-overruns and broken promises, and is canceled under pressure from congressional appropriators.
The DoD should pilot a new category of data rights for software acquisitions
Ultimately, as with software itself, modern acquisition policy needs to be fielded quickly, tested, measured, and iterated on repeatedly until it meets the intended objectives. To bring the United States’ rich base of software engineering talent to bear on our national security, the DoD should run a pilot program to test a new category of data rights designed specifically for software projects.
The DoD should run this pilot program specifically with the aim of encouraging the commercial software industry to adapt its proprietary commercial technology to field AI and autonomy for military missions. It should gauge whether the pilot is successful by measuring outcomes – costs, vendor lock-in, deployment speed, and so on – against current approaches. And it should use those outcomes to make permanent changes to the current outdated data rights regime, which the Executive Branch specifically identified as an area of concern in a recent report. (A more thorough overview of how such a pilot program might be structured is covered in the original version of this article.)
Below are five key principles such a pilot program should emphasize:
- Account for size. By default, software data rights should be commensurate to the size of the vendor’s and the government’s respective investments in the software. Vendors should retain data rights to self-funded software during early and prototyping phases of a multi-phase program. As the program transitions to larger production contracts, the government should receive greater data rights commensurate with its investment.
- Define the scope. By default, software data rights should be tailored to a specific program or use case, rather than to the entire federal government for any use. The software data rights pilot should require acquisition officials to define a specific customer and program to which the data rights will apply. By requesting a more tailored scope, DoD customers can attract a greater range of vendors to their solicitation and still obtain sufficient rights to prevent vendor lock-in for the program they are funding through the contract.
- Address technical lock-in. By default, software data rights should require adherence to technical interoperability standards such as APIs and adherence to government-defined or industry-defined open protocols. Rights to use code are insufficient to meet this need: The DoD is riddled with highly bespoke software systems owned fully by the government, which nevertheless are utterly impossible to integrate with.
- Allow vendors to propose alternative contract structures. By default, the government’s data rights requests should allow vendors to propose alternative contract, delivery, and data rights frameworks common in the software industry – including as-a-service contracts. The government should not structure solicitations to exclude these alternative structures by default.
- Weigh the costs — not just the benefits — of greater data rights. By default, the government should be required by law and policy to weigh both the benefits and the costs of various data rights frameworks and contracts structures before making an award. Modern software vendors may offer less favorable data rights at the expense of other benefits, which the government often fails to weigh in its award decisions. Specifically (and among other factors), the government should consider the impact of its preferred data rights framework on: speed to field the system; the upfront and recurring costs of the system; the value gained from continuous deployment; the risk of vendor lock-in; and the vendor’s guarantees of reliability, interoperability, and security. The government should solicit information from vendors on these tradeoffs and explicitly weigh them in making its award decision.
Ultimately, these specific principles are less important than the need for DoD to treat the acquisition process itself as an area for testing, evaluation, and experimentation. The DoD’s recent software color-of-money pilot provides an apt model for this type of exercise. As with the color-of-money pilot, the proposed data rights pilot could experiment with a variety of approaches and measure specific outcomes — costs, vendor lock-in, deployment speed, and so on — against current approaches. And it could use those outcomes to make permanent changes to the current data rights regime.
This, along with other reforms, would enable the DoD to capitalize on a new wave of software-defined companies that have shown interest in U.S. national security, and bring fresh engineering talent to the U.S. defense industrial base.
