Hacker News Reader

Comment by oofbey | Hacker News Reader

This looks quite cool from a technical perspective, but the unusual license definitely gives me pause. Largely because I'm not familiar with BSL. Others say it's increasingly popular, but with a little googling the acronym is still somewhat ambiguous - opensource.org lists BSL as the "Boost Software License" which looks more like BSD. This kind of confusion doesn't support the idea that this is a solid trustworthy OSS license.

Still, I really appreciate that you didn't choose a copy-left license.

On the license front, what is the "change license" clause listed? It says something about changing in 5 years. Does this mean it will become Apache licensed in 2027? Why would you put that in there?

View on HN

It's exactly that. It gives us a little chance to fight against the Giants.

In 5 years the initial version becomes Apache 2.0 then the next version and so on and so forth. CockroachDB uses similar license. MariaDB uses that, Redpanda Data and others. You are right that acronym is confusing - it's not Boost license, it's Business License. Every major technological startup turned away from BSD/Apache 2.0 licenses due to inability to compete with cloud providers without technological edge.

I certainly don't think you should pick a permissive license, and find yourself under competition from companies running your own software.

However, I'm sad that instead of going with an Open Source license that protects against that, you're using a proprietary license. That alone is a nonstarter for many users, not because they want to compete with you but because they want to protect themselves and make sure they have a firm foundation to build on.

Much of the software you're citing as examples moved from Open Source to proprietary, harming their users in the process, and causing many users to seek alternatives.

Do you think AGPL offers such protection? I think even AGPL is fine for Amazon et al, they are happy to dump the code somewhere while selling a managed service with enough wrapper layers. But AGPL is toxic also for self-hosters who aren’t trying to build a managed hosting service, since it applies equally against all parties.

AGPL does not require source distribution of your application, unless the AGPL code is accessed directly by your users.

So, if this were AGPL and I have an closed webservice that uses this, it is in the clear.

But then Amazon is free to host this as a paid service and take all the money.

Redis is doing just fine, PostgreSQL is doing just fine. They are both real open source.

The performance improvements are not worth the legal/compliance overhead of adding non-FOSS to my stack. Much less so if the performance improvements are due just to some optimization choice in the underlying system. In the next 5 years, it will be easier to have Redis adding the io_ring optimizations than for this new project to become uniquely better.

Now I’m curious where you work and how compliance requires FOSS!

You misunderstood. What I am saying is that is precisely because I am working on projects of different sizes and potentially with different customers, I do not want to have the burden of having to check if the projects have specific compliance requirements.

I have a SaaS [0], my own (AGPL, by the way) open source project [1] and also work have the occasional contract job. It's much easier to say "just use Redis because it is FOSS and it gets the job done" across the board then to try to special-case the tools based on licensing requirements.

[0]: https://communick.com

[1]: https://hub20.io

And? AGPL is not a non-commercial license. If Amazon wanted to provide such a service, they would certainly be permitted to. As long as they provided any changes they make to the the AGPL source code. The AGPL would not "infect" their hosting infrastructure.

> AGPL is toxic also for self-hosters who aren’t trying to build a managed hosting service

Absolutely not. First of all, you can always use any software under AGPL as released without any limitation.

Secondly, if you were to make changes and release them you can still run it any way you want.

Thirdly, if you are making changes for internal use, and for some reasons your really want to keep them secret, you can STILL run the database to your heart's contents as long as you don't provide it as a service to the public.

AGPL is much more permissive than people think. It's just providing a degree of protection to developers and and users from patent trolls and other uncooperative entities.

Exactly - the grandparent is asking “can a true copy left / Free Software license protect a young startup from Amazon reselling their software”, and my assertion is no, it cant.

Can you give an example of an AGPL product being resold by Amazon or someone like them?

Mastodon is AGPL and there are various cloud hosting providers.

There really aren't that many popular AGPL server software to start with though, so it's an unfairly biased question.

MongoDB is the most famous example to transition from AGPL to a closed license. MongoDB was AGPL until October 16, 2018. Since October 16, 2018, it uses Server Side Public License (SSPL), which they authored.

From their FAQ:

> The market is quickly moving to consume most software as a service. This is a time of incredible opportunity for open source projects, with the potential to foster a new wave of great open source server side software. The reality, however, is that once an open source project becomes interesting, it is too easy for large cloud vendors to capture all the value but contribute nothing back to the community.

HN discussion from 2018: https://news.ycombinator.com/item?id=18229452

FAQ: https://www.mongodb.com/licensing/server-side-public-license...

Today, MongoDB is an AWS partner: https://aws.amazon.com/quickstart/architecture/mongodb/

The most recent notable example of open-source software going closed because of Amazon specifically is Elasticsearch, which switched from Apache to SSPL. The announcement blog post was titled "Amazon: NOT OK - why we had to change Elastic licensing".

HN discussion from 2021: https://news.ycombinator.com/item?id=25833781

FAQ: https://www.elastic.co/pricing/faq/licensing

MongoDB is definitely an example. Did switching licenses actually "fix" their "problem" though? And ElasticSearch doesn't count since it was a pushover license before and not the AGPL.

AGPL strikes a balance between the needs of users, upstream and intermediate developers.

Here [A]GPL is Schrödinger's license. At the same time people complain that it's too restrictive and not restrictive enough.

If you want to completely prohibit any SaaS usage closed source is the only option, like BSL. And I'll stay away from your software.

We do not choose AGPL so we would not harm our users. Lets not confuse the means and the goal here. AGPL is copyleft and restricting. Fair users refuse using it. OSI does not help technological companies to find a fair solution and force us to go outside of "OSS".

I don't want to enter in the merit of your company's choice, it's definitely up to you what license to use, but I'm confused about that statement around AGPL. How would AGPL harm users?

The lawyers often ban AGPL at tech cos

Which means they may pay for an alternative to the AGPL.

More likely they'll ignore the s/w. Huge amount of talent is working in such companies. Using AGPL will practically exclude them from interacting with the s/w.

Also, smaller companies like to play safe. If FAANG with their million lawyers aren't touching it, why should I take the risk.

Because unlike FAANG you don’t have millions of engineers to create the software from scratch. Companies pay for databases (Oracle, Gemstone, MsSQL, anything at Amazon). Almost all the risks (price changes, maintenance costs, etc.) can be managed adequately via a long term enterprise contract.

Yes, we’re going through this right now

By preventing them from using dragonfly. Many companies prohibit from dev teams(aka our users) from downloading and using agpl licensed software.

> We do not choose AGPL so we would not harm our users.

This is a first. If anything, it seems clear that a FLOSS license such as AGPL achieves exactly the opposite: is highly protective of the users' best interests, both in the short term and long term.

Could you elaborate on why do you think that users are harmed by standard, run-of-the-mill FLOSS licenses?

Depends on who you consider 'the users'. If you are a 'user' in the sense of an individual working on their own stuff, then yes, AGPL protects you a lot.

However, if you are a 'user' in the sense of a company wanting to make software to sell as a service, it doesn't protect you very much, and can make you vulnerable.

How does AGPL can make a company trying to sell a software* as service vulnerable?

*Assuming it's not a memory-store as a service, obviously.

I don’t know, but I do know my legal department says we can’t use it, and I have heard the same about many other companies.

Most legal departments don't allow for copyleft licenses. This is because most legal departments don't actually make their own legal determinations but instead rely on industry norms. And google set the stage here ages ago with their no-GPL (and especially, no-AGPL) policy.

However this is rather uniquely due to Google's monorepo infrastructure. Google quite literally has all its products in the same source code repository, being built and statically linked together to create a single system binary (or so I am told--I've never worked there). In this case AGPL would virally infect the rest of your code and you could find yourself in trouble. Even if they don't, they might get hit with a discovery request for the source code of some project to prove compliance, and in the process have to provide their entire monorepo and all its business secrets to the court. Etc. Etc.

But these are concerns which stem directly from Google's monorepo architecture. It's not generally true of the whole industry. And yet Google's fear of copyleft--rational though it may be in their particular instance--has been copied throughout the entire industry. 99% of the companies out there have nothing to fear from the AGPL. But hey, if you're some random in-house lawyer at company XYZ, who are you to question Google's legal precedent?

> However, if you are a 'user' in the sense of a company wanting to make software to sell as a service (...)

That does not meet the definition of "user", does it?

In addition, if that was the motivation behind that absurd claim, why not be honest and just say "we don't release our software under a FLOSS license because what we actually want is to keep it proprietary"?

It means ‘user’ in the sense of the person who is choosing what software to include in their work stack, and most software of this type is going to be used in a professional setting. If you use a license that most legal departments won’t let their developers use, your software won’t gain much adoption… which is especially important if you are planning on making money from your software. People aren’t going to be paying for support for their personal projects.

Using a non-OSI approved license hurts your users considerably more than AGPL (and this is coming from someone who generally doesn't like the AGPL). Legal teams are far less likely to approve licenses like the one you've chosen, than AGPL.

I could convince a legal team to allow an AGPL service, depending on how we were using it. It would be difficult to get them to allow us to use this license, and I definitely couldn't convince them to allow us to contribute to software using this license.

Effectively, you've ensured you won't have a community, because in reality the project is closed source, and dead if your company dies, which means it's not an option for me to consider.

I do not have any practical, first hand experience with either license. Re -agpl, i know for a fact that it is banned in corporations. We choose BSL to avoid this. Say if a team in amazon would want to use DF internally they could. I know for a fact that AGPL is a big no there. If we are mistaken and BSL is also banned then we will need to see what to do.

I hope people will understand the reason behind bsl. I hope people will see apache there and will help us to grow. Based on HN comments some already do.

As someone building software for a living I fully agree with your decision to not go full OSS. It’s always a hefty discussion but I feel most of the people only exist on the receiving end of software and do not have to worry how a license impacts real life distribution. Big corp (I’m from Germany) DOES hesitate to go with any form of non-Apache-2 licensed OSS software. In Germany often times OSS is even discouraged if there’s no commercial support for it.

I understand the emotions people have regarding licenses that do allow them to work with software as they please - but I also think it’s useless to argue around licensing of a software instead of focusing on the good it can do. Something being proprietary has NO impact on your choice to buy it when outside of the software world. Why does it here?

The problem you are pointing out is not the open source license, it's the lack of support. If they offered AGPL with a dual-license version and made a strong message about commercial support, they could please both crowds without compromises.

> I do not have any practical, first hand experience with either license.

I do have practical first hand experience with both. I can get a legal team to approve the use of AGPL, but I cannot get them to approve BSL, unless we've signed a contract with the company.

Having an understanding of the license, and some first hand experience seems like it would be a pretty important thing, when choosing it, especially for a business.

This is not representative of my experience. AGPL is unconditionally banned at most companies where I know the answer to this question. They don't care if the license is OSI-approved, they care if it aligns with their business requirements and objectives. Most companies are not ideological about open source.

BSL is at least making an attempt to address the legitimate concerns of businesses -- both sides -- in a balanced and pragmatic way. I have no dog in this fight, being neither a BSL licensor nor licensee (nor AGPL for that matter), but having been party to the legal conversations at large companies I understand why BSL is generally considered to be more acceptable than AGPL. BSL may or may not be the right license for this software, I have no opinion, but businesses don't care about arguments from ideological purity. If BSL satisfies their requirements better than AGPL, and anecdotally all the evidence seems to support this notion, then they will go with BSL software.

To put it another way, if OSI is serious about being in the conversation about the future of software licensing, they must address the reasons so many companies refuse to adopt AGPL software.

I wonder how involved you've been in these kinds of discussions. I've run open source programs at companies, and worked together with the legal teams in terms of what was and was not allowed.

Transferring copyright to another company, without a contract with that company, for the most part is something a legal team isn't going to agree to. BSL only addresses one side's concerns, and it's not in your favor.

AGPL, when used for internal services that customers don't interact with, is generally not that difficult to get approved. How many companies are using mongodb, for instance?

If that's your only concern, then why not dual license? Give your users the choice whether they want to follow the current license or the AGPL.

We may do it in the future. We will see if the community will accept Dragonfly with BSL. MariaDb were pretty famous and i do not remember any loud objections to their license.

There were a lot of loud objections to their license, and remember that MariaDB the database isn't licensed that way (it's GPL), just the much less used MaxScale and CMAPI.

I was quite excited to see Dragonfly. However now that the license has been pointed out, I won't be touching it with a 10 foot pole. I wish you the best of luck, but I'll never use it.

If it was AGPL I'd have been a happy camper though.

> Every major technological startup turned away from BSD/Apache 2.0 licenses due to inability to compete with cloud providers without technological edge.

No, there are plenty that still use permissive licenses.

GitLab uses MIT and a custom license for EE: https://docs.gitlab.com/ee/development/licensing.html

Deno uses an MIT license and has some secret sauce that is currently just in hosted services AFAIK: https://github.com/denoland/deno/blob/main/LICENSE.md

PlanetScale has hosted services and an open source tool called Vitess which is Apache licensed: https://planetscale.com/ https://github.com/vitessio/vitess

Finally Redis has a BSD licensed core, a source available license for additional modules, and a closed source license for enterprise. https://redis.com/legal/licenses/

Redis has a BSD license because it was written by antirez who did not intend to make it a commercial enterprise. Today its too late to change and wont help Redis Inc to protect their ip. We looked at elastic, mongodb, cocroach labs, mariadb, redpanda, atlassian, grafana labs , scylladb. The last two are agpl but the motivation is the same: to protect themselves.

Bravo for picking the BSL and writing your license the way you have. It shows maturity in that you and your company know what they are doing and intend to be there for the long haul.

MariaDB is GPL there are some enterprise components which are BSL.

Was excited to see the project but now seeing it is not Open Source it means 1/10th of value

Reply on news.ycombinator.com