Cal.com Blamed AI Hackers for Going Closed-Source. Its Own AGPL History Explains More

On April 15, 2026, Cal.com — the YC-backed, API-first alternative to Calendly that has spent five years as one of the most visible AGPL projects in the developer tooling space — stopped being open source. Not "restricted the enterprise tier" open source. Not "added a field-of-use clause" open source. The core product moved to a proprietary license, and the genuinely open code was split off into a new, deliberately hobbled repository called Cal.diy.

The stated reason, attributed to CEO Bailey Pumfleet in coverage from The Register and XDA Developers, was AI. Publicly available source code, the argument goes, is now a gift to attackers who can point coding agents at a repo and have it triaged for exploitable bugs in minutes: "Open-source code is basically like handing out the blueprint to a bank vault. And now there are 100x more hackers studying the blueprint," Pumfleet reportedly said.

That explanation got a rough reception. It also, on inspection, isn't the most interesting thing about what changed. I cloned the new repository, read the license file and the README warnings directly instead of taking press summaries at face value, and the mechanics of how Cal.com restructured its licensing tell a more specific story than "AI made us do it" — one that has less to do with hackers and more to do with a clause in the AGPL that Cal.com's own hosted product had been quietly obligated to for years.

What Cal.com actually is

If you haven't run into it: Cal.com is scheduling infrastructure, not just a scheduling app. It ships a hosted SaaS product at cal.com that competes directly with Calendly, but its differentiator has always been that the same codebase is self-hostable and embeddable — companies build booking flows into their own products against Cal.com's API rather than linking out to a third-party page. That self-hosted, source-available posture is a big part of why it accumulated tens of thousands of GitHub stars and became a default recommendation on "open-source SaaS alternatives" lists.

Since 2022, Cal.com ran what's called an open-core model: the core app was AGPL-3.0, and a separate /ee/ (Enterprise Edition) directory held commercial-only code for things like Teams, Organizations, Insights, Workflows, and SSO/SAML, gated behind a paid license key. That structure is documented in Cal.com's own self-hosting license-key docs and in its 2023 blog post "Changing to AGPLv3 and introducing the Enterprise Edition". Open core, AGPL floor, proprietary ceiling — a well-worn pattern shared by plenty of infrastructure companies.

What changed on April 15

The April 2026 move didn't tweak that split — it inverted it. The AGPL core itself became proprietary. What used to be "free core + paid enterprise add-on" became "paid product + a separately maintained MIT fork with the enterprise code physically deleted, not just license-gated."

I checked this directly rather than trusting a secondary source. The cal.diy repository's LICENSE file reads MIT, copyright Cal.com Inc. 2020–present. Searching the tree for the old /ee/ enterprise directory and the "Enterprise Edition" gating code that used to ship alongside the AGPL core turns up nothing — the enterprise features aren't dormant behind a license key check anymore, they're absent from the source entirely. The README states it plainly: "Unlike Cal.com's 'Open Core' model, Cal.diy has no commercial/enterprise code."

The same README opens with a warning block that's doing a lot of quiet work:

Use at your own risk. Cal.diy is the open source community edition of Cal.com and it is intended for users who want to self-host their own Cal.diy instance. It is strictly recommended for personal, non-production use.

And immediately under that, a redirect: for "commercial and enterprise-ready scheduling infrastructure, use Cal.com, not Cal.diy." In other words, the free version now comes with an explicit "don't actually run this for anything that matters" disclaimer baked into the project's front door. That's a materially different posture from a standard open-core split, where the free tier is fully production-capable and the paid tier just adds convenience or scale.

If you want to run the pre-April, fully-featured, AGPL version of Cal.com in production going forward, the path is a paid Self-Hosted Commercial License with a license key — the same enterprise licensing infrastructure that used to gate only the /ee/ add-ons now gates the base product.

The reason Cal.com gave, and the one it didn't

The "AI lets attackers read your blueprints faster" argument isn't crazy on its face — AI-assisted code auditing genuinely lowers the cost of finding memory-safety bugs, auth bypasses, and injection flaws in a public repo, and there's a real, ongoing industry conversation about whether that changes the open-source security calculus (see The Register's coverage of the broader debate). But the same argument applies to essentially every popular open-source project, and nobody else building scheduling, CRM, or booking software has made this move for this reason. Developer reaction, reflected in the Slashdot discussion thread that broke the story, was openly skeptical — the recurring line was some version of "AI is now the excuse for every decision a vendor already wanted to make."

Here's the part I think the coverage underweighted: AGPL-3.0's defining feature, the thing that separates it from plain GPL, is Section 13 — the network-use clause. Ordinary GPL only triggers your obligation to release source when you distribute the software. AGPL triggers it when you let users interact with it over a network, full stop, even if you never ship them a binary. That clause exists specifically to close the "SaaS loophole" that let companies run modified GPL code as a hosted service without ever releasing their changes.

Which means: as long as Cal.com's own hosted cloud product ran on the same AGPL codebase as the self-hosted version, Cal.com was on the hook, by the letter of its own license, to make the source of any modifications running on cal.com's servers available to users of that hosted service — including anything they built exclusively for the SaaS product and never intended to ship into the open self-hosted repo. That's a real constraint on how freely you can build cloud-exclusive, differentiated features without also handing the source to self-hosters and competitors. Relicensing the core to proprietary removes that constraint entirely, for the hosted product as much as for self-hosted deployments. The AI-security framing explains why now might have felt urgent to the company. It doesn't explain why the fix was "delete the copyleft obligation on our own cloud product," rather than, say, hardening the existing EE gate or improving patch cadence. The license mechanics do.

I want to be careful about what's verified here versus what's my read: the April 15 date, the MIT license on Cal.diy, the stripped /ee/ code, and the production-use warning are things I confirmed directly against the repository. The AGPL Section 13 argument is my own analysis of publicly documented license text applied to publicly documented facts about Cal.com's product structure — not a claim anyone at Cal.com has made. Treat it as an informed reading, not a quote.

This is a known playbook — and Cal.com just skipped a step

Relicensing-then-forking has a well-established arc at this point, and it's worth knowing the pattern because it predicts what usually happens next:

HashiCorp moved Terraform from MPL 2.0 to the Business Source License in August 2023. The community response was OpenTofu, a genuine fork adopted by the Linux Foundation with 40+ companies joining the consortium almost immediately. HashiCorp was acquired by IBM for $6.4B roughly eighteen months later.
Elastic relicensed Elasticsearch away from Apache 2.0 in 2021. AWS responded by forking it as OpenSearch, which is now its own healthy Linux Foundation project. Notably, Elastic reversed course and returned Elasticsearch to AGPL in August 2024 — the first (and so far only) major reversal in this pattern.
Redis dropped its BSD license for a source-available license in 2024. The community fork, Valkey, picked up backing from AWS, Google Cloud, Oracle, Ericsson, and the Linux Foundation and hit roughly 19.8K GitHub stars in its first year — genuinely fast adoption for an infrastructure fork. The more telling number: before the relicense, non-employees made 54% of Redis's commits; within a year afterward, no external contributor was making more than five commits. The community didn't just fork the code, it left.

Every one of those cases produced an independent, foundation-backed fork that could credibly compete with — or in Elastic's case, outlast — the original vendor's decision. Cal.com's situation is structurally different: there is no independent Cal.diy. Cal.com wrote it, Cal.com hosts it, and Cal.com's own README tells you not to run it in production. It's less "the community forked us" and more "we pre-forked ourselves and kept the keys." Whether that heads off a genuine Valkey-style community fork, or just delays one while goodwill drains the way it did for Redis, is the open question — and as of this writing there's no Linux Foundation-style independent fork of the pre-April Cal.com codebase, which is itself notable given how quickly that happened in the three precedent cases above.

Why this should matter to you even if you've never touched Cal.com

If you self-host Cal.com in production today: you're now running unsupported, unlicensed enterprise-tier code unless you buy the commercial license, or you're on a migration clock to Cal.diy (with Teams, Organizations, Insights, Workflows, and SSO/SAML gone) or to a different product entirely. Neither option is a same-day swap if you have booking pages embedded across a product.

If you use the hosted cal.com product: day-to-day, probably nothing changes immediately — but the guarantee that used to come with "this is AGPL, so if they ever do something you don't like, you can fork it and run it yourself" is gone. That guarantee was a real part of the pitch to security- and compliance-conscious teams evaluating scheduling vendors, and it no longer applies to the current codebase.

If you're evaluating any "open source" infrastructure vendor right now: this is the fourth major relicensing in roughly three years from a company that built its adoption on an open-source badge (after HashiCorp, Elastic, and Redis). The pattern is now common enough that "AGPL/MPL/BSD today" is not a reliable signal about tomorrow, especially for VC-backed companies under pressure to show a defensible moat against both cloud providers and, increasingly, AI code-generation tools that can replicate the client-facing surface of an app faster than ever. Read licenses as a snapshot of intent at funding-round time, not a permanent commitment.

Cost, concretely: per aggregated third-party pricing trackers (Cal.com doesn't publish enterprise pricing directly), the hosted product runs roughly free for individuals, around $12/seat/month for Teams, and around $28–30/seat/month for Organization/Enterprise tiers with SSO — those figures aren't from Cal.com's own pricing page directly and should be verified against cal.com's current pricing before budgeting, but they give a rough sense of what "enterprise-ready" now costs versus the self-hosted-for-free assumption a lot of adopters started with.

Practical use cases this actually breaks or complicates

Agencies and platforms embedding Cal.com's API into client products under the assumption of a stable, freely-licensed core now need to check whether their usage crosses into what requires a commercial license, and re-read the terms of the commercial license page rather than assuming the old AGPL terms still apply.
EU-based or data-residency-sensitive teams that specifically chose self-hosted Cal.com to keep booking data off a US-hosted SaaS now have to weigh a paid commercial license against migrating, since the AGPL "run it yourself, forever, for free" path only survives in the deliberately non-production Cal.diy fork.
Open-source-alternative directory maintainers and "awesome self-hosted" lists that still list Cal.com as a free Calendly alternative are, as of April 2026, describing Cal.diy's crippled feature set, not what most people mean when they recommend Cal.com.
Contributors who sent PRs into the AGPL Cal.com repository over the years contributed to code that's now partly proprietary — worth knowing if you were counting that work as a portfolio piece for "shipped a feature in a widely-used open-source project."

The migration math nobody advertises

Cal.com is a large monorepo — Next.js frontend, tRPC for the API layer, Prisma against Postgres, with a substantial app-store of third-party calendar and video integrations. That's not a criticism; it's a normal, well-built modern web stack. But it means "just self-host the fork instead" is not a low-effort swap for anyone who built real integrations against the AGPL version. If your booking flows depend on Teams, Organizations, Insights, Workflows, or SSO/SAML — the exact feature set that Cal.diy has physically deleted rather than merely locked — moving to the free fork isn't a downgrade in abstract terms, it's a rewrite of whatever depended on those features. And moving to the commercial license instead means absorbing per-seat SaaS-style pricing on infrastructure you'd previously budgeted as "free plus our own hosting costs."

That's the part that tends to get lost in "open source vendor goes closed source" coverage generally: the interesting damage isn't the philosophical betrayal, it's that a whole category of engineering decisions — "we can self-host this because it's free and AGPL, so worst case we fork it" — gets quietly invalidated after teams have already built architecture around that assumption. The AGPL's promise was specifically that this couldn't happen to you without your consent, because you'd always retain the source as it existed under that license. That's still technically true — nothing stops you from running the last AGPL-licensed commit forever — but you'd be running an unpatched, aging fork with zero vendor support, which is a very different proposition than "run the actively maintained open version."

Practical use cases this actually breaks or complicates

The framing in Cal.com's own posts is that Cal.diy is Cal.com "still supporting open source." What that undersells: Cal.diy isn't a snapshot of the old free tier with a new name. It's had Teams, Organizations, Insights, Workflows, and SSO/SAML removed outright, not just left unlicensed — meaning even if you're comfortable with "personal, non-production use," you're not getting the pre-April feature set for free anymore under any framing. There's also no stated commitment to security patch parity, LTS support, or how long Cal.diy will stay actively maintained relative to the commercial product — the standard risks of a vendor-maintained "community edition" that has no independent governance and no obligation to keep pace with the thing it was split from.

Where this leaves the competitive picture

The irony is that this move makes self-hosted Cal.com converge toward the exact model Calendly has run the whole time: closed-source, hosted, pay-per-seat, no self-hosting escape hatch worth relying on for anything you can't afford to lose. Cal.com's differentiator versus Calendly was never really the booking UI — it was "you can run this yourself and never be at our mercy." That's now true only for a version explicitly marked "don't use this for anything that matters." If you were choosing Cal.com specifically because it was self-hostable AGPL infrastructure — not because you preferred its UI to Calendly's — the honest comparison today is between Cal.com's commercial license and every other closed SaaS scheduling tool, not between Cal.com and "true" open alternatives, because that category of product just lost its most visible member.

Developer-focused scheduling still has a few genuinely open players — smaller, less feature-complete projects that haven't taken outside funding at a scale that creates pressure to relicense — but none with anything close to Cal.com's API surface, integration count, or name recognition. That's a meaningful gap: Cal.com's scale was precisely why it was the default recommendation, and scale is exactly what tends to precede a relicense in this pattern (MongoDB's 2018 move to SSPL, the largest database vendor doing it first, set the template that HashiCorp, Elastic, and Redis all later followed once they hit comparable scale). If you're evaluating a smaller open-source scheduling or booking tool as a Cal.com replacement specifically to avoid this risk, weigh maturity against exactly the kind of leverage-driven relicensing risk you're trying to avoid — a project without outside investors has less incentive to flip, but also fewer resources to match Cal.com's feature set today.

What the marketing (and most of the coverage) leaves out

My read

I don't think the AI-security explanation is false, exactly — I think it's incomplete in a way that's convenient for the company telling it. AI-assisted vulnerability scanning is real and is a real, industry-wide pressure on open-source maintainers generally, which makes it a plausible-sounding, hard-to-fact-check reason that also happens to justify a licensing change that independently solves Cal.com's AGPL network-use exposure on its own commercial cloud product. When a stated reason for a business decision applies equally to every open-source competitor who didn't make the same decision, and there's a separate, unstated mechanism that explains the specific choice made, I weight the unstated mechanism more heavily. That's a judgment call, not a fact I can hand you a citation for — form your own view of the license text and the timeline and see if you land somewhere different.

What is a fact: Cal.com is now the fourth notable infrastructure vendor in three years to relicense away from a permissive or copyleft open-source license after building its user base on that license, and unlike the three before it, its "community edition" ships with an explicit warning not to use it for anything real.

Who should adopt, wait, or walk away

Adopt the commercial Cal.com product if you already need enterprise features (SSO, Teams, Insights) and were going to pay for a hosted scheduling vendor anyway — you're not meaningfully worse off than choosing Calendly, and you get better API-first embedding.

Wait and audit if you're currently self-hosting the pre-April AGPL Cal.com in production. You have a live compliance and licensing question to resolve, not an abstract one — check what version you're running, whether it predates the license change, and what your actual obligations are under the commercial terms before your next security review flags it.

Consider Cal.diy only for what it's labeled for: personal projects, evaluation, learning the codebase. Don't put customer-facing booking flows behind it based on the assumption that it's "basically Cal.com but free" — per the maintainers' own warning, it isn't, and it isn't meant to be.

Watch, don't panic, if you're just a hosted-SaaS user. Nothing about your day-to-day booking experience changed this week. What changed is the insurance policy you had against Cal.com changing its mind about your data, your pricing, or its roadmap — that policy expired in April, quietly, for a product a lot of people picked specifically because they thought it hadn't.

Discussion: If you maintain or depend on an AGPL project with both a self-hosted and a hosted-SaaS deployment of the same code, have you actually audited whether Section 13's network-use clause is forcing you to open-source features you built exclusively for your cloud product — and if you found that it was, would relicensing be the fix you'd reach for, or would you restructure which code runs where instead?

Sources: