TechCrunch frames Delve's actions as part of a pattern of troubled behavior, reporting that the startup allegedly forked an open-source tool and sold it as its own proprietary product. The article positions this as a reputational crisis not just for Delve but for YC's vetting process.
Submitted the story to Hacker News where it drew 277 points and 142 comments, reflecting strong community engagement. The high score signals that developers view open-source license violations by funded startups as a serious breach of trust.
The editorial argues the Delve case follows a well-established pattern: a startup takes an open-source project, adds a thin proprietary layer, and raises VC money on top of it. This structural incentive problem means incidents like this will keep happening as long as venture capital rewards speed over provenance.
By framing Delve as a 'troubled YC startup' in the headline, TechCrunch implies that Y Combinator's brand is on the line. The article suggests this is not an isolated incident but the latest in a series of controversies, raising questions about YC's due diligence on founder ethics.
The editorial emphasizes the chilling effect on the broader ecosystem: when funded companies strip attribution and commercialize open-source work without compliance, it discourages maintainers from publishing code under open licenses. The 277-point HN score is cited as evidence that developers take these violations personally because many are themselves maintainers who have experienced similar appropriation.
Delve, a Y Combinator-backed startup already dogged by prior controversies, now faces allegations that it forked an open-source tool and sold it as its own proprietary product. The story, broken by TechCrunch, landed on Hacker News where it drew a score of 277 — high enough to signal genuine community anger rather than idle curiosity.
The core allegation is straightforward: Delve allegedly took an existing open-source project, stripped or obscured its provenance, and commercialized it without proper attribution or license compliance. The specifics — which repo was forked, what license it carried, and how much code was directly lifted versus modified — form the technical backbone of the dispute.
This isn't Delve's first time in the crosshairs. The TechCrunch headline explicitly frames this as the latest chapter for a "troubled" startup, suggesting a pattern of behavior rather than an isolated misstep. For YC, which prides itself on vetting founders and maintaining network trust, the association is increasingly awkward.
The open-source ecosystem runs on trust. Thousands of maintainers publish code under permissive or copyleft licenses with the expectation that the social contract — attribution, license compliance, contributing back — will be honored. When a funded startup allegedly violates that contract to build a commercial product, it doesn't just harm the original maintainers. It erodes the implicit trust that makes developers willing to open-source their work in the first place.
The Hacker News reaction (277 points) reflects a developer community that takes these violations personally, and for good reason. Many HN readers are themselves open-source maintainers who have watched their work get absorbed by commercial entities with zero acknowledgment. The Delve case isn't novel in structure — it follows a pattern we've seen repeatedly: startup takes open-source project, adds a thin proprietary layer, raises VC money on the combined product, and hopes nobody notices the foundation isn't theirs.
What makes this case notable is the YC connection. Y Combinator alumni networks carry significant social capital in the startup ecosystem. When a YC company gets caught allegedly violating open-source norms, it raises questions about due diligence. Did anyone at YC review Delve's codebase provenance? Was there a technical audit? Or does the accelerator model — fast in, fast out, high volume — structurally discourage the kind of deep technical vetting that would catch this?
The uncomfortable truth is that the current incentive structure rewards this behavior. A startup that forks an open-source tool and wraps it in a SaaS offering can reach market faster than one building from scratch. The risk of getting caught is low (most open-source maintainers lack the resources for legal action), and the consequences — even when caught — rarely extend beyond bad press. Delve may face reputational damage, but unless there's a license with real teeth (GPL, AGPL) and a maintainer willing to enforce it, the practical consequences may be minimal.
This case highlights a structural problem in the open-source world: the gap between what licenses require and what actually gets enforced. Permissive licenses like MIT and BSD make forking trivially easy and enforcement nearly impossible — you're required to include the copyright notice, but proving a violation in a closed-source SaaS product requires access you typically don't have.
Copyleft licenses (GPL, AGPL) offer stronger protections in theory, but enforcement still requires resources. The Software Freedom Conservancy and similar organizations do enforcement work, but they can only cover a fraction of violations. For individual maintainers, discovering that a funded startup has commercialized your work and having no practical recourse is a demoralizing experience that directly impacts the sustainability of open-source.
Tools like Software Composition Analysis (SCA) scanners — Snyk, FOSSA, Black Duck — exist to detect open-source components in proprietary codebases. But they're typically used by companies worried about *their own* compliance, not by maintainers trying to detect unauthorized use. The asymmetry is structural: the entity with the resources (the startup) has the tools to check compliance, and the entity harmed by non-compliance (the maintainer) doesn't.
If you maintain an open-source project, this is a prompt to review your licensing strategy:
- If you want maximum adoption and don't care about commercial use: MIT/BSD is fine, but understand that you're explicitly allowing exactly what Delve allegedly did (minus the attribution stripping). - If you want to prevent proprietary forks: AGPL is your strongest tool. It requires that any network-accessible derivative work also be open-sourced. Companies like MongoDB (SSPL) and HashiCorp (BSL) have moved to even more restrictive licenses for exactly this reason. - If you want a middle ground: Consider dual licensing — open-source for community use, commercial license for companies building products on top of your work.
For startup founders: if your product incorporates open-source components (and it almost certainly does), run an SCA scan before your next funding round. Investors are increasingly asking about open-source compliance, and getting caught post-funding is significantly worse than disclosing proactively.
For YC and other accelerators: this might be the case that prompts adding open-source provenance checks to the standard due diligence checklist. A simple SCA scan during batch onboarding would catch the most egregious cases.
The Delve situation will likely follow the familiar arc: intense community anger, a founder statement that either apologizes or disputes the claims, and then gradual fade from the news cycle. The structural incentives won't change from one case. But each high-profile incident does shift norms incrementally — more maintainers choose protective licenses, more investors ask about compliance, and more developers remember the name of the company that got caught. Whether that's enough to actually deter the next Delve is an open question. The open-source ecosystem's immune system works, but it's slow, and the damage is done before the antibodies arrive.
The project is Apache licensed, so even if they took it, outside of lacking attribution / retaining copyright, I don't see a problem? They would be require to add it to an "About" tab or something.The project in question is here:https://github.com/simstudioai/
The thing that strikes me as odd is how is it that Delve becomes an unicorn superstar (by iself), and the company they steal stuff off of, is much much less of a success story.It would make more sense that the people who actually built the thing would do the thing better and do it first.
In the long list of Delve's misdeeds, this is probably the least of them.
I had someone steal my MIT open source software (that I sell for $5) and they are selling it for $11 or more. My software is 8+ years old; they are lying to the customers that they have been developing theirs for years. Very frustrating.mine: https://videohubapp.com/my GitHub: https:&
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
What probably happened here is depressingly common in early-stage startups. Someone finds an open source tool that does 80% of what they need, forks it, strips the branding, and then ships it. Nobody thinks about the license because the company is in "move fast" mode and there's no pr