Directus License Revision: Community Feedback Requested

Hello Directus community!

I wanted to give you all a quick heads up on an upcoming software license revision we’re planning to roll out in the next month or so. As always, keeping the community involved matters to us… so we’d love one final gut check before it goes live.

For a bit of context, Directus was released as open source under GPLv3 back in 2011. About three years ago, we moved to BSL 1.1 with an additional usage grant that allows anyone under $5M/year in total finances to use Directus for free.

The goal was simple… keep Directus open and accessible for the vast majority of our community, while making the project financially sustainable.

In practice, embedding that grant directly into the license got messy… especially around definitions like “total finances” and “production use.” This is where we landed:

“You may use the Licensed Work in production as long as your Total Finances do not exceed US $5,000,000 for the most recent 12-month period … ‘Total Finances’ mean the largest of your aggregate gross revenues, entire budget, and/or funding (no matter the source); ‘you’ and ‘your’ include (without limitation) any individual or entity agreeing to these terms and any affiliates of such individual or entity; and ‘production’ mean any use other than (i) development of (including evaluation of the Licensed Work), debugging, or testing your offerings, or (ii) making the Licensed Work available standalone in unmodified object code form.”

(Ugh… yeah.)

We’ve received a lot of valid feedback over the past few years that this structure is unclear and overly complex… and we agree.

So this update is really about restructuring what already exists to make it more clear and consistent… moving from a combined BSL + Grant model to two distinct pieces:

  • MSCL (Monospace Sustainable Core License), a custom license based on the Fair Core License, which fully converts to GPL after 4 years.

  • Innovation Grant, a separate grant that preserves free usage for individuals and smaller organizations (under $5M in annual revenue and under 25 headcount).

Additionally, our current license has largely operated on an honor system. For the most part, that’s worked well… but there have been cases (particularly with some larger enterprises) where it’s been unintentionally or deliberately overlooked.

To address this, we’re introducing self-service registration keys for paid customers and grant users. This removes ambiguity and helps ensure everyone is operating fairly.

One of the reasons we used the Fair Core License as a starting point is because it includes protections to preserve the integrity of the registration system for commercial use. At the same time, we feel strongly about the code eventually converting to GPL (which FCL doesn’t allow)… which led us to craft our own license (MSCL). :flexed_biceps:

This isn’t a change in direction… it’s an evolution based on a few years of real-world usage and community feedback, with the goal of making things clearer and more predictable for everyone.

I’m excited about this… and wanted to bring you all in before we finalize it.

As always, if you have reactions, concerns, weird edge cases, or anything else… I’d genuinely love to hear it!

Thank you,

// Ben (and Rijk)

5 Likes

Thanks Ben, I’m very excited to share this journey with you. What are your thoughts on Educational institutions and non-profits? Most will have less than $5M annual revenue but still have over 25 headcount, especially if we count students or volunteers.

1 Like

agreed to this point head count should be increased

Quick clarification on the Innovation Grant’s headcount criterion (under 25): does this refer strictly to the licensee’s own employees/contractors, or could it in any way extend to end users in a multi-tenant SaaS deployment? We’re a small SaaS startup self-hosting Directus on behalf of our customers (multi-tenant).

2 Likes

Huge red flag for me.

The BSL 1.1 was at least a known, reviewed license. A custom “Monospace Sustainable Core License” is untested, hasn’t been reviewed by the broader open source community, and gives Directus maximum flexibility to redefine terms at any point… I could never responsibly recommend a platform to my clients when the licensing terms could change underneath them after delivery. Not just a risk for them, it’s my own reputation at stake. You’re losing an entire channel of potential adopters with something like this.

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.

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’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.

6 Likes

This feels like an excuse to start paywalling features behind a commercial license. It also feels like something that will only affect tiny businesses that are self-hosting Directus for free, and who are likeIy to be forced to pay to access “enterprise features” in the future.

The SME-friendly license has always been a distinguishing, reassuring feature of Directus. It’s truly sad to see it being taken away.

3 Likes

Besides what other people have said, I want to ask a question: why was a licence change needed, exactly? Are the core contributors/employees not happy? Is the core team/company struggling financially? What is going to be the destination of the extra projected income (implied by statements such as “but there have been cases (particularly with some larger enterprises) where it’s been unintentionally or deliberately overlooked”)?

I have loved working with Directus. It is an incredible project. I was getting ready to pitch to the “board” of my organization (not a company) donating to the Directus core team. But this makes me think twice.

Especially since, as per Directus’s website, there have been at least five venture capitalist funds pouring money into Directus. And we all know what that means: they will ask for their money back (plus some more…).

3 Likes

filipe,

The companies that invent their own licenses are typically VC-backed and trying to thread a needle between “we want to look open source to appease our community” and “we need to capture revenue our investors expect.” Existing licenses don’t do exactly what they want (meaning existing licenses don’t let them restrict usage in the specific way their business model requires), so they write their own. And every single time, the custom license is more restrictive than what it replaced, never less. Regardless of how Ben spins it.

The thing is, the companies that created licenses that actually got adopted broadly (like MariaDB with BSL, Sentry with FSL) had those licenses drafted by established open source attorneys like Heather Meeker and submitted them for community review. The licenses were designed to be reusable across projects, not bespoke to one company’s needs.

So the MSCL is not that. The name itself tells you it’s not intended as a community standard. It’s a proprietary legal instrument wearing open source clothing. It exists to serve Monospace Inc’s interests and nobody else’s.

So about your question, why was a license change needed? I know exactly what you’re getting at, and I think the writing is on the wall. The BSL they’re already using converts to GPL… that’s its whole design. If GPL conversion was the only goal, they could just stay on the BSL and refine the usage grant. They don’t need a new license for GPL conversion.

What the BSL doesn’t have that the FCL does is the license key enforcement mechanism and the non-compete clause. The GPL conversion isn’t the reason for the new license, it’s just the justification for the new license. It’s the part that sounds good while the parts that actually matter (non-compete, software-enforced feature gating) get smuggled in underneath.

Just trying to make sense of this myself. Curious to see what the team’s take is.

1 Like

I’ll say this. If this project moves away from open source, like this change does, I will reccomend that we migrate away to my team. If it stays on the current licence I will (just as I was doing) continue developing, open sourcing extensions, recommending to other people, and donating. I am even willing to be included in the paid tier, depending on pricing. I am all for paying people a fair wage. I am not for being lured into a (great!) tool and then having the licence changed.

I challenge the Directus team: if you want to “democratize data” like you state in big bold letters on your page, then be transparent. How much money are you making, and how much money do you need? And how much money do you want?

EDIT: Just two years ago the team was talking about “200% growth (3x) in annual recurring revenue”. How much money is does this project need to be sustainable?

2 Likes

Same. I am all for supporting good software, both financially and in terms of development.

The “honor system” problem isn’t really solved by this. The forced registration accomplishes two things: it creates a legal record, and it builds a user database.

So if Monospace discovers that a company lied on the attestation, they have a signed document to use in a legal proceeding. Plus every self-hosted instance phones home with an organization name, contact email, and size attestation. So now Monospace has a directory of every organization using their software, what size they “say” they are, and how to contact them. So when a company that registered at under 25 headcount posts a job listing saying they have 26 employees, Directus enterprise sales team can reach out. When a company raises a Series B that gets announced on TechCrunch, Directus can check the registry and send an invoice.

Based on experience, I really don’t think the registration system solves the problem Ben described (companies freeloading and denying it). An enterprise that’s willing to freeload and deny it will simply find a way to bypass registration with false information or not register at all. Small teams and organizations will be disproportionately affected by this change, as icouto suggested.

I work with some small government contractors who operate in environments with strict data governance and network security requirements. A self-hosted tool that phones home with organizational details to a third-party vendor is a non-starter in those environments. The whole point of self-hosting for these organizations is that nothing leaves their network. Forced registration turns a self-hosted product into a product with a SaaS dependency, which is exactly what these users were trying to avoid by self-hosting in the first place.

2 Likes

The concern for me isn’t the thresholds, it’s predictability. As a small SaaS startup building on Directus, I’m not trying to avoid paying. When we reach the scale where a commercial license makes sense, we’ll pay it. Frustrating if some enterprises are currently not paying.

But the combination of a custom, unreviewed license and mandatory registration keys makes it harder to confidently build a long-term product on this foundation. Potentially having some features behind a paywall is scary too.

The BSL had a community behind it. A bespoke license means the terms are whatever Monospace decides they are, now and in future revisions. That’s a different kind of risk than the financial thresholds themselves.

Most importantly: Publishing the actual MSCL text before asking for feedback would go a long way here. It’s hard to evaluate a structure without seeing the language. You’re just saying it’s ”better”.

Carwei and others building “small” SaaS products on Directus: Ben posted a detailed response on a Reddit thread about this announcement that included specifics on feature gating. Two items in particular that anyone building multi-tenant applications should be aware of:

  • Custom RBAC filters will be gated to paid tiers. I’m sure you’re aware, but this is the mechanism you’d use to scope data per-tenant.
  • Additionally, seats and collections will be capped in the free tier.

So they’re knee-capping any meaningful implementation of multi-tenant architecture.

These details were not in the original announcement. They were mentioned in a single sentence on Reddit, buried in a much longer post emphasizing how everything is :clap: free :clap: with the Innovation Grant.

I would link to the thread directly but I’m not sure if it’s against forum rules. Search Reddit for the announcement title and you’ll find it.

Wow, I didn’t know any of that. That’s a massive change from just a few years ago, based on direct dialogue with Directus sales. Back then they happily supported SaaS startups, just encouraged a paid license for support response times etc. when possible.

This is exactly what I ment about predictability being the big risk. Thanks for the heads-up. The unknowns are adding up… :confused:

Of course! I really appreciate you joining in.

Regarding non-profits, NGOs, research orgs, open source projects, universities, and educational institutions… any thoughts on how those should be handled? I’ve seen common practice is to mention contacting sales to discuss discounts.

We have always, and would continue to offer those discounts.

But I do worry about adding a sweeping free grant for all those groups regardless of size/scale/project. I’m also not sure how much current/future revenue we’d instantly lose by doing so.

To me, these large enterprise-like orgs (such as American Red Cross, WWF, Wikimedia, Kubernetes, Mozilla, MIT, Harvard, etc) feel more like deep discounts than all-out free usage. But curious what you think.

Maybe we can look into formalizing discounts or partial grants for these? Or do you think it’s more about playing with the 25 headcount??

1 Like

What are you thinking it gets increased to? And could you share some reasoning for how you come to any numbers?

Thanks!!

1 Like

Also, we would of course clarify this in the T&Cs of the grant, but headcount is the formal employee/team. This would not include volunteers or students of EDUs… the same way that it wouldn’t include external clients or “end users” of a company.

1 Like

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…

  1. Keep the source available for trust, auditability, extensibility, and public visibility
  2. Allow for license key enforcement that legally cannot be removed
  3. Avoid environment-based (dev/prod) ambiguity
  4. Allow non-competitive forks to be used/resold
  5. Remove the ambiguity of who needs to reach out for a license and when
  6. Convert to OSS after 4 years, and to GPLv3 (not MIT)

I hope all of this helps! Happy to dive deeper…

1 Like

Well, yeah. But doesn’t it matter what is being paywalled? The features we’re gating are things like SCIM, Offline Mode, Annual Invoicing, and Paid Support.

We’re not hiding the fact that we feel that big enterprises should be paying for this project, so that individuals, hobbyists, and small orgs can keep using it for free.

Without assuming what’s being taken away… what is your concern here? What questions can I answer?

1 Like

Appreciate the feedback and questions. Let me dive in (pardon the copy/paste for the answers I’ve made elsewhere).

why was a licence change needed, exactly?

Answered here:

Are the core contributors/employees not happy? Is the core team/company struggling financially?

Our team is happy and we are not financially struggling. But the same way we optimize the code to be efficient, we are restructuring our license to be more clear (based on feedback that it is not, as I mentioned in my OP).

What is going to be the destination of the extra projected income (implied by statements such as “but there have been cases (particularly with some larger enterprises) where it’s been unintentionally or deliberately overlooked”)?

This is an extreme example, but let me say it to illustrate a point.

You run a small convenience store, and your employees are happy and business is going well… but you have a non-trivial number of people who take things from your store without paying. Sometimes they say it’s because your signs/price-tags aren’t very clear, and other people do it because they aren’t being honest.

Doesn’t it make sense to update your signs/price-tags to be more clear (our license change), and maybe install one of those RFID checkers at the door (our registration keys)? If no one is stealing, then nothing changes.

I have loved working with Directus. It is an incredible project.

Thanks!

I was getting ready to pitch to the “board” of my organization (not a company) donating to the Directus core team. But this makes me think twice.

Ok, happy to answer any questions making you worried about this.

Especially since, as per Directus’s website, there have been at least five venture capitalist funds pouring money into Directus. And we all know what that means: they will ask for their money back (plus some more…).

Our investors aren’t building the software and they don’t make decisions for the company. They all understand OSS (have invested heavily in this category) and trust us. We’ve already grown the company a LOT since their investments, so they already have their financial returns.

Importantly, they can not “ask for their money back”… UNLESS we fail in general as a business (run out of money). That’s exactly why we’re making these changes… to keep things growing and sustainable.

2 Likes

“we want to look open source to appease our community” and “we need to capture revenue our investors expect.”

The thing is, the companies that created licenses that actually got adopted broadly (like MariaDB with BSL, Sentry with FSL) had those licenses drafted by established open source attorneys like Heather Meeker and submitted them for community review. The licenses were designed to be reusable across projects, not bespoke to one company’s needs.

We are NOT trying to “look” OSS. It’s been a proprietary license for the past 3 years.

What we’re trying to do is honor the OSS ethos, with something that actually works. I worked on our licenses directly with Bruce Perens (the co-founder of open source and the OSI) as well as several SME software license attorneys.

We’re trying to continue to honor that with a Grant that continues to give our software away for free to almost ALL of our users. We’re doing something novel that doesn’t fit with existing licenses, and are writing something that works well for that goal.

Try to understand that there is a lot of gray between pure OSS/MIT and paid closed-source enterprise software.

Existing licenses don’t do exactly what they want (meaning existing licenses don’t let them restrict usage in the specific way their business model requires), so they write their own. And every single time, the custom license is more restrictive than what it replaced, never less. Regardless of how Ben spins it.

I’m trying really hard to explain our thinking. It’s unfortunate that you can only see this as a “spin” and not our best attempt to build something premium but sustainable.

Do you have any recommendations or constructive thoughts here? Did you read my comments on WHY this change is happening? Offer some suggestions that solve those problems.

So the MSCL is not that. The name itself tells you it’s not intended as a community standard. It’s a proprietary legal instrument wearing open source clothing. It exists to serve Monospace Inc’s interests and nobody else’s.

Nothing is a standard… until it is. It seems like I’m wasting my breath trying to speak with you about this, since you don’t seek to understand what/why we’re doing things… but are comfortable saying we’re only serving our own interests and no one else’s.

That’s your honest opinion? That our free grant for almost all users, our free tier, being source available, source convert to true OSS… it’s all just a big marketing ploy?

So about your question, why was a license change needed? I know exactly what you’re getting at, and I think the writing is on the wall. The BSL they’re already using converts to GPL… that’s its whole design. If GPL conversion was the only goal, they could just stay on the BSL and refine the usage grant. They don’t need a new license for GPL conversion.

Maybe read this and then let me know if you still think that…

What the BSL doesn’t have that the FCL does is the license key enforcement mechanism and the non-compete clause. The GPL conversion isn’t the reason for the new license, it’s just the justification for the new license. It’s the part that sounds good while the parts that actually matter (non-compete, software-enforced feature gating) get smuggled in underneath.

No smuggling. I can’t be more clear here.

YES. Protecting the registration key system is one of the MAIN reasons for this change. That’s why we had to move away from BSL, since it does’t protect that.

So if none of the “standard” licenses that are out there work for these requirements… what are we to do except create one that does?

1 Like