Item — HN Reader

> The GNU project makes it very clear that they are striving for the freedom of the user to modify and adapt the software that they use. So every time a GNU tool is used in the private back-end part of a SaaS webapp, that's directly opposite to the spirit of the GNU project, because you, the end user, have no way of modifying said SaaS.

> Also, I would be very hesitant to release anything valuable with LGPL or even GPL these days.

The point of the AGPL is to close the loophole that allows this abuse. Just switch to it for your own projects.

1 comments

As far as I understand, the AGPL still allows a service provider to use an unmodified binary internally, as long as the user of that service never accesses it directly. If my understanding is correct, that means if GNU were to switch to AGPL, it wouldn't help the users of SaaS webapps that internally use GNU tools at all.

The point of the AGPL is to require sharing of modifications to the software when that software is used in a service. If you're using an unmodified binary, then you haven't made any changes to the software. You won't be obligated to share changes if the changes don't exist, so you could use the unmodified binary internally or externally.

The AGPLv3 has a lot to say about patents, which is enough to scare off many companies from software that uses the AGPLv3, but I believe it won't be triggered if you never make any changes in the first place (and are therefore presumably not a 'contributor').

AGPLv3: https://www.gnu.org/licenses/agpl-3.0.en.html

If the webapps themselves use AGPL software, that's not "internally." If the employees of a SaaS company themselves use AGPL software that isn't linked to the service that users access, that's internally; e.g. if a webapp uses an AGPL database, the users are accessing that database.

I'd say using an AGPL tool as a service for your webapp is this scenario:

"Scenario 1: Using an unmodified AGPL binary" https://medium.com/swlh/understanding-the-agpl-the-most-misu...

which seems to be allowed by AGPL without disclosing source code.

The details are somewhat unclear but basically yes, that's what a cloud provider/SaaS company would probably assume. So they probably just won't use AGPL code and if they do want to offer a service with the same APIs, they can (at least for now) recreate a compatible service that they write themselves.