back
3 comments
It seems like this one sentence of my message has become the focal point of it, which was not the intent. However, I corrected it to be more close to the truth, which is to say that it is merely controversial, not necessarily that its status as an open source license is debatable.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495721 might be good background reading
The FTP masters’ message (from 14 years ago!) is pretty convincing:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495721#17

The follow on questions on that thread seem to be fairly hypothetical handwringing, and something I’d expect the FSF to submit an amicus brief, giving their fairly reasonable FAQ answers, if it ever did show up in court. Given that the GPLv3 (and its derivative, the AGPLv3) allow for up to thirty days to remedy shortcomings, your source code being unavailable for a few hours while GitHub is down seems like a non issue.

Sure, I think its mostly settled now. But it definitely was debated at the time.
I feel that the AGPL actually reduces the software freedom in a misguided attempt to close the ASP "loophole", as if offering an API from a private fork is something to be prevented.

I am a proponent of software freedom, and resultantly I view the AGPL as nonfree.

What's your definition of software freedom exactly?
If I download some open source free software, and modify it so it does something differently on my computer, simply running "systemctl start httpd" should not potentially bring down the machinery of state copyright enforcement against me for not publishing my private patches.

Freedom includes freedom to have privacy. Not distributing any software, my privacy should not be violated.

Running an ASP off a private fork is not "loophole", any more than, say, using free software to make missiles or killing machines.

I feel like the AGPL is just anticapitalist fist-shaking.

> Freedom includes freedom to have privacy.

You have that. The AGPL provides rights to _users_ of your software; that's it, no one else. If _you don't provide_ the modified software to someone, they can't demand your private patches. No one can "bring down the machinery of state copyright enforcement" against you, unless you interact with them first and provide them your modified software and they use it.

And even when you do that — when you provide your software to someone — they still can't demand that you "publish" your private patches. Only that you give to _them_ the modified software under the same rights that you received the original software. Only to _them_, not the public. No publishing required. _They_ are free to publish the software they received, of course, as were you when you first received the original software; but you aren't obligated to publish it.

----

The only difference between AGPL and GPL is that the definition of what constitutes "distribution" of software is extended. The AGPL changes only "distribution" and nothing else in the GPL.

Yeah, and running a business on my own computer by providing API services to someone is not distribution of software. Running an API business shouldn't force me to distribute anything to anyone.
> Yeah, and running a business on my own computer by providing API services to someone is not distribution of software.

Depending on the software, according to the author of said software, it can be. I'm not saying this is the case for all software, but for some kinds of software it makes sense.

> Running an API business shouldn't force me to distribute anything to anyone.

"Running an API business" does not "force" you to "distribute anything to anyone". Using software that was clearly meant, by its author, for the provision of a service and licensed as such to you is what requires you to do anything. And the AGPL is very tame at that:

1. you don't have to distribute non-AGPL3 and non-GPL3 code;

2. you don't have to distribute to just about anyone, only your users; and

3. you don't have to distribute anything _you haven't modified_.

----

If you were given the freedom to modify a software, then not providing users of this modified software the same freedoms you received is loss of software freedom, don't you see?

What's the difference to the user? Any kind of selling software is "providing API services", if I'm invoking an API over the network then I'd like access to the source that's behind that API for the same reasons (fixing bugs, making improvements) that I'd like access to the source for an API I'm invoking on my local machine.
Consider "Service as a Software Substitute": https://www.gnu.org/philosophy/who-does-that-server-really-s...

Do you consider it a problem? If not, why not? If so, what other than the AGPL do you propose to fix it?

No, I don't consider it a problem at all. Nothing is being used improperly or against the spirit of free software when software freedom is exercised (by a service provider) - that's the whole point.

I really think the whole AGPL is simply sour grapes, because most GPL-using businesses have not figured out how to become profitable. ("open source is not a business model.") The anti-corporate, anti-business types see people exercising their software freedoms and using free software to make money, and think it's a problem that needs to be stopped.

It's interesting that TPTB have ruled such "ethical source" licenses as nonfree - you're not allowed to restrict Freedom 0 to say that users aren't allowed to, say, use the software to produce bombs. That's not a free software license.

Using it to generate revenue however, is seen as a "loophole" to be "closed".

I don't see a license that forbids the generation of revenue by selling access to a service API using a private fork as any less nonfree than one that forbids the production of bombs.