4 ms·

I understand that AGPL is an attempt to combat software-as-a-service otherwise hiding open source behind a network interface (and yes I know, the FSF's preferen

by chungy 5y ago

I understand that AGPL is an attempt to combat software-as-a-service otherwise hiding open source behind a network interface (and yes I know, the FSF's preference against that term). It's still rather heavy-handed to a point that I would even avoid using AGPL software even for myself. It goes far beyond what the standard GPL demands and might even violate the freedoms to run a program as I wish, and to redistribute the software as I wish. The standard GPL already puts "restrictions" on the latter, but at least said restrictions only apply if I choose to distribute binaries. In the case of SaaS, I am more comfortable with running a service and making the choice to distribute my source or not. Personally, I probably would publish substantial changes to software regardless, but if the only thing I do is change a line of CSS, I also don't think it's right to force me to have to set up infrastructure to publish my modified source.

devman0 5y ago
AGPL is basically a clickwrap EULA instead of a distribution license, it also arguably violates freedom 0 of the free software definition.
- lifthrasiir 5y ago
  With that logic virtually every free (and non-free) software violates the freedom 0 because there is no warranty that the software is fit for any particular purpose. The freedom 0 is simply about being able to run the software and doesn't talk about the consequence thereafter.
hedora 5y ago
What infrastructure are you talking about? You could literally just publish the source tarball from upstream and a .patch file. Alternatively, you could put in on github/gitlab for free. This is a particularly low bar, given that you'll need a server to serve the app anyway.
svnpenn 5y ago
> running a service and making the choice to distribute my source or not. This right here is exactly why AGPL (and OSL that I use) exists. It counters your sentence with "no, you can't do that". The fact that it removes your choice is a feature, not a bug. These licences don't give companies an escape hatch from sharing the source code, and I support that.
hardwaresofton 5y ago
The AGPL is a modified code distribution suicide pact (to make it possible to merge upstream), not an anti-commercialization license. The people it punishes are those who modify software but don't contribute changes back upstream. See the FSF article (https://www.fsf.org/bulletin/2021/fall/the-fundamentals-of-the-agplv3 https://www.fsf.org/bulletin/2021/fall/the-fundamentals-of-t... ), reproduced below: > Simply put, the AGPLv3 is effectively the GPLv3, but with an additional licensing term that ensures that users who interact over a network with modified versions of the program can receive the source code for that program. In both licenses, sections four through six provide the terms that give users the right to receive the source code of a program. These terms cover the distribution of verbatim or modified source code as well as compiled executable binaries. However, they only apply when a program is distributed, or more specifically, conveyed to a recipient. Using a program over a network is not "conveying." It is important to note that this only applies to the code running on the server, and not for example to the JavaScript programs that your browser may download and run locally — these are conveyed to you. Some discussion a while back: https://news.ycombinator.com/item?id=30952949 https://news.ycombinator.com/item?id=30952949 [EDIT] - Altered the initial description, there's no requirement to merge upstream, just to make the code available!
- josephcsible 5y ago
  The AGPL just forces you to make the source code of your changes available under itself. There's no obligation to get them merged upstream.
  - hardwaresofton 5y ago
    Thanks for this correction, updated the comment!
- rapnie 5y ago
  AFAIU there's no obligation to contribute upstream at all, just the need to provide the source such that anyone who wants to can contribute upstream. So you can't grab the code in your SaaS and extend it without making it available to the public. For example the Truth Social was briefly in violation of AGPL when they took and adapted the Mastodon source code. Later on they provided a zip-file with the codes in it.
enriquto 5y ago
> The standard GPL already puts "restrictions" on the latter, but at least said restrictions only apply if I choose to distribute binaries. You seem to have it backwards. The GPL and the AGPL concern the relationship between the programmer and the users. They are specifically designed to: 1. Grant the users of the program the "four freedoms". 2. Forbid any third-party middlemen to strip the users of the program of these freedoms. The second point is what separates permissive "google-friendly" licences and copyleft. It doesn't make a difference for the users, but it avoids third party distributors to strip users of the program of the four freedoms. In that sense, I'd say that copyleft really gives "more freedom" to the users (unless they intend to re-distribute the program and strip other users of the freedoms that the original author granted to them). Users of AGPL software are thus assured that they will have the four freedoms forever, regardless of who distributes the program that they use. Construing the GPL or the AGPL as "putting restrictions" to the users can only be done in bad faith.
webmaven 5y ago
> Personally, I probably would publish substantial changes to software regardless, but if the only thing I do is change a line of CSS, I also don't think it's right to force me to have to set up infrastructure to publish my modified source. The modified CSS is already being distributed to the user, so I think the requirement is being satisfied. Now, if you are producing CSS from a different source language, like SASS, you might have to provide that, as it would be the "preferred form of the work for making modifications to it" . Similar logic would apply to minified JS, I think. But in any case, your fear of having to set up infra is overblown. A link to a GitHub or Gitlab repo would suffice (you do have your changes under version control, right?), or a tarball in Google Drive, or any number of other "dumb" solutions. And keep in mind that none of this applies unless your deployment is public- (or client- or customer-) facing. If your use of the modified software is internal to your organization (which includes employees, contractors, and even vendors) the changes can stay private.

by chungy 5y ago

devman0 5y ago

AGPL is basically a clickwrap EULA instead of a distribution license, it also arguably violates freedom 0 of the free software definition.

lifthrasiir 5y ago
With that logic virtually every free (and non-free) software violates the freedom 0 because there is no warranty that the software is fit for any particular purpose. The freedom 0 is simply about being able to run the software and doesn't talk about the consequence thereafter.

hedora 5y ago

What infrastructure are you talking about? You could literally just publish the source tarball from upstream and a .patch file. Alternatively, you could put in on github/gitlab for free. This is a particularly low bar, given that you'll need a server to serve the app anyway.

svnpenn 5y ago

> running a service and making the choice to distribute my source or not. This right here is exactly why AGPL (and OSL that I use) exists. It counters your sentence with "no, you can't do that". The fact that it removes your choice is a feature, not a bug. These licences don't give companies an escape hatch from sharing the source code, and I support that.

hardwaresofton 5y ago

The AGPL is a modified code distribution suicide pact (to make it possible to merge upstream), not an anti-commercialization license. The people it punishes are those who modify software but don't contribute changes back upstream. See the FSF article (https://www.fsf.org/bulletin/2021/fall/the-fundamentals-of-the-agplv3 https://www.fsf.org/bulletin/2021/fall/the-fundamentals-of-t... ), reproduced below: > Simply put, the AGPLv3 is effectively the GPLv3, but with an additional licensing term that ensures that users who interact over a network with modified versions of the program can receive the source code for that program. In both licenses, sections four through six provide the terms that give users the right to receive the source code of a program. These terms cover the distribution of verbatim or modified source code as well as compiled executable binaries. However, they only apply when a program is distributed, or more specifically, conveyed to a recipient. Using a program over a network is not "conveying." It is important to note that this only applies to the code running on the server, and not for example to the JavaScript programs that your browser may download and run locally — these are conveyed to you. Some discussion a while back: https://news.ycombinator.com/item?id=30952949 https://news.ycombinator.com/item?id=30952949 [EDIT] - Altered the initial description, there's no requirement to merge upstream, just to make the code available!

josephcsible 5y ago
The AGPL just forces you to make the source code of your changes available under itself. There's no obligation to get them merged upstream.
- hardwaresofton 5y ago
  Thanks for this correction, updated the comment!
rapnie 5y ago
AFAIU there's no obligation to contribute upstream at all, just the need to provide the source such that anyone who wants to can contribute upstream. So you can't grab the code in your SaaS and extend it without making it available to the public. For example the Truth Social was briefly in violation of AGPL when they took and adapted the Mastodon source code. Later on they provided a zip-file with the codes in it.

enriquto 5y ago

> The standard GPL already puts "restrictions" on the latter, but at least said restrictions only apply if I choose to distribute binaries. You seem to have it backwards. The GPL and the AGPL concern the relationship between the programmer and the users. They are specifically designed to: 1. Grant the users of the program the "four freedoms". 2. Forbid any third-party middlemen to strip the users of the program of these freedoms. The second point is what separates permissive "google-friendly" licences and copyleft. It doesn't make a difference for the users, but it avoids third party distributors to strip users of the program of the four freedoms. In that sense, I'd say that copyleft really gives "more freedom" to the users (unless they intend to re-distribute the program and strip other users of the freedoms that the original author granted to them). Users of AGPL software are thus assured that they will have the four freedoms forever, regardless of who distributes the program that they use. Construing the GPL or the AGPL as "putting restrictions" to the users can only be done in bad faith.

webmaven 5y ago

> Personally, I probably would publish substantial changes to software regardless, but if the only thing I do is change a line of CSS, I also don't think it's right to force me to have to set up infrastructure to publish my modified source. The modified CSS is already being distributed to the user, so I think the requirement is being satisfied. Now, if you are producing CSS from a different source language, like SASS, you might have to provide that, as it would be the "preferred form of the work for making modifications to it" . Similar logic would apply to minified JS, I think. But in any case, your fear of having to set up infra is overblown. A link to a GitHub or Gitlab repo would suffice (you do have your changes under version control, right?), or a tarball in Google Drive, or any number of other "dumb" solutions. And keep in mind that none of this applies unless your deployment is public- (or client- or customer-) facing. If your use of the modified software is internal to your organization (which includes employees, contractors, and even vendors) the changes can stay private.