that is a big difference
You are right about in-house, but the lawyers won’t care so much becuase ‘in house’ is not so clear. In house cannot include clients or partners using it? They pay and we host so seems to violate. Pretty useless for most businesses. And it’s not dual licensed, so I cannot contribute or pay to change this outcome. For me, it’s just the same as a closed source saas product. That’s fine, I just find it strange that people would let Amazon etc bully people into crap licenses while they could just use MIT-but-not-for-Amazon.
1. It doesn't solve my problem of finding an Open Source tool. I can just ignore it.
2. I won't read the code because they could claim I copied it if I wrote a similar tool. A browser extension to keep me from viewing Source-Available code would be nice.
but that the problem. There cannot be MIT-but-not-for-Amazon. MIT is a do whatever you want license.
The problem of 4 freedoms is restricted in MIT, that is why GPL exists. SSPL or this license extends that to exclude AWS.
You are right, they could just exclude AWS but you cannot build a license around specific people or names, aws could just change their name and avoid that.
If you were writing the license, how would you rewrite this offending line to exclude only AWS like businesses?
> It’s a crippling license that goes against many of the modern ideas of oss
yes. this goes against MIT because that assumes AWS or the mom and pop store can use your work without contributing back and use your open source code to build a closed source software.
the entire premise of 4 freedoms is that the freedom of seeing/editing code made by author is given to the ultimate end user. MIT goes against that so there is that.
again, how would you rewrite that line to exclude SAAS providers who just leech off of open source projects for their own gain?
But if you say Amazon or any of their subsidiaries. They are not going to rename Amazon to add 1 product to aws.
The wording is indeed difficult; for my taste to be something not considered abuse, it would need to be integrated in a bespoke product where it offers less than 5% of said products functionality. However that would allow aws. But I think it can be rewritten or added on-to by saying something like that it cannot be offered as a distinct service meaning you cannot say ‘we offer a search engine, here is elastic’; it can be a nocode product which allows you to add search and search apis from elastic by clicking them together if that nocode product also allows for many other features not offered in elastic. So some way to convey it needs to be integrated and not just a copy you can spin up.
However, that would be difficult and convoluted and hard to fight. That’s why I was thinking about adding mandatory FTEs if you use it to make money. That type of thing would simply have the aws lawyers not sign off using it.
Yes, you can. You're not providing Nango as a managed service; you're providing your SaaS as a managed service, which uses Nango for some things. But as long as your customers can't access a sizeable portion of Nango *for purposes outside your SaaS*, you're fine.
https://www.elastic.co/licensing/elastic-license/faq
IANAL.
Edit; come to think of it; make it a ‘contribute GPL3 or MIT license’ (not sure if something like it exists); you can use it for anything, however, if you offer it as a hosted product to your clients (aws etc), you must contribute x.y% of your staff FTE to it. GitHub/Gitlab can do the KYC per employee for which the company has to pay.