On Wed, 3 Sep 2008 18:47:59 +0200 Michelle Konzack wrote: > Hello Francesco,
Hi. > > Am 2008-08-29 23:56:56, schrieb Francesco Poli: > > > If you're really worried about this, upload it to two different free > > > VCS > > > services. > > > > They still may be off-line at the same time: it's less likely, but > > still possible. > > And therefore I have *two* services to monitor, to check whether I have > > to re-upload to a third place! :-( > > Are you joking? > > <http://www.simtel.net/> > <http://www.linuxberg.com/> > > The have several 100 mirrors worldwide... No, I am not joking. The problem basically boils down to: is there a generally-accepted statement that uploading source to a public hosting service suffices for the purpose of complying with Section 13 of the AfferoGPLv3? As long as you use a public hosting service, you are offering access to source through an external service, which may be (temporarily) unavailable when a user attempts to download source. Which steps does the AfferoGPLv3 requires you (as a person who modified the application and runs it on a publicly-accessible server) to take in order to ensure you are actually "offer[ing] all users [...] an opportunity to receive the Corresponding Source of your version" ? Maybe making source available from a public hosting service with 100 mirrors worldwide suffices. The probability of having *all* the mirrors unreachable at the same time is really close to zero (even though not zero). It could be that, in the unlikely case all the mirrors are unusable, you are excused for not making source available. This is a possible interpretation, indeed. On the other hand, it could be that you are *not* excused. If this is the right interpretation, then you have to monitor the external hosting service and immediately shut the application down, as soon as the source becomes (temporarily) unavailable. This is another possible interpretation. Without a generally-accepted statement that tells us which interpretation is the official one, we cannot know. To stay on the safe side, we should assume that the pessimistic interpretation (i.e.: the second one) is correct. Disclaimers, again: 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
pgpDPv4ZZFETr.pgp
Description: PGP signature
