[Subject changed accommodating requests for easier to follow branches of original thread.] Reply inline: Original Subject: Re: [Koha] Proposal To Switch Koha's License to GPLv3 and AGPLv3 or AGPLv3 On Mon, July 12, 2010 09:13, MJ Ray wrote:
Thomas Dukleth wrote:
[...]
The difficulty had been that AGPL 3 is sufficiently new that SFLC has lacked the familiarity of experience to already have well thought out answers to some questions about applying AGPL 3.
This ^^ is exactly what I argue. Even the expert lawyers that usually support our community haven't mapped all fairly obvious concerns yet.
We are agreed that SFLC has not yet given detailed attention to many obvious aspects of AGPL 3. If Koha would adopt AGPL 3, Koha would be in the vanguard of projects adopting AGPL 3. Hundreds of other projects would have proceeded Koha, however, we would be amongst the first projects with an existing community for which we need to take extra caution by asking serious questions and carefully considering the answers received.
1.2.1. SPECIFIC APPLICATION TO KOHA. [...] We should include Net::Z3950::ZOOM and the source code for Yaz for which ZOOM is merely a wrapper. [...] We should include DBI and the dependency which we currently require DBD::mysql. [...]
This makes the download size/cost problem a little bigger, as well as adding an element of repository management.
The repository management issue is of concern to me. Our initial efforts at automated support for managing the Corresponding Source in relation to code which is incorporated into Koha but which the Koha community does not develop will undoubtedly be less than what they should be. The automation will improve without any great consequence in the interval.
2.1. EQUIVALENT ACCESS TO PROGRAM AND CORRESPONDING SOURCE.
As the use is in object code form for a remote network user under AGPL 3, the "equivalent access" provision of section 6 (d) would apply. Limiting the bandwidth for accessing the source code to a greater degree than the limitation of the bandwidth of the program use for countries where network connectivity is poor and extraordinarily expensive would not be allowed. This change corrects the answer given for limiting bandwidth as a remedy to AGPL 3 objections given in section 3.1.1.3 of an earlier message of mine in this thread at http://lists.katipo.co.nz/pipermail/koha/2010-July/024391.html .
So I hope everyone reads this and understands the implication: if your source code download is being hammered, limiting its bandwidth means you should limit the bandwidth to your catalogue service too!
Aaron answered today that the source code network node and the software network node should have the same overall level of service. They need not have exactly the same level of service at the same time. See his answer to your question about taking the software offline, question Q.1.A in the quoted message at http://lists.katipo.co.nz/pipermail/koha/2010-July/024537.html .
A corner case question is whether putting the source code as a Disallow in the robots.txt http://robotstxt.org/ means you should list the whole Koha as Disallow. I know some libraries (those with rare books, for sure) like to have catalogue pages listed on search engines to help encourage membership.
A provider of free source code hosting services with ample bandwidth, such as http://www.gitorious.org/ and http://github.com/ , would be one option for hosting the Corresponding Source. Contracting Corresponding Source hosting services with a Koha support company would be another option. [...]
I remember that I have an outstanding question about availability linking and external hosting, but this raises another one: does this combine with the previous paragraph to mean that if your chosen cost-free source code hosting service denies bandwidth to someone, then your catalogue service should also deny them bandwidth?
See Aaron's answer about there being no need to take the service offline. Reasonable block lists are usually only temporary if used at all.
So, do any of the cost-free source code hosting services publish their block lists? I didn't find one.
If there is a real problem, people can change source code hosting services. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783