> No you don't, as that's not creating any users, the source code repo is the source code repo, not a distributed program you provide as service for anybody.
The license is a copyright license and deals exclusively in modification and redistribution, not usage - that includes the source code. "Users" mean "potential users" in this context; whoever hypothetically uses the software in any given version, as it exists in source code form, regardless of whether such users come into existence or not. It doesn't matter whether the software is deployed or not; the license cannot and does not claim to control or have anything to do with that. If it did - if the violation only occurred at the point where the software is deployed and run - then again that would imply this is an EULA that controls usage and violates Freedom Zero.
Again, consider my "two parties" scenario. I make some changes to AGPL software, but never deploy it or offer it as a service. According to you, that is perfectly OK. I then send it to someone. According to you, again, that is perfectly okay, just like contributing to an AGPL project. Then that someone makes zero changes to the code - therefore not triggering clause 13, obviously - and deploys it without updating the source code offer. No problem. If the license worked as you claim, then it doesn't work to close the SaaS loophole at all.
It does not, and the entire hack the FSF came up with is precisely this, converting a usage restriction into a responsibility for the developer making modifications. Everyone defending the AGPL misunderstands this, because the FSF has been very careful to never bring up that this is what they did. They treat it like schrodinger's license: simultaneously claiming it can do things that require it to restrict usage (making it nonfree) and claiming it is a free software copyright license.
> I'd heavily recommend talking to someone with (FOSS) legal experience if you're involved in such distributions, no offense meant.
It's rather difficult to find someone who will consider entertaining the idea that the FSF is completely backwards in their license design, because nobody wants to open that can of worms. People are much happier to just pretend nothing is wrong and move on.
> We're providing most of our code base under the AGPLv3 and have never faced any such issue either for people contributing to our projects or us contributing to other AGPLv3 projects.
Of course, because neither you nor your contributors actually parsed the AGPL properly nor are you aware of the violations occurring on a daily bases. That nobody knows there is a problem doesn't mean there isn't one :)
> Granted, some FANG company refused to use us
No surprise there. I have a hard time using AGPL software too; last time I discovered some on my system I was already in violation, because my distro had patched it without adding a source code offer, and since I use a source-based distro (Gentoo) that patch occurred on my machine, making me responsible for it. On top of that, I was running it as a network service behind a protocol-translating proxy, just because that is how it was meant to be used, so even if it did have a source code offer, it would have been invisible to external users. I was ticking all the boxes for AGPL abuse without even knowing it.
(What nefarious service was I running taking advantage of a poor AGPL project? My personal email server, which used dspam as a spam filter - although not directly exposed to the internet, it could easily be argued that everyone sending mail to me is a "user" of dspam since the data they sent is piped to it, quite directly, and the AGPL does not make any attempt to carefully define these terms)
Right now the only AGPLed software I (knowingly!) run is Nextcloud (with 2 other users besides myself) and (as of a recent license change, sigh) Grafana, but I once thought of making a little patch to a Nextcloud CSS file as a joke, and had to remind myself that that would've been an AGPL violation without packaging it up and distributing it and updating the source link in the footer. For Grafana I also had a tiny proxy-inserted patch (just because it was easier that way than rebuilding, this was before the AGPL change) just to add the ability to display image icons next to dashboard names (again for a little joke displaying character images for servers), but I'm going to get rid of that before the AGPL update on that box because I just don't want to deal with any of this. Not exactly a comfortable feeling knowing I can't even make a trivial change to "free software" running on my own system without breaking the license. And it gives me zero incentive to contribute to these projects. I don't want to support this kind of ecosystem.
(Web apps: for fuck's sake, if you insist on being AGPL, please implement self-serving source code so we don't have to deal with any of this nonsense, and then maybe you can take GitHub pull requests without everyone violating the license too.)
I once had a discussion with the authors of a DAW that used the AGPL license, and pointed out that MIDI is technically a network protocol - meaning their DAW would have to figure out a way to make source code offers over MIDI, to be presented to users on the other end, even though MIDI doesn't even have any standard mechanism for user-interface text. Never mind that MIDI can even be used over a unidirectional transport, so you couldn't even do that at all in some cases. The AGPL doesn't even begin to consider these problems; it was written assuming everything is a web server or something. I got crickets from the devs. Sigh. (Why is a DAW AGPLed to begin with even?)
Seriously, it's a completely broken license, written by some lawyer who though they were being clever and had magically solved the SaaS + free software issue, without bothering to consider the consequences of what they were creating. And now everyone's sweeping the problem under the rug and nobody wants to seriously talk about it. Because how could the FSF be wrong about free software licensing?
> but that's not something really hurting us in any way
I dunno, for what it's worth the AGPL definitely turns me off from contributing to projects, but maybe you aren't losing enough contributors to care ¯\_(ツ)_/¯
This is of course still predicated on you not caring that your contributors are all violating each other's license. Is that a problem? In practice, probably not, if nobody actually makes legal demands over it. But it's a fact, whether it's a problem or not. And I don't like relying on "people being nice and not enforcing license violations" to run my open source projects. We have licenses for a reason, ignoring them and encouraging certain violations just because the situation isn't a problem (or because nobody understands the license) invalidates the entire point of licenses.
> and definitively better than getting stabbed in the back like some other projects got from some SaaS companies due to having a permissive license that allowed them to deploy changes without giving them back anymore.
Too bad that, as I explained, if a company really wants to use AGPL software without contributing back, they still can.
Personally, everything I've written recently is MIT or dual licensed, but I understand the desire not to allow companies to deploy modified versions of open source software without giving back. The AGPL just doesn't fix that problem. At all. Fixing that problem is incompatible with the Free Software Definition. If you really, really want to fix that problem that badly, you have to accept that your license cannot be a Free Software license by the standards we use today. It's one or the other.
A thought that's probably dumb: how many of these issues could you resolve by just adding the word "reasonable"? Ie:
> If you modify the Program, you must make a reasonable effort to offer all users interacting with the modified program remotely through a computer network [...] an opportunity to receive the Corresponding Source of your version
IANAL, but offering the source to users of a web app seems pretty reasonable. offering the source over MIDI does not.
This doesn't solve the problem of having two different parties, of course.
I'm sympathetic to the need for a license like the AGPL. But—perhaps it should be just be a EULA. Maybe freedom zero was a bad idea. It was written in a world where AWS didn't exist, and there's no shame in realizing that you need to change with the times.
The license is a copyright license and deals exclusively in modification and redistribution, not usage - that includes the source code. "Users" mean "potential users" in this context; whoever hypothetically uses the software in any given version, as it exists in source code form, regardless of whether such users come into existence or not. It doesn't matter whether the software is deployed or not; the license cannot and does not claim to control or have anything to do with that. If it did - if the violation only occurred at the point where the software is deployed and run - then again that would imply this is an EULA that controls usage and violates Freedom Zero.
Again, consider my "two parties" scenario. I make some changes to AGPL software, but never deploy it or offer it as a service. According to you, that is perfectly OK. I then send it to someone. According to you, again, that is perfectly okay, just like contributing to an AGPL project. Then that someone makes zero changes to the code - therefore not triggering clause 13, obviously - and deploys it without updating the source code offer. No problem. If the license worked as you claim, then it doesn't work to close the SaaS loophole at all.
It does not, and the entire hack the FSF came up with is precisely this, converting a usage restriction into a responsibility for the developer making modifications. Everyone defending the AGPL misunderstands this, because the FSF has been very careful to never bring up that this is what they did. They treat it like schrodinger's license: simultaneously claiming it can do things that require it to restrict usage (making it nonfree) and claiming it is a free software copyright license.
> I'd heavily recommend talking to someone with (FOSS) legal experience if you're involved in such distributions, no offense meant.
It's rather difficult to find someone who will consider entertaining the idea that the FSF is completely backwards in their license design, because nobody wants to open that can of worms. People are much happier to just pretend nothing is wrong and move on.
> We're providing most of our code base under the AGPLv3 and have never faced any such issue either for people contributing to our projects or us contributing to other AGPLv3 projects.
Of course, because neither you nor your contributors actually parsed the AGPL properly nor are you aware of the violations occurring on a daily bases. That nobody knows there is a problem doesn't mean there isn't one :)
> Granted, some FANG company refused to use us
No surprise there. I have a hard time using AGPL software too; last time I discovered some on my system I was already in violation, because my distro had patched it without adding a source code offer, and since I use a source-based distro (Gentoo) that patch occurred on my machine, making me responsible for it. On top of that, I was running it as a network service behind a protocol-translating proxy, just because that is how it was meant to be used, so even if it did have a source code offer, it would have been invisible to external users. I was ticking all the boxes for AGPL abuse without even knowing it.
(What nefarious service was I running taking advantage of a poor AGPL project? My personal email server, which used dspam as a spam filter - although not directly exposed to the internet, it could easily be argued that everyone sending mail to me is a "user" of dspam since the data they sent is piped to it, quite directly, and the AGPL does not make any attempt to carefully define these terms)
Right now the only AGPLed software I (knowingly!) run is Nextcloud (with 2 other users besides myself) and (as of a recent license change, sigh) Grafana, but I once thought of making a little patch to a Nextcloud CSS file as a joke, and had to remind myself that that would've been an AGPL violation without packaging it up and distributing it and updating the source link in the footer. For Grafana I also had a tiny proxy-inserted patch (just because it was easier that way than rebuilding, this was before the AGPL change) just to add the ability to display image icons next to dashboard names (again for a little joke displaying character images for servers), but I'm going to get rid of that before the AGPL update on that box because I just don't want to deal with any of this. Not exactly a comfortable feeling knowing I can't even make a trivial change to "free software" running on my own system without breaking the license. And it gives me zero incentive to contribute to these projects. I don't want to support this kind of ecosystem.
(Web apps: for fuck's sake, if you insist on being AGPL, please implement self-serving source code so we don't have to deal with any of this nonsense, and then maybe you can take GitHub pull requests without everyone violating the license too.)
I once had a discussion with the authors of a DAW that used the AGPL license, and pointed out that MIDI is technically a network protocol - meaning their DAW would have to figure out a way to make source code offers over MIDI, to be presented to users on the other end, even though MIDI doesn't even have any standard mechanism for user-interface text. Never mind that MIDI can even be used over a unidirectional transport, so you couldn't even do that at all in some cases. The AGPL doesn't even begin to consider these problems; it was written assuming everything is a web server or something. I got crickets from the devs. Sigh. (Why is a DAW AGPLed to begin with even?)
Seriously, it's a completely broken license, written by some lawyer who though they were being clever and had magically solved the SaaS + free software issue, without bothering to consider the consequences of what they were creating. And now everyone's sweeping the problem under the rug and nobody wants to seriously talk about it. Because how could the FSF be wrong about free software licensing?
> but that's not something really hurting us in any way
I dunno, for what it's worth the AGPL definitely turns me off from contributing to projects, but maybe you aren't losing enough contributors to care ¯\_(ツ)_/¯
This is of course still predicated on you not caring that your contributors are all violating each other's license. Is that a problem? In practice, probably not, if nobody actually makes legal demands over it. But it's a fact, whether it's a problem or not. And I don't like relying on "people being nice and not enforcing license violations" to run my open source projects. We have licenses for a reason, ignoring them and encouraging certain violations just because the situation isn't a problem (or because nobody understands the license) invalidates the entire point of licenses.
> and definitively better than getting stabbed in the back like some other projects got from some SaaS companies due to having a permissive license that allowed them to deploy changes without giving them back anymore.
Too bad that, as I explained, if a company really wants to use AGPL software without contributing back, they still can.
Personally, everything I've written recently is MIT or dual licensed, but I understand the desire not to allow companies to deploy modified versions of open source software without giving back. The AGPL just doesn't fix that problem. At all. Fixing that problem is incompatible with the Free Software Definition. If you really, really want to fix that problem that badly, you have to accept that your license cannot be a Free Software license by the standards we use today. It's one or the other.