3 ms·
Thank you for your detailed reply. > it is (theoretically) trivially easy to work around - just contract out your modifications, have the contractor keep the c
by 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> 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.
- seabass-labrax 3y agoThis 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.
- hedora 3y agoHere 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.