Someone Forked Your Code. The Regulator Still Calls You.

On September 21, the National Highway Traffic Safety Administration's Office of Defects Investigation opened a preliminary evaluation into Comma.ai. The agency cited five reported crashes involving Comma's aftermarket driver assistance hardware. Two were fatal, and three people died. Across four of the crashes, as many as 11 people were injured.

The pattern NHTSA described is a familiar one for driver assistance systems: failing to detect or respond to slow or stopped vehicles in the same lane.

Here is the detail that should make every open-source founder sit up. According to the agency, some of the crashes, possibly including at least one fatal one, may have involved forked versions of Comma's openpilot software rather than the company's own release. One case appears to be a February 2026 crash in Ascension Parish, Louisiana, where a 2022 Toyota RAV4 running FrogPilot, a community fork, struck an unoccupied police vehicle stopped with its emergency lights on. Two rear-seat passengers died.

The investigation covers the comma three, comma 3X and comma four devices, plus openpilot and the forks built from it. Your license may say the fork is someone else's code. The investigation scope says the regulator is still starting with you.

Because the hardware, the brand and the install base all trace back to one place.

Comma sells the device. Openpilot runs on it. Forks run on the same device, often installed with a few taps, and to a crash investigator, a police report or a jury, the box on the windshield says comma. The legal question of who is responsible for modified code is real and unsettled. The practical question of who gets the first letter is not.

This is not unique to cars. Any company that ships open code onto hardware it sells, or into a platform it runs, faces a version of the same thing. The community that makes your project exciting is also the community that can ship a variant with its safety limits turned off.

Nothing here is legal advice, and the specifics depend heavily on your industry and your country. But the pattern is clear enough to plan around.

It would be easy to read this as a company that ignored risk. The public record says otherwise, and that is what makes the case useful.

Comma's own support pages say openpilot's adaptive cruise control performance can be affected by vehicles in the same lane that are not moving. They say openpilot is designed to limit how hard it can brake or accelerate. The company tells drivers they must be able to retake control immediately with a pedal or the cancel button, and the device uses a camera to watch for distracted or drowsy drivers.

Those are real guardrails. They sit in the official software. The open question in any fork is which of them survived.

That is the lesson worth taking. Documentation and default limits protect the version you ship. They do nothing for a version someone else modified, unless your product has a way to tell the two apart.

A quick way to check whether this applies to you. Answer yes or no.

Does your product include open-source code that users can modify and redeploy?

Does it run on hardware you sell, or inside infrastructure you operate?

Could a modified version cause physical harm, financial loss or a data breach for someone other than the person who modified it?

Would a journalist, regulator or plaintiff naturally describe an incident using your company's name?

Two or more yeses and you have fork exposure. That covers robotics, drones, medical devices, fintech SDKs, smart home firmware, AI agents that take actions, and a growing number of developer tools.

The fourth question is the one founders skip, and it is the one that decides whose name is in the headline.

Most of the moves below keep the project open. They make the official version distinguishable and make unsafe changes harder to hide.

Separate the safety layer. Put the limits that prevent harm in a component that is signed, versioned and checked at startup, even if everything above it is open. Users can still fork the features. They have to go out of their way to strip the guardrails, and the device can tell when they have.

Make the running version visible. If support, logs or crash data can show exactly which build was installed, you can answer an investigator's first question in hours instead of months.

Draw a clear line in your trademark policy. Open-source licenses cover code. Trademark policies cover names. Requiring forks to use a different name, and not implying your endorsement, is a normal and widely used practice.

Document the known limits in plain language, the way Comma documented stopped vehicles. Specific beats vague. A limit that names the scenario is one a user can plan around.

Keep a written incident process. Who reviews a report, how fast, and what triggers a notice to users.

In your product plan, not in a legal folder you open after something goes wrong.

Safety architecture, trademark rules and incident response all cost engineering time. If they are not in the roadmap, they get pushed behind the next feature every sprint. Put them in the same document as your launch milestones and your hiring plan. A plain spreadsheet works. So does a planning tool like Foundra, where the risk items sit next to the product and financial plan and get reviewed on the same cadence.

Investors will ask about this too, especially in hardware and AI. A founder who can say which of their guardrails are signed, which builds are running in the field, and what the fork policy is will have a much shorter diligence call than one who says the license covers it.

1. List every component in your product that limits harm: rate limits, spending caps, physical safety limits, permission checks.
2. Mark which of those live in code a user can modify and redeploy.
3. For each one that can be modified, decide whether it should be signed, checked at startup, or moved server-side.
4. Write a one-page trademark and naming policy for forks, and link it from your repository.
5. Add a build identifier to your logs and support flow so you can always answer: which version was running?

None of this requires closing your code. It requires knowing which version did what, and making sure that answer is easy to find.

When a regulator, an insurer or a large customer looks into an incident, the first questions are usually simple. Your ability to answer them quickly matters more than any single answer.

Which version was running? If you cannot tell the difference between your release and a modified build from the logs or the device itself, every incident becomes yours by default.

What limits were supposed to apply? Written, dated documentation of what the product is designed to do and not do is the starting point for any review.

When did you learn about the problem? Support tickets, forum posts and bug reports all carry timestamps. If users flagged a pattern months ago, someone will find that thread.

What did you do after you learned? Fixes, warnings, blocked versions and updated documentation all count. Silence counts too, the other way.

None of these questions depends on whether your code is open or closed. They depend on whether you kept records that let you tell your own story. For a small team, that can be as simple as a changelog, a shared incident sheet and a habit of writing down decisions on the day you make them.

This applies well beyond hardware. If you ship an AI agent that can move money, send messages or change settings, the same four questions will come the first time it does something a customer did not expect.

Is Comma.ai responsible for crashes involving forks? That is exactly what the investigation is looking at, and it has not reached a conclusion. NHTSA has said it will evaluate whether modified software was involved.

What is a fork? A copy of an open-source project that someone else changes and distributes separately. FrogPilot is one example built from openpilot.

Does an open-source license protect me from liability? Licenses typically disclaim warranties, but they do not decide how regulators or courts treat a product you sell. Get advice from a lawyer who knows your sector.

Should I stop open-sourcing my product? Not necessarily. Many companies keep code open while signing the safety-critical parts and enforcing naming rules for forks.

Which industries face the most fork risk? Any where a modified version can hurt people other than the person who changed it: vehicles, drones, medical devices, payments and AI agents that take real actions.

1. Comma’s hands-off driving tech under investigation after 2 fatal crashes, TechCrunch, September 23, 2026
2. Feds Investigating Plug-and-Play Aftermarket Hands-Free Driving Tech Company After 3 Reported Deaths, Yahoo News
3. Comma AI’s retrofit driver-assist faces a federal probe after five crashes, Runtime Wire
4. Openpilot, Wikipedia
5. Top Tech News Today, September 23, 2026, Tech Startups