Gotcha. That’s very helpful.
Increasing the headcount threshold from 25 to 50 seems to genuinely be a concession made based on community feedback. However, I do see in the draft PRs for the v12 license enforcement system (#27173-#27180) that this architecture has been in development for months. The grace-period popup in the code dates the registration initiative back to at least October 2025. Moreover, you made a comment earlier in this thread about this being discussed internally for a year. Not much has changed over the last few weeks, in that case.
I do have some questions that may help to clarify the grant and licensing conditions a bit more.
You describe registration and telemetry as the “ONLY” requirements for the OIG grant, but the enforcement code shows that every installation validates its license against a remote service every 6 hours by default. Moreover, a report is sent on every validation call that includes the:
-
project id
-
public url
-
database client
-
user count by type
-
role counts
-
flow counts
-
dashboard counts
-
extension counts
-
collection counts
-
total item counts
-
share counts
-
file counts
-
fields per collection
-
database size in bytes
-
file storage size in bytes
-
MCP config
-
collaborative editing status
-
websocket status
-
visual editor URLs
-
and per-method API request counts broken down by type with totals and cache hits
Whew! That’s a lot. In fact, it’s the complete commercial profile of a deployment. I wonder if it is a bit disingenuous to call this “basic telemetry.”
Do you have a data retention policy for this information? Who will have access to it? Will it be stored on infrastructure controlled by Monospace? Will it be used for purposes beyond license validation, such as sales targeting, pricing optimization, or identifying high-usage deployments for enterprise outreach? Will it be shared with investors or third parties? Will the data flow be documented in a privacy policy, DPA, or somewhere else?
It appears that the entitlement to disable analytics only exists in the Enterprise tier. Can you confirm this?
For self-hosted software running on the user’s own infrastructure, managing the user’s own data, can you explain why the 6-hour validation frequency is necessary? What happens to a deployment that loses connectivity to the validation service for 24 hours or a week?
Air-gapped and offline operation requires the Enterprise tier based on what I’m seeing. Does this mean that organizations behind strict firewalls or in environments with unreliable internet must pay Enterprise pricing to run Directus reliably?
Does the OIG grant expire? If so, how often must it be renewed and what is the renewal process?
The licensing architecture supports entitlement overrides such that the licensing server can change an individual installation’s limits between validation cycles without any action or code change on the user’s end. Under what circumstances would Monospace need to selectively change limits for individual customers? Will users be notified when their entitlements are changed remotely?
If the JWKS endpoint rotates its signing key, then any Directus instance running an older version will fail token verification once its cached JWKS expires. At that point the installation can no longer validate even if the license itself is valid and paid for. So this gives Monospace the ability to force version upgrades by rotating signing keys. Is there a planned key rotation policy?
When a paid license lapses, the install transitions to locked immediately and non-admin users are kicked out until an admin completes the deactivation workflow. What’s the rationale for an immediate lock rather than a softer transition window where existing users retain read-only access, for example, while the admin decides how to bring the install into Core compliance?
The grace-period popup links to a URL containing the acronym KYC (Know Your Customer). I am unfamiliar with the use of this phrase outside of regulated banking and financial environments. I’m curious if this is how Directus internally describes the registration system, and if so, how it applies in the context of “basic registration”?
Is there a reason a community RFC wasn’t provided for such consequential architecture before reaching draft-PR stage?
If this is out of scope for this thread, I’m happy to post these questions in a new thread. Thanks so much for any insights.