This is an edited and abridged version of a post that originally appeared on the Anduril blog.
It would be hard to name a blog post more prophetic in the history of technology commentary than Marc Andreessen’s 2011 “Why Software is Eating the World.” Over the last decade, software companies have powered most of the technological progress worth noting and have dominated global markets in practice today. The Department of Defense (DoD) has not entirely escaped Andreessen’s forecast.
Indeed, it is becoming clearer that software, not hardware, will drive the decisive military technology of the 21st century. But the defense market, unfree at its core, has not experienced the same shifts we have seen in the commercial world in practice today. As a result, legacy hardware vendors still rule the defense industry and win nearly all of DoD’s major programs, and the DoD confronts a long list of problems tied to acquiring software-defined military systems.
At the center of this problem is a paradox: The United States has abundant engineering talent needed 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). Yet antiquated acquisition policies and practices, relics of a hardware-defined 20th century, have stopped DoD from fully drawing on this pool of human capital for military use across the force.
Among those antiquated policies and practices are data rights—an obscure but vital area of attention for the DoD as it seeks to encourage innovative companies to build software-defined capabilities for national security. The current data rights regime is not bad in itself; it is simply outdated. Created in the 1980s, it still reflects a hardware-centered world. As a result, it fits poorly with both the creation of and market for advanced software development projects under current acquisition rules and expectations today.
The DoD would benefit from piloting a new class of data rights for software programs. That proposal, described in more detail below, should be built to address both government and industry frustration with the current one-size-fits-all data-rights approach and would strengthen national security by channeling the nation’s software base into defense applications more effectively in practice going forward there.
The status quo on data rights
When acquiring new technology, the DoD faces more considerations than ordinary consumers do. Not only must the DoD think about price and product quality, but because it is often purchasing highly complex, specialized systems that serve national security functions, it has to be especially careful not to become too dependent on individual companies for essential capabilities (known as vendor lock-in) and thereby expose itself to predatory pricing. This is entirely understandable, given the DoD’s history of being cheated by major defense contractors and its ultimate accountability to Congress and the American taxpayer in procurement decisions over many years and repeated high-stakes programs alike.
As a result, the DoD often tries to reduce this risk by insisting not only on the right to use new technology, but also on 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 craft custom data-rights packages as they wish — called “specifically negotiated rights” — but in practice their choices collapse into a handful of preset licenses, which are usually either too narrow or too broad for software projects in practice.
Restricted rights
For noncommercial software first developed by a private party, the acquisition rules encourage, but do not require, the use of restricted rights in practice.
Restricted rights are odd when viewed through the lens of modern software industry practice, because they treat software like a physical widget instead of code that can be copied and decompiled endlessly at almost no cost. Specifically, the main limit on software delivered with restricted rights is that it may be installed on only one computer. So long as the software remains on one computer, there are virtually no other limits on how the government can use, share, reverse engineer, or modify that software within the one-machine rule alone there.
It is hard to overstate how strange this setup looks to a modern software provider. Contemporary software is sometimes sold by installation, though that is rare now in markets dominated by Software as a Service. But the central aim of nearly every software license is to define proper uses of the software; to block reverse engineering, modification, or sharing of the underlying source code; and to protect the developer’s hard work — precisely the things restricted rights do not govern at all.
For these reasons, restricted rights are not often used for major software projects and, when they are used, they are unlikely to produce good outcomes for either the government or vendors alike.
Commercial licenses
For software that is effectively dual-use, meaning it is offered both commercially and to the government without major modifications, the acquisition rules encourage, but do not require, use of a standard commercial license there.
This option fits well for commoditized software, such as commercial word-processing or travel-booking software, but it can be an awkward match for proprietary commercial technology that must be adapted to defense applications. For example, imagine a vendor taking an AI algorithm privately developed for computer-vision object detection and adapting it for military targeting or threat evaluation. That situation points to a core commercial capability with material changes to make it useful for military use in this defense context there.
What license terms should apply to software like that? This is exactly the question the DoD must answer if it wants to use the latest commercial technology to fill critical gaps in our military capability. Commercial software licenses, despite their flexibility, do not always give a satisfactory answer to that question. Nor do the other standardized data-rights categories discussed here as a practical matter for programs today.
Finally, for understandable reasons, many DoD programs view standard commercial license agreements as inadequate for their needs when acquiring these technologies. If the DoD becomes dependent on a bespoke system with no commercial alternative to perform a crucial function, acquisition officials may see a higher risk of vendor lock-in and price gouging. For that reason, commercial agreements are used far less often by the DoD for defense-oriented software than the alternatives there.
Unlimited rights and government purpose rights
Government purpose rights and unlimited rights agreements are the most common rights in military software solicitations 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 hard to devise a data-rights framework more likely to frighten away modern software talent, software investment dollars, and software companies than government purpose rights or unlimited rights under current acquisition practice today.
Government purpose rights give the government — meaning the entire United States government, forever — 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 in which 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 hand it to another contractor as part of a separate contract for similar work.) there
When the five-year period ends, the government receives unlimited rights. Unlimited rights are similar to government purpose rights, but they let the government share the software for any purpose at all — including, if it chooses, sharing it with the vendor’s commercial competitors for pure commercial use whatsoever there.
Government purpose rights and unlimited rights carry the implicit warning that if the vendor underperforms or tries to raise prices on its product, the government may give the source code to another vendor to maintain, modify, and profit from. (A peculiar feature of data rights is that they are negotiated separately from deliverables, so it is possible to have government purpose rights to software but no source code delivery, or the reverse. For this discussion I am assuming the government has asked for source code along with the rights, although there are some high-profile examples where it has not done so.) They also let the government take software supplied for one specific use and one specific agency, and deploy it for an entirely different use in an entirely different government agency, with a different vendor — without paying the original creator of the software any additional fees under those circumstances today.
The problems with government purpose rights and unlimited rights
It is understandable that acquisition officials rely on government purpose rights and unlimited rights as a blunt instrument to curb vendor lock-in and exert downward pressure on software prices. But these rights also carry costs, inviting gamesmanship and misuse by both vendors and the government, to the detriment of U.S. taxpayers and the American warfighter.
For their part, vendors can exploit these seemingly broad data rights regimes to trap the government inside proprietary systems even when the vendor added relatively little to the total solution. Government purpose rights and unlimited rights are tied directly to government funding, which means a vendor can evade them by self-funding a critical portion of a software product and claiming proprietary rights over it. In a typical case, a vendor self-funds development of a small but essential element of a larger government-funded system and obtains proprietary rights in that element. The vendor has, in effect, “locked in” the Government to its system, even though the vendor did not shoulder the rest of the risk and did not provide the rest 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 mostly paid for.
Just as often, the reverse happens: The government, mindful of the risk of lock-in, works around the “funding-focused” data rights structure and drafts solicitations around sweeping government purpose rights or unlimited rights from the outset. Although the government cannot legally compel a vendor to grant government purpose rights to its self-funded proprietary systems, it can frame its solicitation so that vendors with proprietary systems simply do not score well at the proposal stage of the solicitation – usually on criteria such as vendor lock-in, which are then narrowly read as a proxy for the vendor’s willingness to provide government purpose or equivalent rights to the system. In this way, the Government can effectively bar vendors offering proprietary solutions from ever prevailing in such solicitations.
The trouble with this method is that, although it sidesteps vendor lock in, it undermines competition – the opposite of the intended result. By organizing software solicitations around broad data rights deals, the government all but ensures that many of the strongest software providers will decide not to pursue DoD contracts. With a few unusual exceptions, modern software companies simply will not operate under expansive data rights arrangements without a clear route to production.
The main reason is basic economics: Modern software development is costly. It depends on rapid and risky development cycles financed by internal research and development (IRAD) dollars. Consequently, the software and computing industry spends a full order of magnitude more on IRAD than the aerospace industry does. Commercial software companies expect to recover the substantial amounts of time and money tied to this IRAD through successful deployment of strong software across many customers. Profit margins in commercial software are higher than in other industries, which in turn amplifies IRAD, competition, and investment in the commercial software sector, creating a virtuous cycle behind much of the technology we now take for granted. The DoD should be trying to reproduce this virtuous cycle in its acquisitions.
To be sure, government purpose rights and unlimited rights agreements do not trouble traditional defense contractors, who are accustomed to building bespoke systems under cost-plus contracts. Traditional defense contractors cannot compete in the commercial software market, and therefore conduct very little genuine IRAD. They are used to having their development costs paid by U.S. taxpayers through hourly labor contracts. They benefit most from the government’s insistence on expansive data rights, which effectively remove competition from companies with more innovative IRAD and software deployment models.
Government purpose rights: a story in six parts
- The government seeks prototypes for a new military software capability in the field of AI (artificial intelligence). Company A arrives with a path-making prototype software product derived from its core commercial technology, built at private expense, which it proposes to adapt quickly for military use. The Government is impressed by Company A’s proposal, especially its ability to deliver quickly using 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. The company’s sales team receives this as a take-it-or-leave-it offer. Company A agrees, believing there is a substantial market opportunity in the DoD that it can win if it performs. The pilot goes very well! The government is delighted with Company A’s prototype and starts the lengthy process of securing funding and issuing a solicitation to enter into a real production contract for the software. The government program team has grown close to Company A’s engineers during the pilot, and together they celebrate the chance for a long-term relationship to deliver modern technology to the DoD. An acquisition official outside the program team is brought in to award a production contract. Equipped with government purpose rights to Company A’s software, the acquisition official begins soliciting proposals from the open market to build on Company A’s codebase. The acquisition official sees her job as finding the cheapest capable engineering team willing to bid on the next phase of the project. She is especially 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 several bids in hand, the acquisition official asks Company A to match the low-ball engineering rates of 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 withdraw. The government program team objects to cutting out Company A with the acquisition official but is overruled on legal grounds. The government cuts Company A out entirely and awards a program of record to the traditional defense contractor. The acquisition official is promoted and moves to another 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 move quickly or turn the offering into a product. Six years and $500M later, the program is a disaster 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
In the end, as with software itself, modern acquisition policy needs to be deployed quickly, tested, measured, and revised repeatedly until it achieves the intended goals. To harness the United States’ deep pool of software engineering talent for our national security, the DoD should launch a pilot program to test a new category of data rights created specifically for software projects.
The DoD should conduct this pilot program specifically to encourage the commercial software industry to adapt its proprietary commercial technology to deliver AI and autonomy for military missions. It should determine whether the pilot succeeds by measuring outcomes – costs, vendor lock-in, deployment speed, and so on – against current approaches. And it should use those outcomes to make lasting 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 match the size of the vendor’s and the government’s respective investments in the software. Vendors should keep data rights to self-funded software during the early and prototyping stages of a multi-phase program. As the program shifts to larger production contracts, the government should receive broader data rights in line 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 identify a specific customer and program to which the data rights will apply. By asking for a narrower scope, DoD customers can draw a wider range of vendors to their solicitation and still secure enough 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 compliance with technical interoperability standards such as APIs and with government-defined or industry-defined open protocols. Rights to use code are not enough to solve this problem: The DoD is filled with highly bespoke software systems fully owned by the government, which nonetheless are completely impossible to integrate with. Allow vendors to propose alternative contract structures. By default, the government’s data rights requests should permit vendors to offer alternative contract, delivery, and data rights frameworks common in the software industry – including as-a-service contracts. The government should not draft solicitations to bar 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 consider both the benefits and the costs of various data rights frameworks and contract structures before making an award. Modern software vendors may offer less favorable data rights in exchange for other benefits, which the government often neglects to consider in its award decisions. Specifically (and among other factors), the government should examine 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 seek information from vendors on these tradeoffs and explicitly weigh them in making its award decision.
In the end, these particular principles matter less than the need for DoD to treat the acquisition process itself as a place for testing, evaluation, and experimentation. The DoD’s recent software color-of-money pilot offers a fitting model for this kind of effort. As with the color-of-money pilot, the proposed data rights pilot could test a range 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 lasting changes to the current data rights regime.
This, together with other reforms, would let the DoD take advantage of a new wave of software-defined companies that have expressed interest in U.S. national security, and bring new engineering talent to the U.S. defense industrial base.