GPL and AGPL are already there, I know what they are and the intention is clear. And like you said, if they want to dual license it, they still can.
"Then it shouldn't be open source" - Yes, true and I agree. But source available, with a bit of a community in github/discord and opportunity to host the code yourself free for small use cases, read the code and raise PRs is WAY BETTER than a fully closed source product. How do we standardise that in a similar way we have done with open source licenses?
It doesn't but I don't think I've seen Amazon being cheaper than other hosting options, especially after IO costs.
What AGPL does stop is Amazon writing improvements, extensions, and integrations for your product and then refusing to make them public in a way they can be upstreamed. That's the bigger issue.
Competing on hosting price or on maintenance/support contracts against Amazon generally is going to favor the smaller party because of the AWS tax. Competing against a city's worth of engineers improving a closed source downstream of your product however is going to be a losing battle. AGPL fixes that.
This is exactly backwards, because of how corporate procurement works.
Large companies--the ones with money--have a whole process around working with new vendors. It can take months to setup. A security review, audit, and legal are likely to be involved.
Or, they all already have a contract with amazon and can start using the Amazon service providing X immediately.
From CTO to audit, risk, accounting, and compliance, everyone's life is easier if they use one vendor for everything, rather than 10.
Larger companies are willing to eat a higher cost for the sake of bureaucratic and logistic simplicity.
The point is big established vendor free-riding on the work a smaller company has done, potentially extinguishing or significantly damaging it and by extention the future of the project.
The upstream can provide:
- Hosting (as mentioned before) or assisting in managing colocated infra.
- Proprietary Licensure for more permissive uses (as mentioned before).
- Support/Security contracts for LTS/Enterprise releases.
- Bug & Feature Bounties for priority changes (or a "hire our engineer" type system).
- Contracting and consulting services for companies building on top of their product.
That's just naming a few but there are plenty of ways to build out a reliable income base for a popular open source product as long as you pick the right licensing early on.
Hosting, Deployment help, LTS release
When you are buying a "one click" aws managed service?
Are feature or bug bounties even applicable if you have to wait an unknown amount of time for it to reach you via AWS?
I'm merely suggesting THAT copyleft doesn't provide you any protection here and WHY that is potentially problematic.
You wouldn't however I was listing them for completeness-sake because they are common strategies employed by FOSS maintainer companies and there's still a market for them outside of the AWS world.
> Are feature or bug bounties even applicable if you have to wait an unknown amount of time for it to reach you via AWS?
That can actually end up being a selling point for moving off the AWS version. If you can effectively "advertise" that and a company really needs a specific feature for their product, that might give them the justification to jump ship to the non-AWS version of the product.
> I'm merely suggesting THAT copyleft doesn't provide you any protection here and WHY that is potentially problematic.
Oh for sure. However I would maybe say that it offers limited protection here (mainly offering protection in other ways) rather than none at all. And that can definitely be problematic no doubt but nowadays I think companies are a lot more hesitant on blindly lumping everything onto AWS compared to 5 or 10 years ago so I'd like to believe that AWS' authority in deciding what is and isn't a viable product is declining in the space.
What the end goal of these so-called opensource companies want is to have you use their "free" demo, but when you get slightly big and is somewhat locked in, or need some feature considered enterprise (coz you got bigger or have revenue), they extract a partial income stream off you.
This revenue model isn't bad per se, but why not just be upfront about it?
Look at unreal engine - their license explicitly states this. You give them some % of your revenue if it reaches $1 million or something like that. Why can't this be more normalized?
This business model is still massively preferable to fully closed source in my view.
Given the way that SPDX is set up, I imagine the ideal way to do it would be to create some standard proprietary licenses and then add exceptions for "small" users that don't want to use the copyleft license and would eventually like to get big.
i.e.
- Commercial-Royalties-1pct
- Commercial-Royalties-5pct
- Commercial-Royalties-10pct
- Commercial-Royalties-Negotiable
- Commercial-Seats-Negotiable
with the following optional exceptions
- Under-100k-USD-Revenue
- Under-1M-USD-Revenue
- Under-5M-USD-Revenue
- Under-10M-USD-Revenue
There's a certain amount of inflexibility that comes from trying to standardise license terms in a way that's compatible with SPDX but maybe an extension to SPDX in the future might improve that and allow you to specify certain terms on licenses more than just basic exceptions.
But what about 1% of revenue for a UX libary or database product from uber?
I'd say that the old elastic licence is great to standardise and so is the 0.5%, 1%, 1.5% or 2%; over a Million, 5 Million or 10 Million.
It doesn't have to always be at 1%.
You could have a "negotiable" license as well but it becomes quickly non-trivial to document what the negotiated terms are in your SBOM.