Evolving ArangoDB's Licensing Model for a Sustainable Future(arangodb.com)
arangodb.com
Evolving ArangoDB's Licensing Model for a Sustainable Future
https://arangodb.com/2023/10/evolving-arangodbs-licensing-model-for-a-sustainable-future/
58 comments
> Our commitment to jumping on the "screw you" licensing train means we can't even be bothered to use the SPX licensing identifier for BuSL correctly
And, to save others the click, they're using the "4 year cliff" version
And, to save others the click, they're using the "4 year cliff" version
> we can't even be bothered to use the SPX licensing identifier for BuSL correctly
Not taking a side on this, but just for historical context: the business source license was originally created by MariaDB, who referred to it as "BSL" and continue to do so [1]. So in the database world, calling it "BSL" is not especially unusual.
If I understand correctly, SPDX already assigned BSL as the short-code for the Boost Software License, so they assigned BuSL to the Business Source License.
Although the Boost Software License has been around since 2003, aside from Boost using it (obviously) it doesn't seem to be a popular choice among other projects.
So adopters of the Business Source License then have to choose between agreeing with the license's creators vs agreeing with SPDX.
[1] https://mariadb.com/bsl-faq-mariadb/
Not taking a side on this, but just for historical context: the business source license was originally created by MariaDB, who referred to it as "BSL" and continue to do so [1]. So in the database world, calling it "BSL" is not especially unusual.
If I understand correctly, SPDX already assigned BSL as the short-code for the Boost Software License, so they assigned BuSL to the Business Source License.
Although the Boost Software License has been around since 2003, aside from Boost using it (obviously) it doesn't seem to be a popular choice among other projects.
So adopters of the Business Source License then have to choose between agreeing with the license's creators vs agreeing with SPDX.
[1] https://mariadb.com/bsl-faq-mariadb/
The reason why more and more projects have to do that, is pretty much AWS. Most open source projects had managed services as an income stream for development, and AWS destroyed that while not giving back a single cent.
So yeah, the real dragon here is Amazon in my opinion. The projects don't have a choice. It's either BSL/AGPL or dead project.
In the world of enterprise, nobody is gonna introduce a new hosting provider if they already have all the ISO audits for AWS or Azure.
So yeah, the real dragon here is Amazon in my opinion. The projects don't have a choice. It's either BSL/AGPL or dead project.
In the world of enterprise, nobody is gonna introduce a new hosting provider if they already have all the ISO audits for AWS or Azure.
Does AWS even offer any arrangodb related services? I wasn't aware. This seems more like a preemptive move by investors to prevent such a thing ever happening. Which, congratulations, they just managed to do. But they might have thrown the baby away with the bathwater.
I just looked at their repo and it seems pretty popular. However, all the top contributors seem to be based in Cologne, Germany. I guess the headquarters are there. Not a lot of outside contributions happening either. I.e. not a very vibrant/healthy oss community around this product. I don't think AWS even has an office there. So I take the lack of their involvement and interest as a given here. But please correct me if I'm wrong. This also makes a fork unlikely. There's a distinct lack of any external stakeholders here. Short of the original developers leaving and forking, that's just unlikely to happen.
I just looked at their repo and it seems pretty popular. However, all the top contributors seem to be based in Cologne, Germany. I guess the headquarters are there. Not a lot of outside contributions happening either. I.e. not a very vibrant/healthy oss community around this product. I don't think AWS even has an office there. So I take the lack of their involvement and interest as a given here. But please correct me if I'm wrong. This also makes a fork unlikely. There's a distinct lack of any external stakeholders here. Short of the original developers leaving and forking, that's just unlikely to happen.
You have some goos points there that I cannot deny. I just know ArangoDB because they were advertising their project on German dev meetups when it was very young as an alternative to all the NoSQL hyped databases that turned out to have some serious limitations.
Their market seems to be the multi-model database market, where you also can run queries on the database without needing hacky "documents as views". They are also a somewhat alternative to neo4j, so I guess the graph database purpose is also there.
Whether or not they can be scaled on the same level, like you implied, especially with the necessary tooling for replication, synchronization and balancing ... is a whole other question.
Maybe someone that uses ArangoDB in production can chime in?
Their market seems to be the multi-model database market, where you also can run queries on the database without needing hacky "documents as views". They are also a somewhat alternative to neo4j, so I guess the graph database purpose is also there.
Whether or not they can be scaled on the same level, like you implied, especially with the necessary tooling for replication, synchronization and balancing ... is a whole other question.
Maybe someone that uses ArangoDB in production can chime in?
We're using it in production, both their cloud-hosted offering and for our on-prem software products. Massive scale isn't really a requirement for us but the multi-model capabilities are a winner for our use cases - being able to mix graph and relational-style queries in the same query language.
A problem for us is the Enterprise licensing is implemented such that our on-prem customers would have to manually update a license string once a year, which is a PITA and why we have previously been using Community edition despite paying for Enterprise (mostly for the support contract).
A problem for us is the Enterprise licensing is implemented such that our on-prem customers would have to manually update a license string once a year, which is a PITA and why we have previously been using Community edition despite paying for Enterprise (mostly for the support contract).
I think Macrometa was created from a fork of the project. A lot of their open source code used to contain references to ArangoDB which were search-and-replaced if you go back enough in their git history: https://www.macrometa.com/
I'd suspect this is less about the biggest players like AWS and Azure and more about the intermediate space that seems to be highly competitive.
I'd suspect this is less about the biggest players like AWS and Azure and more about the intermediate space that seems to be highly competitive.
> It's either BSL/AGPL or dead project.
AGPL is an infinitely better choice than BSL. Nobody would have been upset had they switched to that instead.
AGPL is an infinitely better choice than BSL. Nobody would have been upset had they switched to that instead.
I may be in a minority of one, but I consider it disingenuous for companies to use GPL/AGPL to drive people towards commercial licenses. BUSL is at least honest about what's going on.
How is it disingenuous? With GPL/AGPL it's actually FOSS. With BUSL it's not. If anything is disingenuous, it's the latter.
The result is the same so it's misleading that one is technically Open Source™ and the other is not.
How is the result the same?
this aws scapegoat keeps getting worse with no real merit behind it
Except with BSL it will still be available as an open source software at some point in the future. This is certainly better than moving to a non-free-and-will-never-be kind of license.
However, the way they've also changed “community edition” builds to forbid commercial usage is kinda fucked up.
However, the way they've also changed “community edition” builds to forbid commercial usage is kinda fucked up.
Sure, someday then-obsolete versions will slowly become FOSS, but they aren't for a long time.
countless instances of 4 year old software are running in critical roles. if it's so good, then a community can take on the burden of backporting fixes and/or watching for CVEs for 4 years.
it's not a long time. it's inconvenient, for sure.
it's not a long time. it's inconvenient, for sure.
They can't backport fixes or look at the newer code for help because that newer code isn't open source yet. It's true that a community that really wanted to could start implementing their own bug fixes, but I wouldn't hold my breath.
What is your best suggestion to keep them in business then?
Two options:
* Stay open source, switch to AGPL so AWS/Google won't use it
* Stop being open source, but just say that's what you're doing instead of this dishonest "we <3 open source (just kidding we're not actually doing pen source)"
* Stay open source, switch to AGPL so AWS/Google won't use it
* Stop being open source, but just say that's what you're doing instead of this dishonest "we <3 open source (just kidding we're not actually doing pen source)"
last I checked neither of those would touch GPLv3 either.
IMO, companies should go source available by default instead of bait and switch FOSS. If your business model isn't compatible with FOSS (which I would argue most aren't), don't do it.
I think being honest with your intentions up front has value, and you can charge for your software in a way that doesn't create a financial cliff when converting from free to paid (make up margins with volume etc).
I hope the rest of the ecosystem starts to feel this way and becomes comfortable paying for software again, especially from a sustainability perspective.
I think being honest with your intentions up front has value, and you can charge for your software in a way that doesn't create a financial cliff when converting from free to paid (make up margins with volume etc).
I hope the rest of the ecosystem starts to feel this way and becomes comfortable paying for software again, especially from a sustainability perspective.
Newer startups will probably be BUSL from day one. What we're seeing now are ZIRP startups reaching the limits of their old "open-source it and they will come" strategy.
I don't think so - many of these applications would never have reached the size and popularity they did as closed source or source available. We'll probably see more "open source for the growth, slam shut to monetise easier", but I think each one that does so will reduce trust in all such software, so I'd expect ultimately it will lead to companies either picking "definitely proprietary but with known terms" or "full on open source, controlled by a foundation" and avoiding this company=project middle ground.
Many of them also raised tens of millions (or more) in VC funding, which helped them achieve their size and popularity.
In a post-ZIRP world, many public tech company valuations have been slashed, and tech IPOs have slowed. Not-yet-profitable private tech companies can struggle to raise funding rounds now at favorable valuations, compared to their last funding round. If you're a VC-funded open source company with no deep moat, this is not a good time. I agree with the GP, we'll likely see more new companies choosing non-open-source but still source-available (e.g. BSL or SSPL) from the start.
In a post-ZIRP world, many public tech company valuations have been slashed, and tech IPOs have slowed. Not-yet-profitable private tech companies can struggle to raise funding rounds now at favorable valuations, compared to their last funding round. If you're a VC-funded open source company with no deep moat, this is not a good time. I agree with the GP, we'll likely see more new companies choosing non-open-source but still source-available (e.g. BSL or SSPL) from the start.
You don't need it to be controlled by a foundation to prevent this kind of bait and switch. You just need a copyleft license and willingness to accept external contributions without a CLA.
Good luck getting VC money that way though.
What’s ZIRP mean?
https://en.wikipedia.org/wiki/Zero_interest-rate_policy
I guess they mean startups funded during the past few years when US VCs were awash with cash.
I guess they mean startups funded during the past few years when US VCs were awash with cash.
Zero Interest Rate Policy
[deleted]
ArangoDb Series B Funding
https://arangodb.com/2021/10/announcing-arangodb-series-b-fu...
I don’t think that Venture Capital and open source companies mix. The monetization at the scale needed for venture capital is just not there.
To clarify, a venture backed company can use, make, and release open source, but open source should not be the source of its revenue.
https://arangodb.com/2021/10/announcing-arangodb-series-b-fu...
I don’t think that Venture Capital and open source companies mix. The monetization at the scale needed for venture capital is just not there.
To clarify, a venture backed company can use, make, and release open source, but open source should not be the source of its revenue.
Given my history I'm definitely not a fan of this madness in the licensing space. But I am also willing to acknowledge that the 1P vs 3P bomb set off by the public cloud incumbents will continue to yield damage to the open source startup ecosystem until something changes.
AWS is the actual villain here. They are the one abusing open source work while giving nothing in return.
We can all keep blabbering that it's not open source anymore, and blah blah, but the reality is that development of such systems is incredibly time consuming, and costs real money. Providing hosted solutions and offering some sirt of consultancy are the only 2 realistic income streams for the people who actually have built 99% of that.
Companies like Amazon destroy this because of their greed.
We can all keep blabbering that it's not open source anymore, and blah blah, but the reality is that development of such systems is incredibly time consuming, and costs real money. Providing hosted solutions and offering some sirt of consultancy are the only 2 realistic income streams for the people who actually have built 99% of that.
Companies like Amazon destroy this because of their greed.
This is FUD. It was FUD when this argument was introduced by a scummy marketing company with product they call a database, and it remains FUD in this case also.
1. AWS never provided a hosted Mongo instance. You know who did? Small startups that provided better support than MongoDB Inc., without the scummy "just dump money into MongoDB Atlas! It will solve all your problems! I promise!" spiel that the marketing company in disguise shoved down its customers' throats (even paying customers).
MongoDB Inc. went around buying out these startups for cents on the dollar right before they publicly announced the license change.
2. AWS did provide a hosted ElasticSearch service. And they did contribute code in return. Amazon's patches to ES included oft-requested security features that ES upstream flat out refused to merge because that'd harm ES corporate's monetization strategy of demanding money for basic security. ES community edition was not a good citizen of the Open Source world.
3. You don't hear this kind of FUD from the PostgreSQL community. Because that is an actually Open Source project with a really good community. Amazon participates in it as a full member of the community: contributing dev time to not just get their features in, but to also review patches that have nothing to do with AWS and of no benefit to them, to even paying for PG evangelism.
4. AWS provides no hosted ArangoDB service.
1. AWS never provided a hosted Mongo instance. You know who did? Small startups that provided better support than MongoDB Inc., without the scummy "just dump money into MongoDB Atlas! It will solve all your problems! I promise!" spiel that the marketing company in disguise shoved down its customers' throats (even paying customers).
MongoDB Inc. went around buying out these startups for cents on the dollar right before they publicly announced the license change.
2. AWS did provide a hosted ElasticSearch service. And they did contribute code in return. Amazon's patches to ES included oft-requested security features that ES upstream flat out refused to merge because that'd harm ES corporate's monetization strategy of demanding money for basic security. ES community edition was not a good citizen of the Open Source world.
3. You don't hear this kind of FUD from the PostgreSQL community. Because that is an actually Open Source project with a really good community. Amazon participates in it as a full member of the community: contributing dev time to not just get their features in, but to also review patches that have nothing to do with AWS and of no benefit to them, to even paying for PG evangelism.
4. AWS provides no hosted ArangoDB service.
Re (1) that's because they rebuilt one which represents an ongoing cost and tax that makes it harder for them to compete. Your other gross generalizations are massive distortion of history.. one was acquired by IBM and one was acquired by Rackspace and another remains independent.
Re (2) I think elastic's failure to shift into a cloud/saas company is something of an own goal/failure to execute probably because of misplaced sales incentives and sales in logging and security giving a distorted lens into the community but Amazon very clearly strip mined their community as well.
Re (3) that's completely untrue... there are about 15 companies competing for postgres and postgres-like mindshare right now and you sure as hell better believe most of them believe the hyperscalers' anti-competitive approach to going to market is a major impediment to their own ability to be stay viable and execute.
Re (4) that's because it is not yet popular enough to see ROI from strip mining... but presumably the creators want it to become popular
Re (2) I think elastic's failure to shift into a cloud/saas company is something of an own goal/failure to execute probably because of misplaced sales incentives and sales in logging and security giving a distorted lens into the community but Amazon very clearly strip mined their community as well.
Re (3) that's completely untrue... there are about 15 companies competing for postgres and postgres-like mindshare right now and you sure as hell better believe most of them believe the hyperscalers' anti-competitive approach to going to market is a major impediment to their own ability to be stay viable and execute.
Re (4) that's because it is not yet popular enough to see ROI from strip mining... but presumably the creators want it to become popular
100GB per cluster in the free version? May as well just run SQLite on a single server for a dataset that size
It sounds like you can compile it yourself to remove that restriction under the BSL, rather than using their pre compiled version.
As I understand it, the pre compiled version will eventually include features that aren't in the public repo, acting as a limited trial version of the enterprise release.
People keep pointing fingers at large cloud vendors as being the root of the problem here, and I hard disagree. I’ve been on both sides of this for more than a decade and helped run a large marketplace full of devtool SaaS products. Here’s my non-exhaustive list of problems that got us to this point:
- Developers as a target market being exceptionally hard to market/sell to and incredibly price sensitive. You have to give away huge amounts of value upfront and hope you can make up the difference later.
- Layer in, depending on your perspective, some healthy concern about needing to have ownership of the core parts of your stack or cynicism about trusting a third-party with your things.
- free + source available becomes the conventional wisdom about how to overcome these issues and reach your audience. I’m the process this also gets conflated with “OSS” because we didn’t know better/that was the precedent.
- a whole generation of people are encouraged to default to an incredibly permissive OSS for all their projects. It’s actually super cool and a lot of novel ideas emerge as a result.
- some of these become wildly popular. The inventors/maintainers think they should probably build a business around this.
- They go raise a VC round on the back of their OSS success. Now there’s a lot of pressure to generate VC outcomes.
- They start by selling consulting/enterprise support/etc because RedHat was the role model for how to build a successful OSS business.
- they realise that is actually super hard and unlikely to actually drive the VC outcome they need.
- they pivot into a SaaS/cloud model instead. The growth and margin potential looks like it stacks up better given the outcomes they’re after.
- they eventually discover that simply running the software for you isn’t as lucrative as they thought. For a start, thinking you’re the best at running it purely because you invented it is pure hubris. That’s true at the start, but it doesn’t take much scale for the nuanced expertise of running one specific piece of software is overshadowed by the complexities of running and connecting thousands of anything.
- so… right at the point when you’re beginning to be weighed down by being a victim of your own success, is the same point where the various other vendors who are good at scale are getting pushed to address an opportunity. They’ve customers lining up saying “hey, we want to use X. But we don’t want to run it ourselves, but we want it inside our VPC. With all of the IAM and other controls we’ve come to expect with everything else”. And so the vendors respond.
- The creators change the license in a scramble to buy more time while they work out what’s actually wrong with their business model.
The problem is people trying to sell and OSS product. You’ve already given it away! The thing people pay for needs to be a _completely different_ but complementary product. If that product is “we’ll run software” then don’t be surprised if you find yourself competing with other companies who have more experience in running software (sidebar: I think Instaclustr is a fascinating example of what it would look like to actually lean into this. Don’t run just one piece of software well, carve out a niche at being the best of running any OSS data layer). Even RedHat had a different product: the support.
But the answer has always been that you need a paid enterprise product that has a _feature set_ that you haven’t already given away. Maybe you access that via a cloud service. Maybe it’s an in prem run it yourself thing. Maybe it’s actual humans putting their hands on the keys.
- Developers as a target market being exceptionally hard to market/sell to and incredibly price sensitive. You have to give away huge amounts of value upfront and hope you can make up the difference later.
- Layer in, depending on your perspective, some healthy concern about needing to have ownership of the core parts of your stack or cynicism about trusting a third-party with your things.
- free + source available becomes the conventional wisdom about how to overcome these issues and reach your audience. I’m the process this also gets conflated with “OSS” because we didn’t know better/that was the precedent.
- a whole generation of people are encouraged to default to an incredibly permissive OSS for all their projects. It’s actually super cool and a lot of novel ideas emerge as a result.
- some of these become wildly popular. The inventors/maintainers think they should probably build a business around this.
- They go raise a VC round on the back of their OSS success. Now there’s a lot of pressure to generate VC outcomes.
- They start by selling consulting/enterprise support/etc because RedHat was the role model for how to build a successful OSS business.
- they realise that is actually super hard and unlikely to actually drive the VC outcome they need.
- they pivot into a SaaS/cloud model instead. The growth and margin potential looks like it stacks up better given the outcomes they’re after.
- they eventually discover that simply running the software for you isn’t as lucrative as they thought. For a start, thinking you’re the best at running it purely because you invented it is pure hubris. That’s true at the start, but it doesn’t take much scale for the nuanced expertise of running one specific piece of software is overshadowed by the complexities of running and connecting thousands of anything.
- so… right at the point when you’re beginning to be weighed down by being a victim of your own success, is the same point where the various other vendors who are good at scale are getting pushed to address an opportunity. They’ve customers lining up saying “hey, we want to use X. But we don’t want to run it ourselves, but we want it inside our VPC. With all of the IAM and other controls we’ve come to expect with everything else”. And so the vendors respond.
- The creators change the license in a scramble to buy more time while they work out what’s actually wrong with their business model.
The problem is people trying to sell and OSS product. You’ve already given it away! The thing people pay for needs to be a _completely different_ but complementary product. If that product is “we’ll run software” then don’t be surprised if you find yourself competing with other companies who have more experience in running software (sidebar: I think Instaclustr is a fascinating example of what it would look like to actually lean into this. Don’t run just one piece of software well, carve out a niche at being the best of running any OSS data layer). Even RedHat had a different product: the support.
But the answer has always been that you need a paid enterprise product that has a _feature set_ that you haven’t already given away. Maybe you access that via a cloud service. Maybe it’s an in prem run it yourself thing. Maybe it’s actual humans putting their hands on the keys.
I wonder what is really going on. If you check DBEngines you can see ArangoDB has been stagnant for years https://db-engines.com/en/ranking_trend/system/ArangoDB
I do not see at this level of popularity big clouds to start provide ArangoDB as a service to really compete with them
Is this an act of desperation to raise some additional funds, telling to investors they are protected from cloud competition ? Something else ?
I do not see at this level of popularity big clouds to start provide ArangoDB as a service to really compete with them
Is this an act of desperation to raise some additional funds, telling to investors they are protected from cloud competition ? Something else ?
100% agree. Nobody is really interested on having ArangoDB on the cloud as a service. I guess >99% of the users are not paying and the company is running out of money (sales guys cost a lot!). I think this is a suicide for the product. Clients will remain, also because the switch is expensive. Their proprietary AQL is not easy to convert into SQL, Cypher or Gremlin....
[deleted]
Re-licensing open source software with non-open source licensing is not a commitment to open source, and I'm content with calling out this kind of cognitive dissonance bullshit for as long as it takes. It's not the end of the world, but if you think that softens the blow, it doesn't. It's just plain-and-simple dishonesty.
I’ve been struggling with this for a bit — I am working on something I’d like to make open source for every use except resale / selling a hosted version.
Eg, you can have a private fork you use at work. You can host it for your own use anywhere you want.
I just want to retain the exclusive rights to sell it.
So 2 questions;
Is this not open source?
What’s a palatable license if you want to be able to sell a hosted version of your product?
Eg, you can have a private fork you use at work. You can host it for your own use anywhere you want.
I just want to retain the exclusive rights to sell it.
So 2 questions;
Is this not open source?
What’s a palatable license if you want to be able to sell a hosted version of your product?
> Is this not open source?
The OSI, FSF and DFSG would all agree that this is not open source if it imposes field of use restrictions.
> What’s a palatable license if you want to be able to sell a hosted version of your product?
The old approach here was to do open core, where the core software is open source but enterprisey wants like SAML/OIDC, auditing features, etc. were in a seperate edition. This generally doesn't get the same hostility as this type of license, where only old (and insecure versions) are available for open source usage.
Or just accept that what you want _isn't_ open source, and go for source-available with a freeware edition. Just don't expect to have your cake and eat it with the publicity and profile boost of open source and the exclusive commercialization ability of proprietary software.
The OSI, FSF and DFSG would all agree that this is not open source if it imposes field of use restrictions.
> What’s a palatable license if you want to be able to sell a hosted version of your product?
The old approach here was to do open core, where the core software is open source but enterprisey wants like SAML/OIDC, auditing features, etc. were in a seperate edition. This generally doesn't get the same hostility as this type of license, where only old (and insecure versions) are available for open source usage.
Or just accept that what you want _isn't_ open source, and go for source-available with a freeware edition. Just don't expect to have your cake and eat it with the publicity and profile boost of open source and the exclusive commercialization ability of proprietary software.
Any license that prohibits selling a hosted version will necessarily fail to meet the Open Source Definition. Your best bet would instead be to pick a license that the companies that would do so are irrationally afraid of. The AGPLv3 is the usual choice for this. Even though, e.g., GCP would be legally allowed to, Google internally has an absolute policy against doing so: https://opensource.google/documentation/reference/using/agpl...
AGPL is certainly the popular choice but it is particularly difficult to wield properly in a corporate environment like GCP or AWS. If your goal is "ha ha fuck you megacorp good luck using THIS license" then congratulations, AGPL is for you. If your goal is to foster a community and ensure service providers contribute upstream, then AGPL fails to meet that bar as it is far too hostile for big businesses.
Proprietary licenses are way more hostile than any FOSS license, though.
Clearly what they meant by "committed to open source" is "committed to taking advantage of other people's open source contributions".
This is why we have the GPL, people. Defend your hard work.
This is why we have the GPL, people. Defend your hard work.
Remember that copyleft licenses like the GPL, while necessary to prevent this kind of thing from happening, aren't themselves sufficient to do so. The project would also need to have accepted significant external contributions without a CLA.
Were there any contributions?
I think there used to be community-maintained drivers but it looks like most of them are dead and they only link to official ones. Most PRs on their repos also seem to be from org members (presumably employees?).
As a maintainer of the C#/.NET driver, I'd say our project isn't so much dead as it is complete. We use it in our products and if it requires updates due to breaking changes, we will maintain it, but otherwise it does what we need it to.
Also worth noting that ArangoDB did have one of their own developers work on the project and made many contributions.
[deleted]
Clearly killing open source and wrapping it in $h1t sandwich! I wonder if they were not making enough money, and somebody advised them to do this stupid move.
Yeah, Looking at LinkedIn Insights they put hiring on pause for a while https://www.linkedin.com/company/arangodb/insights/
I think at this point of their development they need to find a way to drive more adoption and ditching Open Source is unlikely to help
I think at this point of their development they need to find a way to drive more adoption and ditching Open Source is unlikely to help
[deleted]
> Our commitment to open-source ideals remains unshaken.
Except for the fact that you are no longer using an open source license. So not so much committed to it as abandoning it.