Let me respond to each of these points individually:
A custom “Monospace Sustainable Core License” is untested, hasn’t been reviewed by the broader open source community…
But that’s how all licenses start, including BSL or GPL. It doesn’t make it better or worse, just new. We based it on FCL so users/companies have a known starting point to understand from.
I could never responsibly recommend a platform to my clients when the licensing terms could change underneath them after delivery
This can happen with literally ANY software at any time. The copyright holder can change licenses, even from OSS to closed, at any point. What is different about Directus here?
The addition of a headcount requirement on top of the financial threshold, plus mandatory registration keys, signals a trajectory toward more control and more enforcement mechanisms, not toward providing enough value that users willingly pay for premium features or services. That’s the wrong direction.
Let’s me break this down… reversing your two points:
1. “…provide enough value that users willingly pay for premium features or services”
We do that ever day. We’ve built a LOT of premium features, services, and value. The problem is there is no way to enforce people paying for them. We currently only have an honor system… and as I said, some people exploit this. Soooo…. (see next point)
2. “The addition of a headcount requirement on top of the financial threshold, plus mandatory registration keys, signals a trajectory toward more control and more enforcement mechanisms”
We’re adding gates for some of these very enterprise-y features (SCIM, Invoicing, Offline Mode). And then adding software registration so we can make sure people are behaving fairly.
I’ve built multiple production projects on Directus specifically because of the open, self-hosted model. This kind of change forces me to evaluate whether I can responsibly build future projects on a platform where the licensing terms are a moving target.
I hear ya… but what’s actually changing for you in this case? Still source available, still self-hosted, same features you’re using today, and (presumably) still free for you. And moving to a very comparable license that still converts to OSS after a few years.
Could you let me know what part is giving you the most concern?
I’d genuinely like to hear the team address why a custom license was necessary rather than iterating on the existing BSL, and what guarantees exist that the Innovation Grant terms won’t narrow further in subsequent revisions.
Sure! Here are the things we needed to address:
Why BSL did NOT work…
- it relies on an honor system that does not hold up at scale
- it makes license key enforcement legally removable
- it blocks monetization of development use
- it introduces ambiguity around “production” and “non-production”
Why FCL did NOT work…
- it requires MIT conversion after 2 years
- it blocks making the software available to others in a commercial product/service
Why MSCL…
- Keep the source available for trust, auditability, extensibility, and public visibility
- Allow for license key enforcement that legally cannot be removed
- Avoid environment-based (dev/prod) ambiguity
- Allow non-competitive forks to be used/resold
- Remove the ambiguity of who needs to reach out for a license and when
- Convert to OSS after 4 years, and to GPLv3 (not MIT)
I hope all of this helps! Happy to dive deeper…