Reply inline: On Tue, July 13, 2010 20:26, david@lang.hm wrote:
On Tue, 13 Jul 2010, Thomas Dukleth wrote:
[...]
People at libraries should not be frightened or overly anxious about copyright liability. Risks of copyright violation have to be managed for libraries every day. Providing access to materials with or without copy machines exposes libraries to the risk of being sued for facilitating copyright infringement. Library administrators unduly fearful of unreasonable action over any possible copyright violation would need to close the library. Reasonable policies help manage risks and AGPL 3 would be a small addition to all the other risks of libraries which would be duly addressed.
but the probelm is that the people at libraries understand what to do with books to comply with copyright. It's not nearly as clear what they would need to do with software (as this discussion shows, even programmers aren't clear on what is needed to comply)
Most programmers do not know about how to comply properly with the familiar GPL 2 license at the level of attention detail about which I have been enquiring. However, when those modifying the software basically respect the users, then misunderstandings are corrected when needed and there are no serious problems. If the Koha community would choose to adopt AGPL 3, we would need to develop an automated system which assists libraries in complying with AGPL 3 specific requirements. In most cases, libraries have contracts with support companies and support company contracts will likely assume the responsibility for AGPL 3 compliance. I am concerned about the other cases. I am concerned about the libraries doing everything themselves with only the mailing list for support. Those libraries need an automated system to help them. They would also have the experience of the support companies and other libraries to assist them.
3.3. SECURITY CONFIGURATION. [...] Section 1 of the license clarifies the issue of automatic generation.
"The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source."
I don't think that effective security settings can regenerate automatically at the moment. Maybe they should and this is a bug in koha to report at bugs.koha-community.org which should block AGPL 3 adoption.
If we choose to upgrade to AGPL 3 for Koha 3.4, we should file some blocker bugs for issuing an AGPL 3 release until there is some automated support for complying with the license. There would also be blocker bugs for Open NCIP and NCIP 2 code license compatibility We are at least several months from the prospect of a Koha 3.4 release with or without AGPL 3.
3.4. DATA. [...] Lack of such coverage in AGPL 3 is not a reason to object to AGPL 3 for an issue it could never have addressed with any certainty.
Why not?
Copyright licenses are only effective in the domain of copyright. Software licenses specifically are only effective for software. [...]
That's a misleading place to cut. I meant: why not object to AGPL 3 for *not* being a significant "measure of protection more against Koha related code becoming locked up on a saas platform"?
A copyright license is not a data contract.
[...]
especially in light of the e-mails on the list about how a dump of code is not that useful (the changes need to be merged and that is the responsibility of the submitting orginization) I have to ask again what you plan to get by changing the license.
it doesn't prevent the data from being locked up by hosting companies.
it doesn't get code into the upstream koha (it does make it possible to get a dump of the code, but this will be without even version control clues like you have with the libline code so it will be even harder to deal with)
so what is this solving?
The software license is part of the solution by making the version which any particular library is using portable. The library could install that version elsewhere under their own control with any effective access to the source code. If the library is using AGPL 3 software, lock-in would not be based on software code. Perfect version control is not needed to install a particular version on a server under the control of a library. AGPL 3 gives power to remote network users of software where they would not have it otherwise. Moving code from your version upstream would be better and AGPL 3 would make integrating code possible even if it would not necessarily be easy. AGPL 3 does not stop service providers from doing more or stop users from insisting upon more. AGPL 3 is not the whole solution, but it is part of a solution to the general problem of user freedom in the context of remote network use of software. Other remedies are needed to address other parts of the problem. [...]
FSF is encouraging the development of software which uses a different database model ensuring that users can run a local copy of the database in which private information is encrypted but everyone can have a copy of the whole database. We should consider the possibility of such a distributed design for Koha. Such a distributed design may never be sufficiently efficient for Koha but the possibility should be considered.
I haven't heard this before, could you point me at info on this?
See the document which MJ Ray had cited as one example. Who does that server really serve? / by Richard Stallman. - http://www.gnu.org/philosophy/who-does-that-server-really-serve.html . Richard is thinking most particularly of collaborative network programs such as facebook. See the Franklin Street Statement, http://autonomo.us/2008/07/franklin-street-statement/ , and http://autonomo.us/ generally. Autonomous was set up to explore network service issues and develop ideas which FSF and the GNU project could adopt in future after they have been carefully thought through. FSF will take its own good time to do more about network service issues directly but we do not need to wait upon FSF to resolve all the problems. We should do what we can for ourselves. AGPL 3 is part of the mix of things which can be done. The problem which it solves may be a small part of a larger problem. However, we should be pleased that it helps greatly in large set of client server user cases which include Koha. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783