[Koha] AGPL 3 objections and replies

[david at lang.hm]

On Tue, 13 Jul 2010, Thomas Dukleth wrote:

>
> On Tue, July 13, 2010 20:26, david at lang.hm wrote:
>> On Tue, 13 Jul 2010, Thomas Dukleth wrote:
>
>>>>>>> 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.

I disagree with this assertion. It's very easy to have AGPL3 software 
which talks to some other service that is not open. This would prevent 
people from setting up their own instance.

This could be something as simple as tieing in to some proprietary 
authentication server. you would be abel to get all the interface code, 
but unless you have the server to talk to you are out of luck. Yes, this 
simple example could be hacked around, but my point is that getting the 
source does not equate to being able to run your own instance of the 
service.

If you try to say that the AGPL3 means that every service needed to run 
the code must be available, that would prohibit using Oracle as a 
database, or Active Directory as an authentication service (things that I 
am sure someone is doing somewhere that I'm sure we would all agree are 
perfectly legitimate)


> 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.

I don't see AGPL3 being effective in blocking a bad actor. It's just too 
easy to setup whatever you don't want to share as a separate application 
and then modify Koha to access it via a web services call (or other 
RPC-like API)

>>> 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.

The type of database needed for a distributed facebook is very different 
from what is needed to support a traditional database application.

the fact that the FSF is talking about this is very different from what I 
read into your statement (which seemed to imply that there was something 
concrete that Koha should consider switching to, if not now, then at least 
in the relativly near future)

> 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.

The FSF can make suggestions, but they are actually _doing_ very little in 
terms of providing code nowdays. some of the code they are providing is 
still central to a system, but the fiasco that was the GPL3 proposals 
process showed that this is more a matter of habit and convienience for 
the core developers who really maintain most of those pieces than it is 
actual contributions from the FSF.

David Lang