3 ms·

> You're so focused on the first sentence that you missed the one I've put in caps. Once you link to the program, you've created a modified work, which as it sa

> You're so focused on the first sentence that you missed the one I've put in caps. Once you link to the program, you've created a modified work, which as it says plainly right there in section 9, you cannot do without accepting the license, which is a contract that tells you what you can and can't do with that modified work. First, you're still refusing to read Clause 13 properly, because it clearly sets requirements for what your modified work needs to do, not what you need to do when using it. Second, this still fails the two-party test, because obviously you could convey the modified version to another party and then they would not be bound by anything, and could evade any source code offer requirements in place. I feel like we're going in circles here; I already made all of these points in my original analysis. I also don't know why you're bringing up linking. Linking doesn't factor at all in any of the scenarios I'm talking about. I know how the (A)GPL works in that respect and am extremely familiar with this concept; you don't need to SHOUT IN ALL CAPS about this completely irrelevant point. The licenses are very clear in what constitutes linking, and merely running executable binaries and communicating with them does not, which is the situation we'd have with an offer-stripping reverse proxy. This is extremely well established in the free software ecosystem. You don't need to lecture me on how the GPL works; I am very familiar with it, agree with the consensus interpretations of GPLv2 and GPLv3 (and LGPL), and know all about the linking stuff. It is the AGPL I have a problem with, which does not change any of the requirements related to linking.

legalcorrection 5y ago
That's an interesting point about Clause 13 talking about what the work must do, not the operator. I understand your point about the MIDI software better now. If indeed the protocol has no way of including a link to the source in any field or header or handshake or something, there is indeed a problem. Fwiw, I imagine that a small minority of network protocols have no way whatsoever of including that kind of metadata. And double so for software that a "user" can "interact with." But generally, the two party problem is solved by them needing to modify the source to remove the link to the source. As for the reverse proxy, I think the implied covenant of good faith and fair dealing in every contract would work to prohibit that, but it is a fun hypothetical.
- marcan_42 5y ago
  > But generally, the two party problem is solved by them needing to modify the source to remove the link to the source. The idea is the second party does not modify the source, they merely prevent the link from reaching the end user. Since the second party isn't bound by that clause at all, there's no way this could constitute a violation per se.
  - jka 5y ago
    If I understand this part of the conversation correctly: the theory/loophole is that a second-party could proxy the AGPLv3-licensed content before it reaches the user, and remove links to the source code?
    - marcan_42 5y ago
      They could proxy access to an AGPLv3-licensed application, where such access does not convey copyrightable content. For example, consider a database server that puts up a banner with a link to the source when you open the connection. You could remove said banner with a proxy. It actually doesn't have to be a second party in my opinion, I believe it'd be perfectly legitimate if it's the same party. I'm just using that as a more clear-cut example because otherwise things devolve into endless arguments about whether a judge would see it as good faith or not.
      - jka 5y ago
        Doesn't the process of removing the banner imply that the original software has been modified? (under that line of thinking, the network is the computer (computation is taking place in a distributed manner))
        marcan_42 5y ago
        It does not. The copyrighted work is the code for the software, and making modifications means modifying the copyrighted software. Copyright has no notion of "modification" in the sense of changing the final behavior. It's strictly about making changes to the copyrighted work itself. This is why things can get interesting with binary hooks and patches, which, depending on how they're done, can be argued not to be modifying the copyrighted work (e.g. a hook done via a hardware debug breakpoint does not require making any alterations to the target software per se, in the copyright sense). Similarly, interpreting (e.g. emulating) software is widely understood to be legal since you aren't modifying the underlying software, even if the emulator causes it to behave differently from the original intent. Of course, then things get murky again with emulation techniques such as JIT, which could be argued to be creating a transient derivative work. Or not so transient, in the case of AOT. I would dare say there is a legal argument to be made that running older x86 Mac apps on an M1 Mac could constitute unauthorized creation of a derivative work (since it outright caches AOT recompiled versions of the apps you run using Rosetta). Of course, this seems stupid from a technical point of view, but I'd love to see if there is prior case law on this kind of situation, where a newly introduced technological mechanism can conceivably cause re-classification of the copyright effects of merely running software. It's certainly a deep rabbit hole to go into.

legalcorrection 5y ago

That's an interesting point about Clause 13 talking about what the work must do, not the operator. I understand your point about the MIDI software better now. If indeed the protocol has no way of including a link to the source in any field or header or handshake or something, there is indeed a problem. Fwiw, I imagine that a small minority of network protocols have no way whatsoever of including that kind of metadata. And double so for software that a "user" can "interact with." But generally, the two party problem is solved by them needing to modify the source to remove the link to the source. As for the reverse proxy, I think the implied covenant of good faith and fair dealing in every contract would work to prohibit that, but it is a fun hypothetical.

marcan_42 5y ago
> But generally, the two party problem is solved by them needing to modify the source to remove the link to the source. The idea is the second party does not modify the source, they merely prevent the link from reaching the end user. Since the second party isn't bound by that clause at all, there's no way this could constitute a violation per se.
- jka 5y ago
  If I understand this part of the conversation correctly: the theory/loophole is that a second-party could proxy the AGPLv3-licensed content before it reaches the user, and remove links to the source code?
  - marcan_42 5y ago
    They could proxy access to an AGPLv3-licensed application, where such access does not convey copyrightable content. For example, consider a database server that puts up a banner with a link to the source when you open the connection. You could remove said banner with a proxy. It actually doesn't have to be a second party in my opinion, I believe it'd be perfectly legitimate if it's the same party. I'm just using that as a more clear-cut example because otherwise things devolve into endless arguments about whether a judge would see it as good faith or not.
    - jka 5y ago
      Doesn't the process of removing the banner imply that the original software has been modified? (under that line of thinking, the network is the computer (computation is taking place in a distributed manner))
      - marcan_42 5y ago
        It does not. The copyrighted work is the code for the software, and making modifications means modifying the copyrighted software. Copyright has no notion of "modification" in the sense of changing the final behavior. It's strictly about making changes to the copyrighted work itself. This is why things can get interesting with binary hooks and patches, which, depending on how they're done, can be argued not to be modifying the copyrighted work (e.g. a hook done via a hardware debug breakpoint does not require making any alterations to the target software per se, in the copyright sense). Similarly, interpreting (e.g. emulating) software is widely understood to be legal since you aren't modifying the underlying software, even if the emulator causes it to behave differently from the original intent. Of course, then things get murky again with emulation techniques such as JIT, which could be argued to be creating a transient derivative work. Or not so transient, in the case of AOT. I would dare say there is a legal argument to be made that running older x86 Mac apps on an M1 Mac could constitute unauthorized creation of a derivative work (since it outright caches AOT recompiled versions of the apps you run using Rosetta). Of course, this seems stupid from a technical point of view, but I'd love to see if there is prior case law on this kind of situation, where a newly introduced technological mechanism can conceivably cause re-classification of the copyright effects of merely running software. It's certainly a deep rabbit hole to go into.