[Koha] AGPL 3 objections and replies
Thomas Dukleth
kohalist at agogme.com
Wed Jul 14 11:47:05 NZST 2010
Reply inline:
On Tue, July 13, 2010 20:26, david at 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
More information about the Koha
mailing list