The editorial argues that the AI framing has 'a kernel of truth wrapped in a lot of strategic convenience,' noting that Cal.com follows an established pattern where VC-backed companies grow using open-source distribution advantages then restrict licenses when competitive dynamics shift. It places Cal.com in a direct lineage with HashiCorp, Redis, Elastic, and Sentry.
Cal.com's leadership frames AI companies ingesting open-source codebases as an existential risk, arguing that AI-assisted developers can now spin up competitors in days using an open codebase as a blueprint. They contend this represents a fundamentally new threat vector that the open-source model was never designed to handle.
The article's title — 'Open Source Isn't Dead. Cal.com Just Learned the Wrong Lesson' — frames the restriction as a misdiagnosis. The argument is that open source remains viable and that Cal.com's retreat reflects a flawed business model conclusion rather than a genuine failure of the open-source paradigm itself.
The editorial traces a recurring pattern: in 2018-2021 the villain was AWS and hyperscalers hosting OSS as managed services, producing SSPL and BSL licenses. In 2026 it's AI. The argument is that each relicensing cycle requires a sympathetic narrative, and the villain changes but the commercial motivation — protecting a VC-backed business from competition enabled by its own openness — remains constant.
Cal.com, the open-source scheduling platform that positioned itself as the developer-friendly alternative to Calendly, is restricting access to its source code. The company — which built its brand and its GitHub star count on being open — is joining the growing list of venture-backed projects that have decided openness is a liability.
The stated reason is AI. Specifically, the concern that AI companies are ingesting open-source codebases to train models that can then replicate products wholesale, or that AI-assisted developers can spin up competitors in days instead of months using an open codebase as a blueprint. Cal.com's leadership is framing this as an existential threat that the original open-source social contract never anticipated.
The move follows a pattern that is now well-established: company raises venture capital, grows using the open-source distribution advantage, achieves meaningful traction, then restricts the license when the competitive dynamics stop being favorable. HashiCorp did it with Terraform (BSL 1.1, August 2023). Redis did it in March 2024. Elastic did it back in 2021. Sentry introduced the Functional Source License in late 2024. Cal.com is the latest, and it won't be the last.
### The AI Framing Is New. The Problem Isn't.
Every relicensing wave needs a villain. In 2018-2021, it was AWS and the hyperscalers: companies hosting open-source software as managed services without contributing back. That narrative was credible enough to generate sympathy, and it produced the SSPL and BSL license family.
In 2026, the villain is AI. And the narrative is: "AI companies are scraping our repos, training on our code, and enabling anyone to recreate our product." This framing has a kernel of truth wrapped in a lot of strategic convenience. Yes, code is being ingested into training data. Yes, AI coding assistants make it faster to clone functionality. But the honest version of the conversation is simpler: the open-source business model has a fundamental tension between distribution and defensibility, and that tension exists whether or not LLMs are in the picture.
Cal.com's core product is a scheduling API. Scheduling is a well-understood problem domain. The competitive moat was never the code — it was the ecosystem, the integrations, the hosted reliability, and the community. If AI makes your code less defensible, that means your code was your moat, which means you were already in trouble.
### The Pattern Is Now Predictable
Here is the lifecycle, observed across a dozen companies:
1. Launch open-source to capture developer mindshare without a marketing budget 2. Raise venture capital on the growth metrics that open-source distribution provides 3. Build a managed/hosted product as the monetization layer 4. Discover that self-hosting users don't convert at the rate the Series B model requires 5. Restrict the license under a narrative that names an external threat 6. Community forks the last open version (OpenTofu, Valkey, OpenSearch)
We are watching step 5 happen in real time, again. The only thing that changes is the named threat. The structural incentive is identical every time: VC-scale economics are incompatible with permissive open-source licensing for single-product companies.
### What the Community Is Saying
The Hacker News discussion (213 points at time of writing) reflects the now-familiar split. One camp argues that maintainers have every right to protect their work and that the "open source purist" position ignores the reality of building sustainable businesses. The other camp argues that Cal.com built its user base on an open-source promise and is now breaking that implicit contract.
Both positions are correct, which is exactly why this keeps happening. The open-source social contract was never a contract — it was a vibe. There was no binding agreement that said "we will stay AGPLv3 forever." And there is no economic law that says VC-backed companies can sustain permissive licensing indefinitely. The surprise isn't that companies relicense. The surprise is that developers keep being surprised.
### Audit Your Dependencies
If Cal.com is in your stack, the immediate action is straightforward: check which version you're running, understand the license terms of that version, and determine whether the new license affects your use case. If you're using the hosted product, nothing changes immediately — you're a customer, not a licensee. If you're self-hosting, you need to read the new terms carefully.
More broadly, this is a good moment to audit your dependency on any single-vendor open-source project where the vendor's business model depends on converting self-hosters to paying customers. If the company has raised $20M+ and the project has a restrictive-license-shaped hole in its future, plan accordingly.
### The Fork Question
Every relicensing produces a fork. Terraform begat OpenTofu. Redis begat Valkey. The question is always whether the fork sustains momentum. The answer usually depends on whether a cloud provider or foundation adopts it. For scheduling infrastructure — a smaller market than databases or infrastructure-as-code — the fork economics are less favorable. There may not be an AWS or Linux Foundation stepping in to maintain a Cal.com alternative.
This means self-hosters should evaluate whether scheduling is actually a problem that needs a large open-source framework, or whether a simpler approach — a lightweight library, a direct integration with Google Calendar / Microsoft Graph APIs, or a managed service you pay for — is the more resilient choice.
### Build vs. Buy Revisited
The meta-lesson is about architectural decisions. Every time you adopt an open-source project from a VC-backed company, you are making a bet that the company's incentives will stay aligned with yours. That bet has a shelf life. For infrastructure you truly depend on, you have three options:
1. Use foundation-governed projects (Linux, Kubernetes, PostgreSQL) where no single company controls the license 2. Pay for the managed service and accept the vendor relationship explicitly 3. Own the layer yourself if it's core to your product and simple enough to maintain
Scheduling falls into category 3 for most teams. It's important but not complex enough to justify a heavy framework dependency with license risk.
The "AI threat" narrative for relicensing is going to accelerate. It's more emotionally resonant than the "AWS is eating our lunch" narrative because it implies something almost predatory — machines learning from your work to replace you. Expect every VC-backed open-source company that relicenses in 2026 to cite AI as the reason, regardless of whether AI is actually the competitive threat or just the convenient framing. The real question for the open-source ecosystem isn't whether Cal.com made the right call. It's whether the VC-funded open-source model was ever going to end differently.
> 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