Software Escrow and the Fisker Ocean...

In July 2026, security researcher Majd Srour did something Fisker Inc. never managed to do. He got a Fisker Ocean to steer itself down a city street, hands-free. He did it with a $999 Comma Four device, an open-source driving platform called openpilot, and a lot of reverse-engineered CAN bus messages.

It’s an impressive piece of independent engineering. It’s also a preventable failure playing out in slow motion. Every Ocean that rolled off the line in Graz, Austria, was shipped with the hardware for adaptive cruise control, lane centering, autonomous parking, and bidirectional home charging. The software to activate those features was still being written when Fisker filed for Chapter 11 bankruptcy in June 2024. When the company’s engineering team was laid off during liquidation, that software died with the company, stuck in a repository nobody outside Fisker could access.

Roughly 11,200 owners were left with vehicles physically capable of features they’d paid for but legally and practically locked out of using them. Two years later, a volunteer community is still finishing what a $2.6 billion company started and abandoned.

A software escrow agreement exists to prevent this exact scenario. Here’s how the mechanism works, how it would have changed the outcome for Fisker owners, and what current Ocean owners and contributors should be doing about it right now.

What Is a Software Escrow Agreement?

A software escrow agreement (also called technology escrow or source code escrow) is a legal and technical arrangement in which a neutral third party, the escrow agent, holds a copy of a software vendor’s source code, build instructions, documentation, and related materials on behalf of the vendor and its licensees or customers.

When a customer licenses software, they typically receive only the compiled, executable version, not the human-readable source code that would let them maintain or fix it themselves. That’s a reasonable arrangement under normal circumstances: source code is the vendor’s intellectual property. It also creates a dependency risk. If the vendor goes bankrupt, discontinues the product, gets acquired and shelved, or stops supporting the software, the customer is left with a black box they cannot repair.

A software escrow agreement solves this by defining specific release conditions, contractually agreed triggers such as vendor bankruptcy, product abandonment, or failure to meet support obligations, under which the escrow agent releases the deposited materials directly to the licensee. The vendor’s IP stays protected under normal conditions. The customer gets a guaranteed lifeline if the vendor can no longer deliver.

For connected products such as cars, medical devices, industrial equipment, and IoT hardware, software escrow has become just as important as it is for enterprise software, because the product’s core functionality increasingly lives in code the buyer never sees.

Why Fisker’s Approach Broke Down

Fisker’s Ocean buyers were never in a software escrow relationship with anyone. No third party held a copy of the ADAS code, the Park My Car autonomous parking software, or the PowerHouse bidirectional charging firmware. When Fisker’s engineers were laid off, the only copies of that code sat wherever Fisker’s internal repositories happened to live, with no clear path for anyone outside the company to reach them.

That single gap explains almost everything that went wrong afterward. The promised ADAS update never shipped, because the people who could finish it no longer had jobs, and no one else had the code to pick up the work. American Lease had to contract a third party to manage over-the-air updates on inventory it acquired at a steep discount, a firm with no history on the platform working from limited documentation, whose update reportedly bricked roughly 10 percent of vehicles. The Fisker Owners Association’s cost-sharing agreement with American Lease later collapsed over a payment dispute, cutting off connected services for private owners entirely, because there was no independent, contractually guaranteed access point to the software stack that didn’t run through a single company’s cash flow.

Owners’ only real path forward has been open-source reverse engineering, a volunteer effort that took two years to produce partial, lateral-only steering control, with full functionality still undelivered.

None of this is unique to Fisker. It’s the default outcome whenever software-gated features are sold without an escrow mechanism behind them. The industry has started calling it the “orphaned EV problem,” and it might happen again to the next EV manufacturer that fails.

How a Software Escrow Agreement Would Have Changed the Outcome

Picture the counterfactual. At the time Fisker sold Ocean SUVs with software-gated ADAS features, it had a software escrow agreement in place, naming the Fisker Owners Association or a designated group of licensees as beneficiaries, with release conditions triggered by bankruptcy, cessation of operations, or failure to deliver promised updates within a defined window.

Here’s what changes.

The moment Fisker files for Chapter 11, the release condition triggers. No lawsuit. No two-year wait for a community to reverse-engineer the CAN bus from scratch. The escrow agent verifies the bankruptcy filing against the contractually defined release condition and releases the deposited source code, build environment, and documentation to the beneficiary group within the agreed timeframe. With Automated Escrow in place, that release draws from a deposit that reflects the software’s most current state, not a stale snapshot from months or years earlier, because every meaningful commit to the codebase triggers a fresh, verified update automatically.

Owners, or a contracted developer working on their behalf, get the actual unfinished ADAS code, not a black box they have to rebuild from zero using externally observed CAN messages. The adaptive cruise control, lane centering, and Park My Car features that sat grayed out, waiting on an update that never came, could potentially have been finished and shipped by a third-party engineering team working from Fisker’s own codebase, the same work Srour has been doing independently, just faster and with official documentation instead of guesswork.

The deposited materials wouldn’t just sit untested. A well-structured escrow agreement requires the deposit be checked before that moment ever arrives, to confirm it contains everything a beneficiary would actually need. This is where Technical Verification does its work: engineers independently confirm the deposit is complete (every file, library, and build script needed to compile the code is present), accurate (the deposited version matches what’s genuinely running in production vehicles), and functional (the code can be built from scratch and actually executed, exercising the adaptive cruise control and lane centering routines, rather than sitting as inert files). PRAXIS treats this process as a full rebuild standard rather than a documentation check, because a deposit that hasn’t been rebuilt and run is still just an unverified promise. Owners wouldn’t have had to discover whether the escrowed code even worked. That question would already be answered.

There’s also no dependency on a single company’s cash flow to keep the lights on. The collapse of the American Lease and Fisker Owners Association cost-sharing deal wouldn’t have severed access to the underlying software, because the software wouldn’t have lived exclusively inside a commercial relationship that could fall apart over a payment dispute. Escrow exists specifically outside of, and independent from, ongoing vendor solvency.

Finally, owners would have had a legal remedy instead of only a technical workaround. Current reporting on the case notes that when a manufacturer fails to deliver promised features and then ceases to exist, there’s no legal mechanism for the buyer to recover them. A software escrow agreement is that mechanism. It converts an abstract promise into a contractually enforceable release condition with a defined trigger and a defined deliverable.

This is precisely why policy advocates have started pushing for software escrow requirements and open-source transition clauses in EV bankruptcy proceedings. It’s a well-established mechanism from the enterprise software world, applied to a category of product that needed it just as badly and didn’t have it.

Why Fisker Owners Need an Escrow Agreement Now

The need for software escrow didn’t expire when Fisker did. If anything, it’s more urgent now.

The Ocean’s software ecosystem currently depends on Majd Srour’s ongoing, unpaid reverse-engineering work on the openpilot port (currently steering-only and still unmerged), the broader openpilot open-source community of over 1,000 contributors with no contractual obligation to maintain Fisker Ocean support specifically, the continued existence of the underlying open-source driving platform for third-party vehicle ports, and whatever remains of Fisker’s original codebase, wherever it sits under whatever IP ownership resulted from the bankruptcy liquidation.

Every one of those dependencies is a single point of failure. If Srour stops working on the port, if the branch never merges, if platform priorities shift, or if the original Fisker source code is sold off, deleted, or locked in a liquidation estate nobody can access, the Ocean’s software future is exactly as fragile as it was in 2024, just with different names attached.

A software escrow agreement established now protects against this outcome. It formalizes a contributor’s work product into a legally protected asset that survives any individual’s decision to stop contributing. It creates a permanent, neutral repository for the current state of the Ocean’s ADAS and CAN integration code, independent of any one developer’s laptop or any single platform’s roadmap decisions. It gives the Fisker Owners Association a real governance mechanism over the software its members depend on, rather than relying entirely on volunteer goodwill. And it sets clear release conditions for what happens to that code if the current arrangement ever breaks down again.

The Escrow Mechanisms That Matter Most Here

Automated Escrow

Automated Escrow refers to deposit processes that are triggered and executed automatically, typically integrated directly into a developer’s or vendor’s existing build pipeline, version control system, or CI/CD workflow.

For a project like the Ocean CAN integration, this matters enormously. The code is actively evolving, with an unmerged branch still being refined as longitudinal control gets added week to week. A manual, occasional deposit updated once a year or once and never again would quickly become outdated and useless in the kind of crisis it’s meant to prevent. Automated Escrow connects the deposit directly to the source repository, so every meaningful commit or release triggers a fresh, verified update. The beneficiary is protected by the current working version of the software.

Technical Verification

Technical Verification is the process of independently testing deposited materials to confirm they’re complete, accurate, and functional, rather than accepting whatever files a vendor or developer hands over and trusting they’re sufficient.

Without verification, a vendor could deposit an outdated version of the code, an incomplete set of files missing key libraries, or source code that exists but doesn’t actually compile. The beneficiary has no way of knowing until the release condition fires, and they try to use what was deposited, at which point it’s too late to ask a laid-off engineering team to fix it. PRAXIS applies Technical Verification as a full rebuild standard: engineers actually attempt to build and run the deposited software before it’s ever needed, checking completeness, accuracy against the production version, and functionality through real execution.

Infinite Retention

Infinite Retention refers to an escrow storage model with no fixed expiration date on deposited materials, as opposed to traditional arrangements that guarantee retention only for a fixed term before materials can be purged.

This matters specifically because of the product at issue. A Fisker Ocean isn’t enterprise software on a typical multi-year replacement cycle. It’s a physical vehicle already on the road that owners reasonably expect to keep driving for a decade or more. Software escrowed today needs to still be retrievable in 2036, not just 2029. Infinite Retention removes the risk of a well-intentioned escrow agreement quietly expiring right around the time it’s needed most.

PRAXIS: Built for This Kind of Flexibility

Not every situation fits neatly into a standard, off-the-shelf escrow template, and the Fisker Ocean case is a good example of why. This isn’t a single vendor depositing code for a single customer. It potentially involves source code contributed by an independent security researcher rather than a formal corporate vendor, a beneficiary group that’s a nonprofit owners’ association representing thousands of individual titleholders, release conditions that need to account for the open-source, community-maintained nature of the underlying platform, and multiple potential depositing parties over time as different contributors add tuning or further integration work.

PRAXIS is built to flex around structures like this rather than forcing every relationship into the same mold. Our Automated Escrow supports multi-party and multi-beneficiary structures with custom release conditions tailored to the actual risk profile of a situation. Every engagement runs on all-inclusive pricing, so there are no surprise fees for the ongoing deposit updates or verification cycles a case like this would need over time. As a U.S.-based provider operating under SOC 2 certification, PRAXIS gives beneficiary groups a jurisdiction and a compliance standard they can point to with confidence, whether they’re a formal corporate licensee or a nonprofit owners’ association. And Escrow Assurance™ ties the whole arrangement together: it’s our commitment that a deposit isn’t just filed away, but actively verified and ready to perform the moment a release condition fires.

That flexibility is what a situation this unusual needs: a bankrupt manufacturer, an open-source workaround, a nonprofit owners’ association, and thousands of individual vehicle owners who all have a stake in making sure this code never disappears.

The Lesson Extends Well Beyond One Bankrupt Car Company

The Fisker Ocean story is being told as a triumph of open-source ingenuity. It’s also a two-year case study in what happens when a product’s core promised functionality lives entirely inside a single company’s walls, with no independent, legally enforceable path to that functionality if the company disappears.

Software escrow, with automated and continuously updated deposits, technical verification treated as a full rebuild standard, infinite retention for long-lived products, and a flexible platform capable of structuring unconventional, multi-party arrangements, is the mechanism the industry has already built to solve exactly this problem. Fisker Ocean owners, the Fisker Owners Association, and the developers now carrying that work forward have an opportunity to make sure that whatever comes next for this vehicle’s software doesn’t depend on the same kind of fragile arrangement that left them stranded the first time.