Comment by bad416f1f5a2

4 years ago

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.

Thanks for such an elaborate and informative answer. This is really helpful.

  • 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.

      4 replies →