On April 4, Y Combinator publicly cut ties with one of its portfolio companies. That almost never happens. YC does not do this. They'll quietly distance themselves from a failing startup, but publicly parting ways? That's a signal of something bad enough that staying quiet felt worse than the embarrassment.
The company is Delve — an AI compliance startup. The reason is one of the weirder startup scandals in recent memory, and it has direct implications for any small org buying AI tools right now.
Here's what happened, and what you need to be asking your vendors.
The Setup: An AI Compliance Startup That Wasn't Compliant
Delve positioned itself as an AI-powered compliance and due diligence tool. The pitch: automate the tedious parts of regulatory research, vendor assessments, policy tracking. Exactly the kind of thing that's genuinely useful for a 20-person NGO that doesn't have a full-time compliance officer.
They raised from Y Combinator. They were growing.
Then an anonymous whistleblower calling themselves "DeepDelver" published a Substack series with receipts.
The allegation: Delve had quietly forked SimStudio — an open-source agent-building tool published by a company called Sim.ai — and rebranded it as their own proprietary product, "Pathways." Not inspired by it. Not built on top of it with attribution. Forked it, stripped the credits, and sold it to customers as Delve's original technology.
The kicker: Sim.ai was a paying Delve customer at the time.
Sim.ai's CEO publicly confirmed there was no license agreement whatsoever. Delve hadn't even bothered to ask. SimStudio is open source, but open source isn't the same as "free to clone and sell as your own." The specific license matters enormously — and regardless of which license SimStudio uses, selling someone else's work as your proprietary invention is fraud, not just a licensing technicality.
Within days, YC made the call. On April 4, they announced they had "parted ways" with Delve.
Why This Is Your Problem, Not Just Theirs
Here's the thing: Delve's customers didn't do anything wrong. They bought a tool, they used it, they built workflows around it. They thought they were using a compliance product. And now they're holding a contract with a vendor that may not own the software it sold them.
That's a mess. Depending on how it shakes out legally, those customers could face:
- License liability if Sim.ai decides to assert rights against downstream users
- Operational disruption if Delve shuts down and the underlying (stolen) software becomes unavailable
- Data exposure questions if Delve had access to their compliance data and is now in freefall
None of that is hypothetical. This is what vendor IP risk actually looks like in practice.
And here's the uncomfortable truth: this is almost certainly not the only time it's happened. The AI tooling market right now is moving so fast that a lot of "proprietary AI products" are relatively thin wrappers around open-source components. That's not inherently bad — plenty of great products are built on OSS foundations. But there's a meaningful difference between "we built on top of LangChain with proper attribution" and "we quietly forked someone's open-source project and erased their name."
Most buyers have no idea which situation they're in.
What "Open Source Under the Hood" Actually Means
Most AI tools you're evaluating today are built on open-source components to some degree. That's fine. Apache 2.0 and MIT licenses — which cover a huge percentage of AI tooling — are permissive enough that commercial use, modification, and resale are allowed as long as attribution requirements are met. If a vendor is using LangChain, Ollama, PostgreSQL, or a hundred other commonly licensed tools, there's no issue.
The problems show up in two scenarios:
Scenario one: A tool is built on a license that's more restrictive — AGPL, for instance, which requires anyone who uses the software to also open-source their modifications. Some vendors don't realize this, or hope you won't. If you deploy an AGPL tool in a commercial context without understanding your obligations, you inherit a compliance problem.
Scenario two: A vendor is doing what Delve allegedly did — passing off OSS as their own proprietary work. This creates fraud risk and potential IP liability that can transfer downstream to customers.
You don't need to be a lawyer to protect yourself. You need to ask the right questions before you sign.
Five Questions to Ask Before You Buy Any AI Tool
These take about 15 minutes and will filter out 90% of the vendor risk scenarios that matter:
1. "What open-source components does your product use, and under what licenses?"
A legitimate vendor will answer this without hesitation. Many SaaS products publish an OSS acknowledgments page. If a vendor gets defensive or vague — that's a signal.
2. "Can you provide a software bill of materials (SBOM) or OSS license disclosure?"
Larger procurement processes ask for this routinely. For smaller purchases it may feel formal, but any vendor who's done their licensing homework will have this. If they've never heard of an SBOM, that's worth noting.
3. "Do you have legal confirmation that you hold all necessary licenses to provide this software commercially?"
Ask for a written warranty in your contract. Standard vendor agreements often include IP indemnification — meaning if someone sues you because the vendor didn't own what they sold you, the vendor covers it. If they resist adding this, walk.
4. "If your company closes or is acquired, what happens to our access and our data?"
This is basic continuity planning, but it becomes critical when a vendor is in the kind of turmoil Delve is now in. Know your exit path before you need it.
5. "Has your company had any IP disputes or licensing claims against it?"
Direct. Maybe awkward. But a legitimate company will answer straightforwardly. A company with something to hide will hedge.
The Bigger Pattern Here
The Delve story is unusual because it got caught and because YC's response was public. Most vendor IP problems are quieter and messier — they surface in acquisition due diligence, or when a startup shuts down and the open-source maintainer sends a cease-and-desist, or when a lawyer reads the license on your vendor's dependency tree for the first time.
Small orgs are disproportionately exposed to this. You're making faster procurement decisions with less legal oversight than a large enterprise would apply. You're relying on a vendor's word more than a contract's warranties. You're building workflows on tools that may have murky IP provenance.
That's not a reason to avoid AI tools — the productivity gains are real and the competition for adopting them is already happening. But "move fast" and "move blind" are different things.
The question "what's actually under the hood?" costs nothing to ask. And right now, with the market moving this fast and this chaotically, it's worth asking every time.
We evaluate AI tools for clients before they commit — including a basic vendor risk pass to catch exactly this kind of issue. If you're looking at a new AI tool and want a second set of eyes, let's talk.