4 ms·

Pretty much the one time the GNU Project conceded anything to a different organization. Still very strange. Also, for anyone wondering - don't use the GFDL, it'

Pretty much the one time the GNU Project conceded anything to a different organization. Still very strange. Also, for anyone wondering - don't use the GFDL, it's one of the worst written licenses out there. Every copy or snippet of it needs the full license text attached, which is kind of bonkers if all you're doing is a citation. Debian rejects documentation written under the license because it's unclear and onerous to comply with[0]. It's incompatible with literally any other license on the planet as well (it's not a "proper" Free Software License because of crap like invariant sections, which just exists to force the GNU Manifesto in every copy of the GNU projects documentation). There's also such charming issues like "the anti-DRM clause is worded in such a way that you can't store a GFDL file on an encrypted filesystem". It's a really really bad license and a serious competitor for the worst license ever written by the GNU project (even the AGPL isn't this bad). Wikipedia changed it because they kept having to deal with people who pointed out that anyone reproducing Wikipedia content could technically violate it's license, an obviously-on-the-nose issue. The worst part? The GNU/FSF still recommends the fucking GFDL on its website[1] for documentation even though they offered a carveout for the WMF. It's hard to understate just how bad the GDFL is. [0]: https://www.debian.org/vote/2006/vote_001 https://www.debian.org/vote/2006/vote_001 [1]: https://www.gnu.org/licenses/license-recommendations.en.html#Documentation https://www.gnu.org/licenses/license-recommendations.en.html...

seabass-labrax 3y ago
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.
- noirscape 3y ago
  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.
  - contravariant 3y ago
    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).
  - senko 3y ago
    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?
    - WorldMaker 3y ago
      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.
  - seabass-labrax 3y ago
    Thank you for your detailed reply. > 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! :)
duskwuff 3y ago
GFDL is an especially bad license for a wiki because, under a strict reading of the license, editors are obligated to treat any section of a page titled "Acknowledgements" or "Dedications" as append-only. Did a vandal create a section with that name and fill it with nonsense? Too bad! License says you can't touch it. This is hardly even the craziest thing about the GFDL, but it's one of the most obviously problematic for a wiki.
- MichaelZuo 3y ago
  This sounds almost like a joke... are you sure GFDL requires that?
  - duskwuff 3y ago
    Yes. Section 4 ("Modifications"), point K: > K. For any section Entitled "Acknowledgements" or "Dedications", [anyone copying a modified version of the document must] Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.
garaetjjte 3y ago
>snippet of it needs the full license text attached, which is kind of bonkers if all you're doing is a citation Eh, wouldn't that be fair use use anyway?
hedora 3y ago
Which part of the GFDL requires you include a copy of the entire license if you want to hyperlink a page that contains GFDL content? A quick skimming suggests that it does not require that. In fact, it only talks about distribution of content, not linking: https://www.gnu.org/licenses/fdl-1.3.en.html https://www.gnu.org/licenses/fdl-1.3.en.html

seabass-labrax 3y ago

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.

noirscape 3y ago
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.
- contravariant 3y ago
  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).
- senko 3y ago
  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?
  - WorldMaker 3y ago
    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.
- seabass-labrax 3y ago
  Thank you for your detailed reply. > 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! :)

duskwuff 3y ago

GFDL is an especially bad license for a wiki because, under a strict reading of the license, editors are obligated to treat any section of a page titled "Acknowledgements" or "Dedications" as append-only. Did a vandal create a section with that name and fill it with nonsense? Too bad! License says you can't touch it. This is hardly even the craziest thing about the GFDL, but it's one of the most obviously problematic for a wiki.

MichaelZuo 3y ago
This sounds almost like a joke... are you sure GFDL requires that?
- duskwuff 3y ago
  Yes. Section 4 ("Modifications"), point K: > K. For any section Entitled "Acknowledgements" or "Dedications", [anyone copying a modified version of the document must] Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

garaetjjte 3y ago

>snippet of it needs the full license text attached, which is kind of bonkers if all you're doing is a citation Eh, wouldn't that be fair use use anyway?

hedora 3y ago

Which part of the GFDL requires you include a copy of the entire license if you want to hyperlink a page that contains GFDL content? A quick skimming suggests that it does not require that. In fact, it only talks about distribution of content, not linking: https://www.gnu.org/licenses/fdl-1.3.en.html https://www.gnu.org/licenses/fdl-1.3.en.html