External booking engine — cal.diy evaluated, Cal.com self-host retained (license correction)

ADR-008: External booking engine — cal.diy evaluated, Cal.com self-host retained (license correction)

Status: Accepted Date: 2026-04-17 Deciders: Mishaal Murawala Supersedes (partial): ADR-001 licensing claim (Cal.com is MIT, not AGPLv3) Relates to: docs/prd/smart-scheduler-v5-implementation.md §4–§5 (Cal.com external-only)

Context

ADR-001 committed V5 to Microsoft Graph for internal scheduling and Cal.com self-hosted for external self-serve booking. Two new inputs triggered a revisit:

cal.diy surfaced as a potential free alternative to Cal.com self-host.
ADR-001 asserted Cal.com is AGPLv3. On re-verification against the upstream repo, the root LICENSE is MIT (verified 2026-04-17 at raw.githubusercontent.com/calcom/cal.com/main/LICENSE). No LICENSE-EE file exists at main. The original AGPL claim is stale — Cal.com consolidated to MIT.

This ADR records the verified licensing reality and the decision on cal.diy.

Decision

Reject cal.diy for V5 external booking.
Retain Cal.com self-hosted as the external booking engine per scheduler spec §4.
Correct ADR-001: Cal.com is MIT-licensed at the root, not AGPLv3. No copyleft/network obligations. Free for commercial production self-hosting.
Defer “build-in-house external booking” (Worker route + ICS + Graph write) as a tracked alternative — not now, but re-evaluate before Cal.com self-host deployment if ops cost of Postgres+Redis+Docker exceeds the V5 feature surface we need.

Licensing Analysis (Verified 2026-04-17)

cal.diy

License: MIT (per upstream).
Disqualifying self-declaration (from cal.diy homepage): “strictly recommended for personal, non-production use” and “Cal.diy is community maintained” — Cal.com Inc. explicitly steers commercial users to Cal.com.
Risk: shipping PFP portfolio-company bookings on a vendor-labeled non-production fork is an indefensible liability, regardless of what the MIT license technically permits.
Verdict: eliminated on vendor positioning, not on licensing.

Cal.com self-host (repo root)

License: MIT. Full text verified:

“Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the ‘Software’), to deal in the Software without restriction…”
No EE file at main. Historical Commons Clause / EE restrictions on packages/features/ee (SAML, managed teams, admin API) that existed in older versions no longer present as a separate license file at the repo root. If EE-gated restrictions exist deeper in the tree, they do not block the feature surface V5 actually uses (event types, bookings, webhooks, slots API).
Obligations for commercial SaaS use: trademark restriction on the “Cal.com” name only. No source-disclosure obligation on modifications. No AGPL network-clause trigger.
Verdict: licensing-clean for Ascend commercial production use.

Cal.com Cloud (paid SaaS)

Teams $12/user/mo, Organizations $28/user/mo, Enterprise custom.
Only relevant if we don’t self-host. Not the plan.

Cal.com Platform (programmatic booking-on-behalf-of-users API)

Separate managed product. Pricing gated (not on public pricing page).
Not needed for current V5 scope: external booking for PFP advisors is one-link-per-advisor, not white-label tenant-embedded booking. If/when V5 ever needs embedded multi-tenant booking, revisit.

Alternatives Considered

Option A — cal.diy (free, MIT community edition)

Rejected. Self-labeled non-production. Cal.com Inc. disclaims support and steers commercial users away. Shipping client-facing infrastructure on this is a reputational + reliability liability.

Option B — Cal.com Cloud paid

Rejected for default path. $12–28/user/mo scales with tenant user count; self-hosting at one worker + one DB is cheaper at even modest scale. Cloud free tier (1 user) remains the right testing target per scheduler spec §4 Deployment Note.

Option C — Cal.com Platform API (managed, gated pricing)

Rejected for current scope. Overkill for one-link-per-advisor external booking. Revisit only if we need embedded white-label booking across multiple tenant brands.

Option D — Build external booking directly into V5 Worker

Deferred (tracked, not chosen now). A public /book/:tenant/:advisor Worker route reading availability from Microsoft Graph + writing the event back via Graph + returning ICS would eliminate the Cal.com ops footprint entirely (no Docker, no Postgres, no Redis, no separate domain).

Why not now: Cal.com gives us event-type management, buffer times, round-robin, cancellation/reschedule UX, webhooks, and a public booking UI for free. Rebuilding that surface is multi-week work.
When to revisit: if PFP pilot reveals we use <20% of Cal.com’s feature surface AND the Postgres+Redis ops cost becomes a drag, spike Option D in a branch.

Consequences

Positive

Licensing reality corrected in writing; no surprise AGPL exposure claim in future audits.
cal.diy formally eliminated with reasoning, so it doesn’t resurface.
Option D is documented as a real fallback rather than a vague “we could just build it ourselves.”

Negative

No cost savings vs. prior plan — we were already on Cal.com self-host.
Ops burden of self-host (Postgres, Redis, Docker, domain, TLS) still applies before PFP pilot.

Follow-ups (actionable)

Update ADR-001 line 22: strike “AGPLv3” → replace with “MIT” and link this ADR.
Before PFP pilot deployment of Cal.com self-host, confirm that no feature V5 depends on lives in an EE-restricted path (spot-check: event-types API, webhooks, slots, bookings v2 — all non-EE per current upstream).
Add a one-line note to smart-scheduler-v5-implementation.md §5 noting Cal.com license status.

References

Cal.com LICENSE (MIT, verified raw): https://raw.githubusercontent.com/calcom/cal.com/main/LICENSE
cal.diy homepage self-disclaimer: https://www.cal.diy/
Cal.com Cloud pricing: https://cal.com/pricing
V5 scheduler spec: docs/prd/smart-scheduler-v5-implementation.md §4–§5
Prior ADR: docs/decisions/ADR-001-graph-first-scheduling.md