For instance, let say there is a platform xyz platform that is an abstraction on rancher to deploy kubernetes, that also deploys the grafana, prometheus, loki, cilium etc. But now, the owners of platform xyz says it is 5k a month for enterprise license of this abstraction. But users may or may not realise that they are using all the tools I have listed. Does that mean, the owners of the platform to have to pay the other platforms?
Another question is, can anyone just decide to offer commercial version of any opensource project? Is there any kind of license that protects the interest of opensource developers.
The whole Apache license isn't very long but this is mostly the extent of your obligations: "You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Work."
Apache is a non-copyleft license. Copyleft licenses like the GPL also require that any code changes, derivative works code, etc. needs to be made available if the software is distributed.
However, you can absolutely charge for support, etc. (But I can't assert copyright over code I didn't actually write.)
>Is there any kind of license that protects the interest of opensource developers
If by "protects the interest" you mean forces consumers of the code to pay them or allows them to restrict who uses their code, then pretty much no. The Open Source Definition as it stands pretty much excludes those kind of restrictions. The developers could of course just choose a proprietary license instead if they want to control how their code is used.
I think ghaff gave a pretty good answer as well, but here's some more nuance:
> Does that mean, the owners of the platform to have to pay the other platforms?
No.
Tons of "value-add platforms" exist like this: wrap a bunch of open source up, add a UX layer on top and offer support. As long as you comply with the terms of the license, you can do just that. And many licenses (MIT/BSD/friends) are often complied with by merely redisplaying that software's license in the documentation or on a LICENSES file somewhere.
But there are licenses that are less permissive. The GPL is the one most people think of. If you modify and distribute GPL licensed software to others, you have to share your source. How do you dodge this? SaaS: change the GPL licensed software as much as you want, never distribute it, but instead allow users to interact with it over the network. Totally compliant.
Hence, we got AGPLv3, with this big provision:
> Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
Now, if your bundled SaaS solution includes AGPLv3 software, you have to make its code available.
There are interesting questions here ... if you take an AGPLv3 software and slap a nice GUI under it, is that "linking" under AGPLv3? Possibly. There's at least an argument to be made.
> Is there any kind of license that protects the interest of opensource developers.
If your interest is building software and releasing it openly while keeping it away from people who want to monetize it, traditionally the use of AGPL does just that. Google, Facebook, Amazon – I have first or second-hand knowledge that any attempt to bring AGPL into those ecosystems is a hard no without exception.
But, what "interest" are you trying to protect? I have released software under the BSD license that has been adopted in commercial applications. I'm fine with that; it was in my interest to release it under the BSD license, that's all.
Licenses matter. Pick the one that encodes what you'd like to achieve.
Just one last nuance I'll add to what the parent wrote.
It wasn't actually the intent of the AGPL to keep a cloud service from setting up a competitor to your on-prem software. Rather it was to address what some felt was a loophole in the GPL's treatment of copyleft. (Namely that operating software as a service isn't considered distribution in the eyes of the GPL and therefore a cloud provider could add some secret sauce to your open source software without contributing back to the commons.)
That said, as a practical matter it seems to be pretty effective because most cloud providers won't use AGPL software (and a lot of other companies won't either).
But, because it doesn't actually prevent a cloud provider from competing with you with your own software, there have been a few (non-open source according to the open source definition) licenses created that specifically bar this sort of use.
> But, because it doesn't actually prevent a cloud provider from competing with you with your own software, there have been a few (non-open source according to the open source definition) licenses created that specifically bar this sort of use.
Excellent note, and very accurate!
I can start a company that sells your AGPLv3 software tomorrow. I just have to comply with the terms & conditions. If I'm doing absolutely nothing but operating the software without change, I can satisfy the license by saying "git clone github.com/your/software", done.
Where things get murky is on the concept of linking/derivative works. If I operate a cloud service and make changes to your software to make it use my cloud systems efficiently, those changes have to be open-sourced under AGPLv3. Does that leak too much proprietary information about my systems? Very possibly. That might be enough to stop me. But if I keep going down that road, I end up risking a legal argument that our systems have become so tangled together that parts of my software fall under AGPLv3.
For most companies, this is simply not worth the risk. MongoDB took it one step further with the SSPL:
> you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. [...] “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
This is basically the anti-AWS license: for AWS to run MongoDB proper, they'd need to expose source for huge amounts of their backplane. It's also not open source under almost anyone's definition.
>This is basically the anti-AWS license: for AWS to run MongoDB proper, they'd need to expose source for huge amounts of their backplane.
Not true. For AWS to run MongoDB proper, they could just negotiate with MongoDB to offer it as a managed service - as Tencent, Alibaba, SAP, IBM, Swisscom, OVH and 10+ others have.
> It's also not open source under almost anyone's definition.
Enter the OSI. While it not be "Open Source" (note the capitals) I don't think anybody has the right to legislate the use of "open source" with lower case letters. A nit, but an important one - the capitals force us to realize that it's not a word in Webster's Dictionary. It's a proper noun definiton put forth and pushed by one organization. I can certainly say "...oracle is lying..." but if I say "...Oracle is lying...", I expect the black cars to drive up to my house pretty quickly.
> Not true. For AWS to run MongoDB proper, they could just negotiate with MongoDB to offer it as a managed service - as Tencent, Alibaba, SAP, IBM, Swisscom, OVH and 10+ others have.
True, that is an option. I’ll give anyone odds of it happening ;-)
> While it not be "Open Source" (note the capitals) I don't think anybody has the right to legislate the use of "open source" with lower case letters.
I think talking about “open source” is overloaded to uselessness. I really prefer to talk about licenses.
Even then the consensus I’ve heard from most people who care to think about software licensing is that the SSPL is essentially a weaponized license designed to strip freedoms. Lowercase open source, you be the judge.
It's happened 15+ times before :-)
I agree - talking about actual facts - i.e. licenses - is far better.
I think SSPL (and AGPL) for that matter, protect freedoms - the freedoms of small companies to innovate and not have their work gobbled up and used by gorillas who have the power of distribution and platform. I don't know about the deals MongoDB has made with these 15+ cloud providers, but clearly it's working somehow. That said, maybe they would indeed not license to the three "biggies". Though it's unclear that those will be the three biggies for too much longer.
Thanks for the clear comment back - sorry for being snarky in my note.
No snark perceived! It was a valuable post that added more context to a topic that deserves it. Far too many people perceive a "black and white", open source / closed source distinction where none exists.
> That said, maybe they would indeed not license to the three "biggies"
I think it's actually likely the other direction: I suspect Mongo has been working with all three to get it licensed as a service, and any hesitation is from their potential customers.
I know AWS the best. They want total control, and hate paying other people. They can also afford a long time horizon. They didn't buy Annapurna Labs to offer an alternative to Intel. They aren't going to want to license Mongo because that cuts into margin and costs them control.
