COMMENTARY | GSA’s new AI clause targets vendor lock-in, but enforcement remains a challenge. #
The General Services Administration spent a number of months this year drafting a new clause to use in its contracts for the purchasing of Artificial Intelligence (AI). The original draft started too broadly, with the June version seemingly preventing ordinary services contractors from using AI tools in their work supporting the government without flowing down implausible contract clauses to their AI suppliers. No casual user with a monthly subscription can get a behemoth like OpenAI or Anthropic to change its standard usage policies. Even the Department of War has had difficulty persuading Anthropic to modify its restrictions on how AI may be deployed.
Fortunately, the newly implemented GSA clause solved the ordinary contractor usage problem by making it not applicable for them.
Conversely, the flow-down burden on the suppliers of AI puts a spotlight on the problem of flow-downs in general and on vendor locking policies specifically. As a legal instrument flow-downs can be flimsy. The concept is that the government imposes certain requirements on the prime contractor to flow down government-identified clauses to its subcontractors or suppliers. This mechanism has been in place forever, but its efficacy is sometimes dubious.
It is one thing for the prime to ask its subcontractors to do things that are easy to accommodate and indeed things they already do: not hire illegal immigrants, for instance. It is quite another to ask it to do something directly antithetical to their business model.
Here is where the contractual linkage breaks, especially for policies that IT companies intentionally build for customer retention and anti-competitive purposes. Indeed, GSA’s new AI clause excuses contractors, in one subsection, when a problem is “driven by a third-party commercial provider... the contractor does not control.” GSA is therefore conceding in at least one place that a government contractor cannot command a commercial supplier it has no power over.
My specific concern is portability, interoperability and the issue of vendor locking terms and conditions. The flow-downs that GSA is asking its contractors to impose on LLM companies in that respect are reasonably worded. The section tells the contractor to support open export formats and to avoid terms that would impair migration. Good. This is how vendor-locking restrictions could be defeated. The problem is the mechanism to get the LLM companies to adhere to them. Remember, the government typically buys IT through a system integrator or a reseller. Under that scenario the government has no contractual standing or privity with the supplier, meaning it cannot sue the supplier for breach.
In 2024, I wrote about a federal dispute over whether a software company’s license passed through a reseller’s contract creates any enforceable relationship between the software company and the government. The question runs in both directions. If the company cannot hold the government to the license for lack of privity, as we saw in the 2024 case, the government may be equally unable to hold the company to its licensed obligations.
This still appears to be an area where the law is not firm. That is not useful footing when an LLM or SaaS company holds data hostage and won’t let users easily leave for a competitor. The government can try to press its right against the reseller, who might not be able to deliver it, or against the licensor, who may have no contract with the government at all. Even where the license is enforceable, it likely runs against the government’s interest. The vendor wrote it to restrict the very portability the flow-down hoped to secure. That collision over perceived rights is why there would be a standoff in the first place.
Lock-in policies are cleverly designed. Sometimes they are presented as necessary for cybersecurity or functional integrity, but even where there is some legitimate overlap, the essential goal is retention. The lock can take different forms. Since 2019, Microsoft’s licensing terms have penalized running software you already own on competing clouds, effectively forcing you to re-license to leave its Azure cloud. This is no accident. It is an intentional business policy. Users have complained about it to no avail, and it is simply not getting negotiated out of a contract by a reseller or even the federal government.
In April, SAP published an API policy restricting which AI engines may touch their hosted SAP data making that data inaccessible to some competitive vendors — a licensing penalty in one case and an access restriction in the other. In each case the lock is set by the supplier, as global policy, identical for every customer, and not generally negotiable by any prime contractor.
AI will already be hard enough to replace without contractual impediments, because of what I have previously called cognitive and emotional incumbency: the way users and organizations grow dependent on a tool once it has learned their work, their people, and their habits. These will be among the stickiest products ever deployed, hard to abandon even when nothing in a contract forbids leaving. That natural stickiness already weakens a buyer’s leverage at renewal. Layer a contractual impossibility of switching to a competitor on top of it and price competition disappears entirely as lock-in calcifies.
These licensing restrictions burden every cloud customer, not just federal agencies. If the Federal Trade Commission moved against anti-competitive behavior market-wide, the government would not need its own approach. But that is a slower and more political path, and government buyers shouldn’t wait. There is one place the government already deals with the supplier directly, without holding a contract: FedRAMP, where cloud and platform providers seek authorization on their own, as a condition of selling to government.
Here’s the thought. Add a competitive-neutrality standard to the normal cybersecurity authorization in FedRAMP. Not a mandate but an optional certification added to the checklist of cybersecurity controls.
A provider could attest to the language of GSA’s interoperability clause, or some other properly crafted language, that includes no license terms that trap software on one cloud, no exit tolls that make leaving uneconomic, and no access rules that bar a competing engine from the customer’s own data. Providers who certify would be affirmatively agreeing to competitive neutrality. Government buyers will then have visibility for the first time, with restrictions no longer hidden in opaque license agreements. Vendors who decline are not punished. They are simply visible for their lack of compliance. Industry cannot object to an optional certification.
The effect may create a race to the top rather than to the bottom. Once portability and interoperability are visible prior to purchase, they may become something providers compete to offer.
FedRAMP has one advantage nothing else offers: its authorization is pursued by the software maker itself, not the reseller that sells it. It is the one place the government deals directly with the OEM without a contract. Some will object that a competitive-neutrality attestation does not belong in a security program built for the NIST controls. I understand. The lack of precise fit is an unfortunate reality. But it need not be terminal.
Because the certification would be optional, it takes nothing away from FedRAMP’s security purpose, and it would cost the provider almost nothing to implement. It is only a voluntary box an OEM can check or ignore. At the very least, it would surface those that commit to competitive neutrality and those that decline.
Michael Garland is the founder of Garland, LLC, a consulting firm that advises industry and government clients on issues related to federal procurement law and the business of IT.