The Strix AI blog post (submitted to HN) argues Cal.com is 'learning the wrong lesson' — the AI scraping narrative is new packaging on a familiar template seen with MongoDB, Elastic, HashiCorp, and Redis. VC-backed open-source companies consistently hit a monetization wall and relicense; blaming AI coding agents is a convenient villain rather than the actual cause.
The editorial reinforces that this is really about taking $32M in VC funding against an AGPL repo, not about AI. AGPL was never going to stop motivated competitors — it was only going to deter legitimate ones, and the economic reckoning was inevitable regardless of Cursor or Claude Code.
Richelsen argues that tools like Cursor, Claude Code, and v0 let competitors reconstruct a working Cal.com clone in days rather than quarters, making AGPL irrelevant as a defensive license. For a venture-scale SaaS, he concludes open source no longer pencils out as a distribution strategy and the codebase must move behind a source-available license to protect paid features.
Cal.com, the Y Combinator-backed open-source scheduling app often pitched as the Calendly alternative, is closing its source. In a founder post amplified by a Strix AI blog breakdown that hit 314 points on Hacker News, CEO Peer Richelsen argued that AI coding agents have made it trivial for competitors to clone the product overnight, and that the AGPL-licensed codebase can no longer be the company's moat. The announced plan: move the core repo to a source-available license, keep a community edition, and concentrate paid features behind the new license boundary.
The repo in question — `calcom/cal.com` — has roughly 36k GitHub stars, a large contributor graph, and has been cited for years as a poster child for commercial AGPL. Richelsen's framing is that the rise of tools like Cursor, Claude Code, and v0 means a determined competitor can now reconstruct a working Cal.com clone in days, not quarters. The conclusion he draws: open source, as a distribution strategy for a venture-scale SaaS, no longer pencils out.
The HN thread pushed back hard, and the top comments converge on a single point: this isn't a story about AI, it's a story about open core economics finally catching up with a company that took $32M in funding against an AGPL repo. The AI angle is new packaging on an old problem.
Strip away the AI rhetoric and the Cal.com move fits a template that's been running since MongoDB's SSPL in 2018, Elastic's license change in 2021, HashiCorp's BUSL in 2023, and Redis's dual-license flip in 2024. In every case, a VC-backed company with an open-source flagship hit the moment where hyperscalers or cheaper competitors started extracting value faster than the original vendor could monetize it. The license change followed. None of those companies blamed AI, because AI wasn't yet a convenient villain.
The uncomfortable truth is that AGPL was never going to stop a motivated competitor — it was going to stop *legitimate* competitors, the ones who read licenses. Bad actors who clone your UI and reskin your Prisma schema were never deterred by copyleft; they were deterred by the cost of building feature parity. AI coding agents lower that cost, yes, but they lower it against *any* competitor's product, including closed-source ones. Notion, Linear, and Figma all get cloned weekly by Cursor-wielding indie hackers. None of them had AGPL protection to begin with.
What AI actually changes is the cost of reimplementation from specs, screenshots, and public API traces — not the cost of copying licensed code. A source-available license doesn't meaningfully slow a Claude-assisted engineer who's willing to look at your network tab and rebuild from behavior. If Cal.com's moat was the code, the moat was already gone before the license changed. If the moat is the hosted service, enterprise contracts, and SOC 2 posture, the license change is neither necessary nor sufficient — it's just cleanup.
The real signal here is that "open source" as a go-to-market wedge has a shelf life, and Cal.com is trading the wedge for margin now that it has distribution. That's a rational business decision. Dressing it up as an AI-threat response is the part practitioners should notice, because it sets a template other founders will copy. Expect "we had to close the source because of AI" to become this year's version of "pivoting to enterprise."
Community reaction tracks this. The highest-voted HN reply notes that Cal.com's contributor velocity from external developers has been low relative to core-team commits for over a year — meaning the AGPL community benefit was already thin. Another top comment points out that the company's self-hosting docs have quietly been deprioritized since mid-2025, consistent with a product org that was already planning to pull self-host into a paid tier.
If you run Cal.com self-hosted in production, three things to do this week. First, pin to a specific commit on the last AGPL-tagged release and mirror it internally — license changes are typically not retroactive, but your legal team will want provenance. Second, read the new license text carefully when it ships: BUSL, FSL, and Elastic License 2.0 have meaningfully different terms around internal use, SaaS resale, and change-date fallbacks. A scheduling widget embedded in your customer-facing product is exactly the kind of usage that source-available licenses tend to restrict. Third, if you were planning to fork, do it now, before the relicense. Post-change forks inherit the new terms.
For teams evaluating Cal.com versus alternatives, the license change should lower — not raise — your confidence in self-host as a long-term path. Cal Atoms, the embeddable scheduling primitive, is the piece most likely to end up gated. Easy@ and Rallly remain MIT-licensed, are narrower in scope, and carry less VC overhang. If your use case is "book a meeting on my website," the surface area you actually need is small enough that a 200-line component plus a calendar API integration is a defensible build-vs-buy.
For founders watching this play out: the lesson isn't "AGPL is dead." It's that AGPL was always a covenant with your *paying* customers, not your competitors. If your business model assumes the license is doing adversarial work, you have a business model problem, and no relicense will fix it.
The next twelve months will see more of these announcements, and the AI-threat framing will show up in most of them because it plays well with boards and press. Treat each one as a signal about the company's commercial maturity, not about the state of open source. Open source itself is fine — Linux, Postgres, and Kubernetes are not being cloned out of existence by Claude. What's ending is the specific arbitrage where a VC-scale company could brand itself as open source while intending, from day one, to eventually close the gate. That arbitrage was always going to close. AI just gave it a more marketable exit line.
> The reasoning provided by their CEO, Bailey Pumfleet, is that AI has automated vulnerability discovery at scale,That sounds like an excuse. The real reason is probably that it's hard to make a viable business out of developing open source.
Brilliant piece of content marketing:1) Pulls you in with a catchy title, that at first glance seems like a dunk on Cal.com (whatever that is).2) Takes the "we understand your pain" approach to empathize w/ Cal.com, so you feel like you're on the good vibes side.3) Provides a gen
>Security through obscurity is a losing bet against automationSecurity through obscurity is only problematic if that is the only, or a primary, layer of defense. As an incremental layer of deterrence or delay, it is an absolutely valid tactic, with its primary function being imposing higher costs
I wonder whether cal actually has concerns about security (in which case, they're wrong, this argument was false when people made it decades ago), or whether they just took a convenient excuse to do something they wanted to do anyway because Open Source SaaS businesses are hard.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
I have an open source project and started receiving a lot of security vulnerability reports in the last few months. A lot of them are extremely corner cases, but there were some legit ones. They're all fixed now. Closed source software won't receive any reports, but it will be exploited wi