I'd be interested to know why you imply that the (GNU?) AGPL is a bad licence. AGPL-3.0-or-later is a very sensible FOSS licence in my opinion; some awkward punctuation is about the most I can level against it.
The short of it is that it doesn't do what people think it does. Enforcement of the AGPL is almost exclusively on "please comply" basis rather than the (relatively) battle-tested GPL. It's not "just" the GPL with an extra demand that it also applies on network software, it's much more complex than that.
The AGPL is basically a EULA disguised as a license. It tries to solve the network problem (aka SaaSification, a practice I would argue is against the spirit but very much permissible by the Four Freedoms) in a very "lawyeristic" way. If you don't modify AGPL software, you're not under any obligation to comply with the AGPL in any form. But the moment you touch the code, you now need to make the source available.
This also means it is (theoretically) trivially easy to work around - just contract out your modifications, have the contractor keep the copyright and act as the only user of the software with an indefinite license. You don't have to distribute a thing since you didn't modify the source code, your contractor did.
Going on from that, the AGPL doesn't actually say how compliance with section 13 must be achieved. According to most lawyers I've heard (not that I am one to be clear), basically your only "safe" option for most network apps is to make your code a quine (a program that can reproduce its own source code, most software isn't this, especially not network software) or something like JavaScript that is fully interpreted clientside anyway. Something like a link to a GitHub repository is not compliant with the AGPL.
This specific property also tends to cause major issues when confronted with protocols that don't easily allow for transferring large amounts of text. ie. MIDI is technically a network protocol.
All of those issues come from the fact that what the AGPL wants to do fundamentally conflicts with both freedom 0 (right to run software however you wish) and a more informal FSF stance that EULAs are bad.
It's just a bad license in terms of how it's understood and the text itself is of dubious quality due to how clearly it's written by a lawyer who got asked to say X without saying X.
Also, or-later is generally a bad clause for any license, since it hands over all licensing grants to whatever entity you trusted to write the license in the first place, so unless you wrote it yourself, that's not a good idea.
Surely they didn't mess up so badly that you can just contract out the modifications. Why not just require that the code is available, period?
The problem that AGPL tries to fix is quite tricky though, since AFAIK you can do whatever you want with GPL code, unless you want to publish anything. And SaaS is not technically publishing the code but only its behaviour (even though for all intents and purposes this is the same as an obfuscated binary, especially in places where deobfuscation is illegal).
Not parent, but thank you for the thoughtful explanation.
Which free/open source licences do you think would be better for the specific purpose of preventing SaaSification while actually being usable/useful in real life?
I agree with the above commenter that the problem is that SaaSification is a use case of software, rather than properly/entirely a distribution model. Trying to prevent SaaSification falls outside of the available scope of copyright law and thus free/open source licenses entirely. It's the job of an End User License Agreement or a "Mutually Assured Destruction" Patent "Grant" or a Trademark Embargo, not a copyright license/open source license.
The fact that all of those options (EULAs, explosive patent grants, strict trademark enforcement) additionally sound so antithetical to free/open source licenses does seem to directly reflect that "Software Freedom 0" paradox that preventing SaaSification tells users how they can't use the software, which is the very opposite of a modern software freedom. (The FSF probably made a massive mistake in accepting the AGPL as anything more than GPL fan fiction, because it does seem to reflect that they don't trust their own software freedoms and will accept some unfortunate compromises on them.)
I don't know if there is an easy answer for how you build free/open source software and prevent SaaSification without also terribly compromising some of the core virtues of what free/open source software was meant to uphold in the first place.
> it is (theoretically) trivially easy to work around - just contract out your modifications, have the contractor keep the copyright and act as the only user of the software with an indefinite license
Would this not require the contractor to comply with section 13? At this point, you would be paying the contractor for ensuring legal compliance instead of doing this yourself, which is something that companies sometimes do anyway.
> AGPL doesn't actually say how compliance with section 13 must be achieved... MIDI is technically a network protocol
MIDI is indeed a network protocol, but I wouldn't read section 13 as requiring that the network used for the offer of source code or the source code itself is the only network used by the software. If you had a remote MIDI sequencer that users could connect their musical instrument to, it would almost certainly have something like a Web interface as well (MIDI isn't by itself an internet protocol, which I'm sure you already know) where the source code could be offered.
Ambiguities inherent to the diversity of software don't negate the general legal principle of good faith. Posting a link to a repository on GitHub with your modifications is usually sufficient for compliance, and edge cases like where GitHub is down or blocked for your user can be resolved with good-faith email correspondence. Given how much fuzziness there is in law, I don't think it would help much to be more prescriptive in say, requiring the offer to be made over HTTP.
> or-later is generally a bad clause for any license, since it hands over all licensing grants to whatever entity you trusted to write the license
This is true, but I consider it to be the lesser of two evils. The evil that or-later avoids is that of licence incompatibilities and ambiguities, which are frequently complicated by a difficulty in tracing the authorship of older software. Those programs which were licensed with an or-later clause can typically be 'rescued' by a new revision published by the licence steward, similar to how the FSF carved out an exception to the GFDL for Wikimedia as discussed elsewhere in this thread. The evil that or-later causes, that the licence steward makes a compromising change, is quite limited: since they can't restrict rights beyond the older licence, the worst-case scenario is that they go against the spirit of copyleft and make it a fully permissible licence, which is still 100% FOSS and in practice the FSF are not going to do any time soon.
Again, thanks for going into depth. I agree that there are improvements to be made, and I certainly wouldn't consider the AGPL-3.0-or-later to be the 'be all and end all' of FOSS licensing, but I'm not yet convinced it's a bad choice! :)
> If you had a remote MIDI sequencer that users could connect their musical instrument to, it would almost certainly have something like a Web interface as well...
Not at all. There are tons of MIDI devices which communicate over MIDI, and which don't have another network interface. Most electronic keyboards fall into this category, for example.
> MIDI isn't by itself an internet protocol, which I'm sure you already know
AGPL doesn't care. MIDI is a network protocol; whether it's bridged to the general Internet is irrelevant to the license.
Here is the text of section 13. I think you are badly misreading it:
> 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. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.
First of all, it says "your version" has to offer users the ability to download the source. Clearly, a sticker with a URL next to the midi jack would comply. However, it only applies to remote users, so your example is already limited to the corner case where they are connecting to a remote midi device through a network port that doesn't have a UI.
Even then, the license says "if your version supports such interaction" which could be construed to be referring to the phrase that follows the disclaimer instead of the one that precedes it.
Even if you read all of those things in the "you have to serve source code over the network that serves the remote midi protocol" way, the clause "through some standard or customary means of facilitating copying of software" clearly implies that you could (say) offer it over port 443 on some server you run, or via a github link.
In fact, that clause pretty clearly means that only distributing it through some obscure MIDI extension would not put you in compliance with the license.
This is true, but if you were selling a physical musical instrument which included AGPL-licensed software, you could also include a physical copy of the source code on a DVD as per section 6(a). Your argument still stands, but I don't think it is against the spirit of the the licence nor a significant legal risk to ignore section 13 in that (very unusual) case.
