On Mon, 19 Nov 2007 22:56:23 +0000 John Halton wrote: > On Mon, Nov 19, 2007 at 11:26:21PM +0100, Francesco Poli wrote: > > The term "user" is not clearly defined. [...] > > Where do we draw the line? > > I'm inclined to say, "At common sense", taking into account the > intended functionality of the software. So someone getting an "access > denied" message is not a "user" of the software (even though the > software might need to be executed to generate that error). > > Similarly, as I said in my previous email a few minutes ago, while the > definition of "interaction" could be clearer, I think it has to be > taken as meaning "interaction" in a direct, top-of-the-stack sort of > way. As for the kernel, scripting engine etc., as a remote user you > don't interact with those directly, but only through the intermediary > applications sitting on top of them. What if the application on top of the stack is just a thin broker layer and any useful functionality is hidden in a backend that never *directly* interacts with public users "remotely through a computer network"? Your interpretation seems to allow for this simple loophole. Hence I am inclined to think that the FSF's interpretation could be different (even though I don't know which). How can we include the above-mentioned backend, but not, say, the web server or the kernel that runs the web server?!? Do you see what I mean? Where do we draw the line? > > > This restriction compels *whoever runs the modified version* of the > > Program to accommodate the source code on the server or, > > alternatively, to set up and maintain a separate network server to > > provide source code: this may be a significant cost in some cases. > > > This is ultimately a use restriction (from the point of view of > > whoever runs the modified version of the Program) > > The highlighted wording is incorrect. Clause 13 only attaches *to the > person who makes the modifications*. It does *not* apply to someone > else who uses the software as so modified. To my mind this is a major > loophole in the APGL - what you might call the "get a friend to modify > it for you" loophole - but it's not a "use restriction". Since this interpretation would allow for a simple AGPL circumvention strategy (Mark Modifier modifies the application leaving the "get source" button untouched, but Sean P. Serviceprovider runs the modified application after removing the source tar archive from the server filesystem), I suspect the FSF's interpretation will differ. That is why I think that this clause is intended to ultimately be a use restriction. > > > private use of the modified version on a publicly accessible server. > > > > I'm *not* quite convinced that forbidding private use on a publicly > > accessible server should be considered as an acceptable restriction. > > > > I'm not sure I understand what "private use on a publicly accessible > server" means, unless this flows out of the question as to whether an > "access denied" error counts as "use" or "interaction". One can also think of an alpha version of a web application which needs some testing on a public network before its source can be reasonably released. I don't think that should be forbidden. -- http://frx.netsons.org/doc/nanodocs/testing_workstation_install.html Need to read a Debian testing installation walk-through? ..................................................... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
Attachment:
pgpAxNNV1gz0D.pgp
Description: PGP signature