Waymo-Uber termination exposes gaps in AV partnership contracts
The May 2026 end of Waymo's Phoenix robotaxi partnership with Uber highlights unresolved contractual questions about IP division, fleet disposition, and post-termination competition — and provides a blueprint for what every autonomous-vehicle partnership agreement should explicitly address.
- Jurisdiction
- US Federal
- Court
- United States District Court
- AI tool named
- Waymo autonomous driving system
- Ruling date
- May 1, 2026
- Source document
- View primary court order ↗
- Last verified
- Jul 25, 2026
Lex Machina Review is an independent risk-tracking and reference resource. Nothing on this site is legal advice, and using it does not create an attorney-client relationship. Every record is reviewed against primary sources but may not reflect the most current status of a matter — always verify directly against the cited court order, rule text, or a licensed attorney before relying on it.
Companion explanation — secondary to the source document above
The quietest phrase in the Waymo-Uber split is also the one that does the most work: the Phoenix robotaxi partnership ended at a “contracted end date.” Reuters reported that the companies ended the Phoenix arrangement in May 2026, with Waymo taking the robotaxi fleet back into its own app and redirecting some vehicles into a DoorDash delivery deal.[1] TechCrunch reported the same day that the Phoenix pilot had launched in 2023, involved roughly 12 vehicles, and that Uber was preparing to announce another autonomous-vehicle partner for Phoenix, though that partner had not been named.[2]
That is the public sequence. It sounds tidy: a pilot reaches its term, the cars go somewhere else, the platform looks for a new supplier. But the legal implications for autonomous driving do not turn on whether the breakup was dramatic. They turn on what the contract said would happen when the pilot stopped being useful.

A contracted end date can be perfectly ordinary. It can also be where the hard questions disappear from public view: who owns the vehicles, who can use the trip data, what happens to support playbooks, whether routing or demand information remains usable, and how far a platform can go in onboarding the next AV company without reusing what it learned from the last one.
The public exit facts are clean; the allocation rules are not
The visible facts favor a planned termination rather than a failed scramble. Waymo did not leave the Phoenix vehicles stranded in a contractual dead zone. It moved the robotaxi fleet into its own Waymo One service and pointed some vehicles toward delivery work with DoorDash.[1] Uber, for its part, was not merely reacting to a partner’s departure; TechCrunch reported that it was readying another Phoenix AV relationship.[2]
Those facts tell us something important, but not everything. Waymo’s reabsorption of the fleet strongly suggests that the vehicles and the core autonomous-driving stack remained under Waymo’s control during the Phoenix deployment. It does not disclose the terms under which Uber received access to the fleet, the app integration, rider workflows, support procedures, or operational reporting. It also does not disclose what each side had to delete, return, quarantine, or stop using once the service moved out of Uber’s consumer-facing environment.
That distinction matters in AV contracts because the vehicle is not just an asset. It is a bundle of embedded software, sensors, maps, logs, maintenance procedures, remote-assistance protocols, escalation channels, safety constraints, and customer-facing service rules. A fleet can be physically returned while the more litigable residue stays behind in systems, emails, dashboards, product specifications, and employee memory.
| Publicly visible after termination | Still opaque from public materials |
|---|---|
| Waymo pulled the Phoenix robotaxi fleet back into its own app. | Whether Uber retained any operational data, analytics, incident reports, integration learnings, or support-process documentation. |
| Some vehicles were redirected to DoorDash delivery work. | Whether the partnership agreement treated redeployment as Waymo’s unilateral right, a post-term permitted use, or something already outside Uber’s rights. |
| Uber was preparing another Phoenix AV partner. | Whether the agreement imposed transition limits, partner-substitution restrictions, cooling-off periods, audit rights, or no-use obligations beyond the 2018 settlement. |
| The arrangement ended at a contracted term. | Whether termination triggered deletion duties, data-return duties, IP-license expiration, residual-knowledge carveouts, or customer-transition rules. |
Fleet disposition is the first clue, not the answer
The fleet’s path after May 2026 is the most concrete legal clue in the public record. If Waymo could move the vehicles out of Uber’s Phoenix service, back into Waymo One, and partly into a DoorDash delivery arrangement, the commercial structure likely did not give Uber any lasting possessory claim over those vehicles.[1] It is a practical sign that Waymo retained the fleet’s center of gravity: the cars, the autonomous-driving system, and the ability to decide where the vehicles would operate next.
But fleet control is not the same thing as data control. A robotaxi deployment generates multiple classes of information. Some may be vehicle telemetry. Some may be rider data. Some may be platform demand data. Some may be map, routing, pickup, drop-off, support, or incident information. Some may be jointly created through integration work. The public reports do not say which categories were created in Phoenix, how they were labeled, or whether either company had continuing rights after termination.
That is where AV partnership drafting becomes less glamorous and more important. A contract can say “Waymo property” or “Uber platform data” and still leave a later litigation team guessing. Was a rider complaint about an autonomous pickup a customer-service record, an operational-safety record, or a jointly relevant incident record? Was a routing adjustment made inside Uber’s app part of marketplace optimization, vehicle operations, or deployment know-how? Was a dashboard built for pilot monitoring a temporary integration tool or a retained business asset?
None of those questions proves a dispute. They show why the bland termination language is not enough. In a mature AV partnership agreement, the exit section should not depend on broad nouns doing specialized work. It should map specific categories of records to specific post-term consequences: retain, return, delete, anonymize, aggregate, audit, or use only for defined legal and safety purposes.
The 2018 settlement matters more after cooperation ends
The old Waymo-Uber trade-secret case is not the starting point of the 2026 termination story, but it is the legal lens that makes the exit more sensitive. In 2018, Uber and Waymo settled the trade-secret litigation for an equity package reported by WIRED as worth about $245 million, and the settlement included a binding commitment that Uber would not use Waymo’s confidential information in Uber’s hardware or software.[3]
Harvard Journal of Law & Technology described the settlement as involving 0.34% of Uber equity and an independent-monitor mechanism, while also emphasizing the unusually abrupt resolution five days into trial.[4] Butzel Long, writing from a practitioner perspective, likewise treated the settlement as a significant trade-secret resolution in the autonomous-vehicle sector.[5]
The careful point is narrow. The public settlement materials do not answer every question created by the 2026 Phoenix termination. They do not disclose the Phoenix partnership agreement. They do not show that the termination violated anything. They do not convert ordinary operational knowledge into a trade secret merely because the companies once litigated. What they do provide is one clearly visible post-settlement competitive constraint: Uber may not use Waymo hardware or software IP covered by the settlement commitment.[3]
That kind of no-use covenant is easier to describe than to administer. In an AV business, prohibited “use” may not look like copying source code or bolting another company’s sensor package onto a new vehicle. The harder disputes tend to live closer to product requirements, safety procedures, test priorities, escalation rules, interface specifications, and lessons learned from watching a system operate at the edge of its design envelope.
A lawyer reviewing Uber’s next AV partner onboarding would therefore ask practical questions before celebrating a clean pivot. Who on the Uber side had access to Waymo technical or operational materials? Which materials were governed by the 2018 settlement, the Phoenix partnership agreement, or both? Were any teams walled off? Were documents tagged by source and permitted use? Did the new partner receive requirements that were independently developed, or requirements shaped by confidential exposure to Waymo operations?
Competition changes the temperature of the same clauses
A post-term covenant does not change words simply because the business relationship cools. It changes practical significance. During a collaboration, disputes over access and operational learning can often be managed through joint committees, steering calls, shared incident review, and commercial incentives to keep the deployment running. After termination, the same facts can be reread through a competitive lens.
That competitive lens is now visible. TechCrunch reported on July 13, 2026, that Uber’s robotaxi lobbying effort had put it on a collision course with Waymo. The report cited Waymo’s self-reported scale metrics of more than 500,000 weekly rides, 11 metro areas, about 4,000 vehicles, and a February 2026 fundraising round of $16 billion at a $126 billion valuation; it also reported Uber’s parallel AV investments, including more than $300 million in Lucid, more than $300 million in Nuro, and purchase agreements involving more than 20,000 vehicles.[6]
Those figures should not be overread. The Waymo ride and fleet numbers were reported as company statements, not independent measurements.[6] They do, however, show why the Phoenix termination is more than a local pilot footnote. The former partners are not merely exiting a small deployment. They are moving into overlapping AV expansion lanes, including markets and policy fights where operational know-how, platform access, and partner substitution can have real competitive value.[6]
The unnamed Phoenix partner is especially important because it marks the gap between business readiness and legal visibility. Uber’s ability to line up another AV company suggests the Phoenix termination was planned. It does not reveal whether Uber’s agreements with Waymo restricted how quickly a replacement could launch, what technical specifications could be shared with a new partner, whether pilot performance data could inform the next integration, or whether Waymo had any audit right to verify compliance with no-use restrictions.
Data division is where neat exits usually fray
The public reports describe the fleet movement more clearly than the information movement. That is typical. Vehicles can be photographed. App availability can be checked. A delivery partnership can be announced. Data allocation usually sits in definitions, schedules, security exhibits, and post-termination clauses that never appear in a press report.
For an AV deployment, the data problem is not solved by assigning “customer data” to one party and “vehicle data” to another. The same trip can produce both. A rider request may belong to the platform for marketplace purposes. The autonomous-driving system may record vehicle behavior near the pickup zone. A support transcript may include rider-facing details and operational facts about vehicle performance. A safety review may draw from logs generated by the car, complaints handled through the app, and human decisions made by support personnel.
Once the relationship ends, those mixed records create different questions for different teams. Product teams want historical data to improve matching and pickup design. Safety teams want incident records. Compliance teams need retention for regulatory and litigation holds. Business-development teams want to show a new AV partner what the platform learned in Phoenix. IP counsel wants to know which materials can travel and which must stay locked.
A serious exit framework would not leave those teams to improvise. It would specify source-based and purpose-based rights: which party owns raw telemetry, which party may keep derived analytics, whether aggregated platform metrics can be used with future AV partners, whether safety-critical records survive deletion duties, and whether anonymization is enough when the data still reflects another party’s deployment behavior.
IP reversion needs more than a return-of-property clause
Traditional return-of-property language is too thin for AV partnerships. The property is not only the car, the sensor package, the software build, or the documentation. It is also the right to keep using APIs, app integrations, interface specifications, maps, safety cases, maintenance procedures, test results, and operational workflows created or adapted during the deployment.
If a contract grants a platform temporary access to an AV company’s system, termination should say whether that access expires automatically, whether any limited license survives for wind-down, whether support tools must be disabled, whether integration code must be removed, and whether either side can reuse jointly developed connectors. If the parties created improvements, the contract should say whether ownership follows inventorship, field of use, funding, implementation, or source system.
Residual knowledge is the uncomfortable clause. People cannot delete their memories, and companies often want employees to be able to use general skills and experience after a project ends. But in a post-trade-secret-settlement relationship, a residuals clause must be drafted with unusual care. A broad residuals right can sit uneasily beside a no-use covenant. A narrow residuals clause can be operationally unrealistic for teams that touched the deployment.
The better drafting move is not to pretend that residual knowledge does not exist. It is to define what cannot be carried forward: confidential technical specifications, nonpublic safety constraints, hardware and software design information, deployment playbooks, source-identifying analyses, and materials subject to prior settlement restrictions. Then the agreement can preserve ordinary employee skill without giving either side a back door into the other’s protected AV know-how.
The missing clauses future AV deals should not omit
The Phoenix split may have been contractually scheduled and commercially rational. That does not make it a model of public legal clarity. For counsel drafting the next AV platform partnership, the lesson is to make the exit architecture visible inside the agreement before the parties need it.
- Fleet return or redeployment: identify who controls each vehicle, when access ends, who handles maintenance and safety obligations during wind-down, and whether the AV company can redeploy vehicles to another commercial use immediately after termination.
- Data ownership and deletion: classify telemetry, rider data, platform demand data, support records, safety incidents, derived analytics, aggregated metrics, and jointly created records, then attach retention, deletion, audit, and permitted-use rules to each class.
- IP reversion and continuing licenses: state which APIs, interfaces, software components, documentation, maps, tools, and integration code must be disabled, returned, destroyed, or licensed for limited wind-down purposes.
- Residual knowledge: preserve ordinary skills without allowing confidential deployment information, technical specifications, or settlement-restricted material to migrate into a replacement partnership.
- Customer and market transition rights: define whether the platform can notify riders, move demand to a new AV partner, use historical pilot metrics in partner negotiations, or continue serving the same territory without a cooling-off period.
- Survival and audit rights: specify which no-use, confidentiality, non-solicit, non-compete-like, safety, records-retention, and verification obligations survive, and give the protected party a practical way to test compliance.
The no-use covenant from the 2018 settlement is the clearest surviving constraint visible from outside the Waymo-Uber documents.[3] It is also a reminder of how little the public termination notice tells us. A prior trade-secret settlement can police some boundaries, but it cannot substitute for a deployment agreement that spells out what happens to assets, data, licenses, customers, and operating knowledge when the commercial reason for cooperation expires.
That is the real legal implication of the Waymo-Uber termination. The problem is not that Phoenix ended. Contracts end. Pilots end. Strategic partnerships often become competitive relationships. The problem is that the cleanest public breakup still leaves the most consequential allocation questions outside public view, exactly where later disputes tend to grow.
References
- Uber, Waymo end robotaxi partnership in Phoenix, Reuters, June 29, 2026
- Waymo and Uber quietly part ways in Phoenix, TechCrunch, June 29, 2026
- Uber and Waymo Abruptly Settle For $245 Million, WIRED
- Waymo v. Uber: Surprise Settlement Five Days into Trial, Harvard Journal of Law & Technology
- Waymo v. Uber — Epic Trade Secret Case, Butzel Long
- Uber's robotaxi lobbying effort puts it on a collision course with Waymo, TechCrunch, July 13, 2026
Related records
Tool profile
Browse tool evaluations →Governing regulation
Browse the obligations tracker →Preventive workflow
Browse verification workflows →
Report a correction or tip
Spotted an outdated figure, a misstated fact, or a ruling this case record should reflect? Public comments are disabled for this content given the professional cost of a misreported case outcome, penalty amount, or rule text — use the structured correction channel instead.
Report a correction or tip for this record →