On Wed, 10 Sep 2008 20:36:54 -0500 Jordi Gutiérrez Hermoso wrote: > 2008/9/10 Ben Finney <ben+debian@benfinney.id.au>: > > "Jordi Gutiérrez Hermoso" writes: > > >> And I argue that this extra cost is no greater than the cost of > >> providing the network interface that's triggering this clause in the > >> first place. > > > > This is plainly false: There is, at minimum, additional cost of > > storage, additional cost of bandwidth, > > I have been interpreting the AGPL, and so far have not been challenged > on this interpretation, that these additional costs can be transferred > onto third parties for whom the cost is probably negligible, like code > hosting sites. I think this thread already saw more than one explanation of why this is not necessarily possible. For instance: http://lists.debian.org/debian-legal/2008/09/msg00016.html > The protests I have heard on this point is that perhaps > transferring these costs to third parties is not effective for various > reasons (anonymity and whatnot). The issue is not anonymity: the issue is that I could want to avoid making the application public (and only distribute it to my remote users). Again, see the above-cited message. [...] > > and additional cost of maintaining those modifications over > > time. > > For instances where the maintenance could be cumbersome, I think the > alternative methods of providing source, such as all at once when you > first transfer the software, could be effective. Suppose I never first transfered the software: I just run the application on my server. Your alternative method does not apply. > > How plausible is it that you have a server somewhere providing the > interface but unable to provide the source? Not all servers are http/ftp (or similar) servers. My (modified) application could interact with its remote user through a very simple network protocol, which does not support file transfers at all. I hope you are not arguing that forcing me to implement http/ftp support complies with the DFSG... > I have a hard time > imagining such a situation, so I don't think I fully understand the > impact of this protest against the AGPL. The cases of when the user is > given a device that has a local network interface can be solved by > giving the user the source on a separate medium when given the device; > this seems like a negligible cost too. Suppose I am not giving any physical device to anyone. My (modified) application runs on a small resource-limited server, talks a very simple network protocol (with no http/ftp support) and has remote users on the other side of an ocean... I don't think this is a particularly far-fetched example. And anyway, a work cannot claim to be Free Software, while forbidding some scenarios just because they are "weird". > > > That's before we even get to the question of whether the AGPL allows > > the corresponding source to be unavailable at a given point in time > > when an person who interacts with the program at time T and then at > > time T+X requests the corresponding source. > > I am not sure. It might. The "opportunity to receive the Corresponding > Source" might be an opportunity in the future. To sue, you would > probably have to convince a judge that you were never given an > opportunity at all. An opportunity in the future? Like "click here, and wait for some 10 or 20 years, to get source" ? Needless to say, those stated above are my own opinions and concerns. Usual (or useless) disclaimers: IANAL, TINLA, IANADD, TINASOTODP. -- http://frx.netsons.org/doc/index.html#nanodocs The nano-document series is here! ..................................................... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
Attachment:
pgpk_VKxAEo_A.pgp
Description: PGP signature