Hacker News Reader

Comment by xorcist | Hacker News Reader

Some things in life are binary. You either allow people to build new products and businesses on your work or you don't. Would you allow me to extend the product with new features? "It depends" is a form of "no". It is not a position to sustainably work from.

If you frame the licensing space as for either personal or commercial use, perhaps your point of view makes sense, but this is not a useful framing for most people, and it is specifically not something the open source community cares about.

If you wish to keep leverage over others then you do not wish to have them compete with you on the same product. That is a valid position to have, but it is squarely on the non-free part of the licensing spectrum. You don't want to play within the open source community and they don't want to play with you. All anyone owe others is to make that clear.

View on HN

This is why open source is rapidly becoming obsolete ;) There have been source-available/fair source/whatever-you-name-it approaches before.

They were attacked by OSI zealots every time because it's not real open source. Which is true, but the unsaid - or well, only sometimes mentioned - other half is that these open source enthusiasts would you rather have a bog standard all-rights-reserved commercial licence than a relatively open licence without the four freedoms!

I can't claim to read other people's thoughts, but my hunch is that this happens because it's too "close" to an open source licence so they view it as competition, while they view commercial software as either a straightforward enemy or they don't care about it whatsoever.

The history aside, this approach just makes the open source community more and more irrelevant each day, especially with the advent of "vibecode your own dependencies up". The 4 freedoms come from a place where they were about users, but gigantic corporations have shoehorned themselves into being users, and instead of the community defending against it, they think the freedom to exploit the maintainers' work while contributing nothing back is more important than keeping the commons free and shared. :P

Only siths think in absolutes.

The freedom to host open-source software is more important than contributing back to the original project: it's where the actual value of open source comes from. Would you host your website behind Apache or Nginx if you couldn't just switch providers and keep the same web server? Would you ever pick up Postgres or MySQL if you couldn't actually pay a company to host that for you, knowing that if they screwed up, you could switch to a provider that did it better?

From a pure engineering reliability perspective, coupling your technology choice to your vendor gives that vendor too much leverage (as we've seen with, for example, VMware).

This isn't about defending the big companies at all. It's about defending the right of hosting providers to compete on hosting a variety of software. In the alternative world of entirely commercial licenses, or entirely BUSL-styled licenses, you would be shackled to the specific vendors that happened to create the technology that you wanted to leverage. This is a scenario where the customer invariably loses.

At its core it's a question of control. If I use this library or app, will I be safe? Will I be able to repair it, use it in the future, pay someone to fix it? Will it still be developed in a few years?

FOSS is a great answer to the first few questions, but it fails at the last one. As a user, yes, I would prefer a cloud-protection license, if it means that software will still be developed in a few years time. It's not like I want to use this software to compete with the author, I'm happy not to be allowed to do that.

Well, there's no guarantee that there will be sufficient market in a few years for that software development to continue unless you fork it and do so (or pay to have done) yourself.

> or entirely BUSL-styled licenses

Let's not get everything mixed up here - I singled out BUSL exactly because it does not prevent competing services, especially at small scale. In fact it would encourage small business and individual usage vs big cloud providers. It also has a conversion clause, so worst case scenario you have a slightly outdated MIT-licensed release to pick up from.

The EUPL the author mentions, the AGPL and others are the ones that directly prevent competing services.

That said, indeed it might not be an ideal choice for that kind of cloud-hosted software if you want to maximize adoption.

The AGPL doesn't prevent competing services.

> The EUPL the author mentions, the AGPL and others are the ones that directly prevent competing services.

To support sibling comment: no it doesn't?

But your point about the revenue cut off in the BUSL is worthwhile (assuming we're talking about a licensor that is leveraging the additional use grant). I just disagree that it's a remedy because it basically punishes a business for being successful, by changing the rules upon which it was built. I'd be very curious to hear of anybody who has licensed software under the BUSL and has ended up getting a license from companies that meet those revenue thresholds.

It's worth noting that the BUSL, by default, with no additional use grant, prohibits the use of the software in production. So I actually think you have the two licenses reversed. The BUSL prohibits production use and competing services by default unless an additional use grant is specified and then it is only allowed under the revenue threshold specified in the additional use grant.

The AGPL has no prohibition whatsoever on the deployment of competing services.

It is expected that you use the license with an Additional Use Grant. For example, Hashicorp says:

> You may make production use of the Licensed Work, provided Your use does not include offering the Licensed Work to third parties on a hosted or embedded basis in order to compete with HashiCorp’s paid version(s) of the Licensed Work.

Or, for a revenue threshold:

> You may make production use of the Licensed Work, provided that your use is solely for an application or system developed or operated by an entity (including its affiliates) with total annual gross revenues of less than $10,000,000 USD.

That is the whole point - you can define your own limits for commercial usage, while keeping the rest of the license text unchanged.

The AGPL's "viral" property inhibits competition without prohibiting it - companies are just scared of accidentally becoming liable to publish private software sources. As far as I know, that's the reason it is banned at Google, Apple and other major companies [1].

That didn't stop AWS though, which is why we now have SSPL and the BSL.

[1] https://opensource.google/documentation/reference/using/agpl...

I think we're agreeing, but you seem to be spinning things:

1. BUSL does not allow production use. Additional Use Grant (optional) is necessary to allow this, and is typcially accompanied by a revenue limit, setting a trap for any business that attempts to use it by changing the rules as they become more successful.

2. The AGPL does allow production use, by default, forever, but requires you publish associated source code when providing the service.

Only one of these licenses bans production use, and that's the BUSL. It can be modified to allow it under certain circumstances, but your original statement, that BUSL allows production use and AGPL prohibits it, is exactly reversed.

Yes, you would be allowed to extend the product. There is no 'it depends', the license is quite short and clear. You have to acquire a commercial license once you go over the revenue threshold, that is all.

I find this much simpler to understand than AGPL/LGPL or the linked EUPL.

Reply on news.ycombinator.com