4 ms·

I think you're speaking of the original AGPL, AGPLv1, which said: "If the Program as you received it is intended to interact with users through a computer netw

I think you're speaking of the original AGPL, AGPLv1, which said: "If the Program as you received it is intended to interact with users through a computer network and if, in the version you received, any user interacting with the Program was given the opportunity to request transmission to that user of the Program's complete source code, you must not remove that facility from your modified version of the Program or work based on the Program, and must offer an equivalent opportunity for all users interacting with your Program through a computer network to request immediate transmission by HTTP of the complete source code of your modified version or other derivative work." This formulation was criticized even by some who were otherwise sympathetic to the broader policy goal. AGPLv3, which is the AGPL that people generally understand to be 'the AGPL' today, says: "[I]f 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." Note the absence of any sort of 'nonremovability of features' implementation of the policy. EDIT: Just an additional point: The current view of RMS and by extension the FSF is that a mere distributor of a version which the distributor has modified must make an effort to have the distributed version comply with that requirement if it did not do so previously (for example, by ensuring that the web application presents some sort of customary offer for source code, though that might not be best practice). There's still no 'feature nonremovability' requirement though. This ended (if not resolved) an argument that had developed last year between me and Bradley Kuhn over whether AGPLv3's special requirement imposed any conditions on mere distributors (my view had been that it did not). For context, I was a lawyer for the FSF when the GPLv3 license family was being drafted and among other things worked on the drafting of AGPLv3 (as did RMS and Bradley). (slight further edit)

teddyh 13y ago
I see; that would indeed be a change since the original Affero GPL. But I note that it only goes into effect upon modification, so mere distributors or SaaS offerers are not affected if they do not alter the program. This means, effectively, that something very much like what I said still applies; If the program did not originally have a facility for downloading source, and you did not modify it, you do not have to add any such facility. > The current view of RMS […] is that a mere distributor of a version which the distributor has modified must make an effort to have the distributed version comply with that requirement if it did not do so previously If this is so, I would like to hear the reasoning behind it; Do you have a link or reference?
- richardfontana 13y ago
  Here's the hypothetical: Suppose work W is licensed by Foo under AGPLv3 but does not support remote network interaction. Bar gets a copy of W and modifies it (call the modified version Y) such that Y now does support remote network interaction when it is run on a server. We assume that Foo, the original copyright holder of W, did not have to "comply" with AGPLv3 section 13 not ony because there was no AGPLv3 licensor upstream from Foo but also because W wouldn't have triggered section 13 under any reasonable reading, since W was not 'remote-network-interactive' software. Clearly if Bar publicly deploys Y, Bar must comply with AGPLv3 section 13. The question is whether Bar has to do something like ensure Y presents a download-source link if Bar merely publishes Y for others to download and install themselves. Bradley's view is that Bar does have such an obligation, for two reasons. One, this is how Bradley reads the text of AGPLv3 section 13 paragraph 1. (I admit that this is one plausible reading of it.) Two, if this weren't the proper interpretation, then there would be a loophole of sorts, or at least a policy frustration, in AGPLv3: If Bar gives Y to Baz, and merely complies with the GPLv3 subset of AGPLv3, then Baz will have the Corresponding Source, but Baz will have no obligation to make that source code available to Baz's users of Baz's deployment of Y. Those users will thus never get the improvements Bar made to W unless they also get a compliantly-distributed copy of Y from Bar. Bradley was closely involved in the drafting of the original (2002) AGPL and I think his interpretation is influenced by that. RMS sided with Bradley: he felt that in this scenario Bar had to do something to Y to make sure that when Y was run it would comply with the source code availability requirement of AGPLv3 section 13. I don't believe this interpretation has been recorded in the FSF's GNU Licenses FAQ yet. I don't have any link or reference other than what I'm reporting right now (this came out of an email discussion). Note that I do not think RMS would take the view reported above if W had been remote-network-interactive software, though I have not asked this question of RMS. W failing to "self-comply" with AGPLv3 section 13 in that case ought to mean that no downstream distributee ought to be held to have to comply with it (somewhat like (A)GPLv3 5d/GPLv2 2c, which was part of the inspiration for the original AGPL).
  - teddyh 13y ago
    The key here is that Bar modifies W to create Y. At that point section 13 paragraph 1 of the AGPL becomes relevant, because Bar has modified the program. My point was that if Bar does not modify the program, then section 13 paragraph 1 does not apply, and Bar is not obliged to insert code to satisfy the condition stated there. You have corrected my slight misconception of the AGPL though; I originally thought Bar could modify W to create whatever he liked without having to insert a facility to download source code, if none previously existed.

teddyh 13y ago

I see; that would indeed be a change since the original Affero GPL. But I note that it only goes into effect upon modification, so mere distributors or SaaS offerers are not affected if they do not alter the program. This means, effectively, that something very much like what I said still applies; If the program did not originally have a facility for downloading source, and you did not modify it, you do not have to add any such facility. > The current view of RMS […] is that a mere distributor of a version which the distributor has modified must make an effort to have the distributed version comply with that requirement if it did not do so previously If this is so, I would like to hear the reasoning behind it; Do you have a link or reference?

richardfontana 13y ago
Here's the hypothetical: Suppose work W is licensed by Foo under AGPLv3 but does not support remote network interaction. Bar gets a copy of W and modifies it (call the modified version Y) such that Y now does support remote network interaction when it is run on a server. We assume that Foo, the original copyright holder of W, did not have to "comply" with AGPLv3 section 13 not ony because there was no AGPLv3 licensor upstream from Foo but also because W wouldn't have triggered section 13 under any reasonable reading, since W was not 'remote-network-interactive' software. Clearly if Bar publicly deploys Y, Bar must comply with AGPLv3 section 13. The question is whether Bar has to do something like ensure Y presents a download-source link if Bar merely publishes Y for others to download and install themselves. Bradley's view is that Bar does have such an obligation, for two reasons. One, this is how Bradley reads the text of AGPLv3 section 13 paragraph 1. (I admit that this is one plausible reading of it.) Two, if this weren't the proper interpretation, then there would be a loophole of sorts, or at least a policy frustration, in AGPLv3: If Bar gives Y to Baz, and merely complies with the GPLv3 subset of AGPLv3, then Baz will have the Corresponding Source, but Baz will have no obligation to make that source code available to Baz's users of Baz's deployment of Y. Those users will thus never get the improvements Bar made to W unless they also get a compliantly-distributed copy of Y from Bar. Bradley was closely involved in the drafting of the original (2002) AGPL and I think his interpretation is influenced by that. RMS sided with Bradley: he felt that in this scenario Bar had to do something to Y to make sure that when Y was run it would comply with the source code availability requirement of AGPLv3 section 13. I don't believe this interpretation has been recorded in the FSF's GNU Licenses FAQ yet. I don't have any link or reference other than what I'm reporting right now (this came out of an email discussion). Note that I do not think RMS would take the view reported above if W had been remote-network-interactive software, though I have not asked this question of RMS. W failing to "self-comply" with AGPLv3 section 13 in that case ought to mean that no downstream distributee ought to be held to have to comply with it (somewhat like (A)GPLv3 5d/GPLv2 2c, which was part of the inspiration for the original AGPL).
- teddyh 13y ago
  The key here is that Bar modifies W to create Y. At that point section 13 paragraph 1 of the AGPL becomes relevant, because Bar has modified the program. My point was that if Bar does not modify the program, then section 13 paragraph 1 does not apply, and Bar is not obliged to insert code to satisfy the condition stated there. You have corrected my slight misconception of the AGPL though; I originally thought Bar could modify W to create whatever he liked without having to insert a facility to download source code, if none previously existed.