[Koha] Proposal To Switch Koha's License to GPLv3 and AGPLv3 or AGPLv3

[MJ Ray]

Thomas Dukleth wrote:
> [This is the second of about three messages which I had intended to send
> in early June reporting on the current state of my seeking answers from
> the SFLC about copyright licensing of Koha.  The effects of chronic lack
> of sleep required me to stop attempting to draft this message for the
> schedule which I had originally intended.]

First of all, thanks to Thomas for sending these and I wish him well
recovering from that chronic ailment.  I reply to key points below.
For the full text, please refer to Thomas's emails in the archive.  I
will reply to the third message when I get time, but I have noted my
own lack of time before.

If you only have time to read one bit, please see section 3.4 near the
end, which strikes at a core reason from the AGPL3 proposal.

[...]
> 1.1.  FSF DRAFTING.
> 
> I include objections raised during the AGPL 3 drafting process.  As MJ Ray
> has identified, the online software for commenting on the FSF license
> discussion drafts has been imperfect with web browser specific problems. 
> Online commenting worked for most everyone most of the time but should
> have been better.  Email and other communication means has been available
> for commenting on the drafts. [...]

I feel Email was not widely available for commenting.  I tried to use
the Email access method several times and it produced error messages
every time I tried.  This was reported to FSF but I seem never to have
got a ticket number for it.

Furthermore, I suspect it's not possible to substantiate the claim
"most everyone most of the time" because failure records did not seem
to be kept, as far as I found on past enquiries.

However, this merely means that some objections should have been
addressed during drafting and that the drafting process was
unnecessarily exclusive.

> 1.2.  MJ RAYS OBJECTIONS.
[...]
> [...]  I am confident that MJ will correct me if he has
> never dropped any of the objections to GPL 3 and AGPL 3 which he once held
> and which I understand to be objections to all versions of the GPL.

Well, I remain mildly concerned about some points, but the extensions
to the GPL FAQ and its use in practice has resolved some and the
others hopefully are too small to impact.

[...]
> 2.  MEETING AT SFLC.
[...]
> The answers which I give to the objections are my own except where I have
> specifically attributed an answer to another person, such as Aaron for
> example, within the same sentence.
> 
> 
> 3.  OBJECTIONS.
> 
> 3.1.  COMPLIANCE BURDEN.
> 
> MJ and Joshua have previously raised the objection that providing the
> source code for the running modified version of a Koha installation is a
> significant burden.
> 
> The actual requirement should not be considered to specify anything
> unnecessarily excessive.  No one would presume that failure to include
> every pixel's worth of modification would constitute lack of compliance. 
> Some reasonable lag between changes in a running version and the
> availability of the source code for the new version would be expected and
> not a compliance problem.

Noting that this opinion is Thomas's because it is not attributed,
upon what is this opinion based?  Why consider it unnecessarily
excessive to follow the AGPLv3 as written and provide complete
Corresponding Source at the time the service is running?

[...]
> 3.1.1.3.  LIMITING BANDWIDTH REMEDY.
> 
> Not everyone who may be running a modified version can afford the
> resources for the technical and financial cost of conveying an
> extraordinarily large number of copies of a large source code base.  MJ
> and Aaron doubt that reducing the compliance burden by linking only to
> modifications along with directing users upstream is compliant with the
> license or at least the FSF interpretation of it.

So I was right on one precondition for my objection: we can't simply
point at git.koha-community.org (and so on) and offer diffs.

> MJ has presumed that limiting bandwidth to the source code would require
> the license to have additional permissions allowing such a bandwidth
> constraint.

No, I am unsure whether limiting bandwidth to the source code would be
acceptable.  I have not presumed anything.  I am undecided on this
aspect.  I question this one in the hope that there is evidence to
clear it up.

In the absence of clarity, it would seem prudent to take a reasonably
conservative view, seeing as copyright infringement is fast heading
towards a guilty-until-proven-innocent position here.  (If you want to
be horrified, search for human-readable descriptions of the UK Digital
Economy Act 2010.)

This sort of misunderstanding does make me wonder whether the concerns
were being considered accurately.  Maybe we should have reviewed a
summary list of the concerns before the meeting, but hindsight is 20-20
and we need to deal with what we have.

[...]
> Controlling the bandwidth to whatever network access is provided to the
> source code is not prohibited by the license language.  Providing access
> to the source code within the means of the party providing access is all
> that is required.  No one has or could ever be expected to have unlimited
> bandwidth and controlling bandwidth can be used to ensure access to the
> source code.  Obviously, limiting bandwidth to such a degree that access
> to the source code is perpetually denied would be prohibited as not
> providing access.

It's a bit difficult to prove that access to the source code is
perpetually denied by such a constraint, though.  So if bandwidth
may be limited, it seems like a bit of a loophole for bad providers.

> Aaron identified the equivalence constraint in section 6 (d).  If the
> program is conveyed in object form, then then there must be "equivalent
> access to the Corresponding Source" with "equivalent copying facilities". 
> Aaron takes "equivalent" to mean that any bandwidth constraint imposed
> upon the source code must also be imposed upon conveying the object code. 
> However, Aaron identified the section only to explain that, as Koha is
> only conveyed in source code form, the whole of section 6 does not apply
> to Koha.

I agree that s6(d) is sort of irrelevant to this situation.  I don't
know if it would be taken as indicative, but I assume not.


Have I read the following section right?  Basically, there *is* an
extra cost in using an external source code hosting service?

> 3.1.1.4.  SOURCE CODE HOSTING SERVICE REMEDY.
> 
> Aaron offered a better suggestion for affording bandwidth than the
> possibility which modifiers would have to constrain the source code. 
> Modifiers could arrange for the bandwidth to be the responsibility of
> another party.  Aaron suggested that those running Koha installations
> could arrange with a Koha support company to host the access to their
> source code with any modifications.  A git repository and build
> instructions for a particular installation would be sufficient.
> 
> Obviously, for a contract over such a hosting service the support company
> should guarantee to the party with a Koha installation that access to the
> source code will be reliable.  In return, the party with a Koha
> installation should guarantee to the support company that all
> modifications will be provided to the support company in cases where the
> party with the Koha installation may be running Koha independently of the
> support company.
> 
> For those installing Koha without any Koha support contract, support
> companies should offer to contract hosting access to the source code with
> any modifications for only a token fee.  A token fee could be anything
> above 0 to make the contract legally binding where the installation
> environment is well known and properly covered by an automated script to
> assist in capturing local source code modifications.

Plus, this brings in my secondary concern of whether the hosted Koha
should go offline whenever the source code hosting service is offline.
Please would you ask that, or should I?

> 3.1.1.5.  ALLOWED REMEDIES FOR OFFSETTING COSTS.
> 
> The possibilities of a source code hosting service for a token fee and
> controlling the bandwidth for access to the source code overcome the most
> significant principled objection that AGPL 3 might impose an unaffordable
> burden on modifiers who cannot afford to provide a great degree of network
> resources themselves.

Picking the one I know best, gitorious.com, finds no way to pay a
token fee and further, "The Website is available only to individuals
who are at least 13 years old", which I guess would have implications
for young users.  http://en.gitorious.org/tos/

Picking another one I've heard of, github.com, finds US$7/mo as the
cheapest option.  Again, there's a "13 years or older" requirement.
There's also a "does not warrant" clause about interruptions (G.12).
http://help.github.com/terms/

Do any suitable guaranteed token fee services currently exist?


Basically, it looks like the extra cost for using AGPLv3 software
arising from Corresponding Source is not completely avoidable.


> 3.3.  SECURITY CONFIGURATION.
[...]
> The intent of AGPL 3 is to provide access to the source code in a manner
> similar to the GPL but with coverage for users of remote network services.
>  There is no expectation in any case that usernames and passwords, or
> other sensitive security configuration information would be revealed for
> any particular version.

What is the basis for being allowed to supply generic security
configuration?  It doesn't appear in the licence.

I am rather more confident that this would not be required (due to
other laws about security and Computer Misuse), but I can understand
why Joshua questioned it.  It's not at all clear.


> 3.4.  DATA.
[...]
> MJ had raised the lack of coverage for data as an insufficiency of AGPL 3.
>  He was raising a concern about vendor lock-in best addressed by
> encouraging the inclusion and use of features allowing users to obtain all
> of their data, and contracts between those running network services and
> their users to ensure that users have access to their own 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?  The current proposal for AGPL 3 stated it would be "quite a
measure of protection more against Koha related code becoming locked
up on a saas platform somewhere in the nebulous "cloud.""
http://lists.koha-community.org/pipermail/koha-devel/2010-May/011303.html

That's sadly not true.  Even FSF says "One problem which the GNU
Affero GPL does not address is the problem of Software as a Service
(SaaS). It is impossible, as far as we know, to address this problem
with a software license." http://www.gnu.org/licenses/why-affero-gpl.html

In other words, I felt the community was being missold AGPL3.  It does
not address saas.  It's easy to think it would at first glance, but it
actually doesn't.  To address saas dangers, we should take action
around portability of data and facilitiating marginal gains, making it
easier to join and collaborate.


> 3.5.  UNTESTED.
> 
> GPL 3 and AGPL 3 are relatively new licenses, having been published three
> years ago.  MJ objects that GPL 3 and AGPL 3 are untested.

I apologise if I gave that impression.  I objected that the meanings
of many key phrases GPL 3 and AGPL 3 are not widely understood: they
are lawyerbombs which may end up having their meanings defined by
disputes involving lawyers.  The FSF uses are not very helpful here
because they can clarify the intent as needed most easily and they are
unlikely to question themselves too harshly.

> 3.6.  COMPULSION OR COOPERATION.
[...]
> The FSF licenses are designed to encourage and reinforce the natural
> social desire of people to cooperate. [...]

However, Co-operatives UK recently published the formula for co-operation:

  Sc * (Ci + Mt) = Co

Shared commitment x Common interests + Mutual trust = Co-operation!

http://www.thereisanalternative.coop/node/7625

I feel the language of compulsion detracts from Mutual trust.  In
other words, it's a balancing act between the commitment required by
a licence and the trust we show in users and developers, which I
feel AGPL balances less well than GPL.

> MJ raises an objection to the compulsion of cooperation from the language
> "ensure cooperation" in the AGPL 3 preamble.

In particular, it exposes a strategic error from which the actual
objections arise.  I don't like the language, but it would be
not worth quibbling if the rest of the licence was unobjectionable.

[...]
> 3.7.  EFFECTIVENESS.
> 
> MJ Ray has claimed that AGPL 3 is easily evaded and ineffectual.

As I've posted before, FSF has claimed that AGPL 3 is ineffectual
against bad Software as a Service providers.

> Some minor evaders of AGPL 3 may never be identified and their practise
> may never be corrected to ensure the rights of the users.  We should not
> be overly concerned that we would fail to identify all possible misuse of
> the license.  However, we do have some means of discovering instances of
> Koha remotely and could add a means of specifically identifying Koha under
> AGPL 3.

Does the community want to waste more time chasing those who do not
want to be part of the community?  Wouldn't it be better to keep our
own part of the river as clean as possible, rather than trying to stop
those downstream from peeing in their own drinking water?

[...]
> Most importantly, at the major companies with business interests opposed
> to the AGPL 3, the people responsible for policy are frightened by AGPL 3.

Most of this section seems below the usual standard.  For example...

> [...]  Google refuses to host AGPL 3 projects on Google
> Code and has purged projects which have been unaware of the restriction on
> Google Code. [...]

But FSF refuses to host projects with non-FDL manuals on Savannah, so
does that mean FSF is scared of manuals under the FreeBSD
documentation licence?  (It doesn't quite mean that, but without
citation, you could draw all sorts of dodgy conclusions.)

> People at all other major companies participating in GPL 3 drafting
> process were also opposed to and fearful of AGPL 3 terms.  No major
> company would participate in the drafting process for AGPL 3.  [...]

I don't feel it's safe to draw that conclusion either.  I've
criticised the exclusive drafting processes elsewhere before,
including the bizarre invitations to participate which included no
social enterprises and relatively few relevant not-for-profits.

> 3.7.1.  MINIMAL STANDARD OF COMPLIANCE.
> 
> MJ objects that providing the opportunity to obtain a tarball of source
> code with hundreds of thousands of lines in various files would satisfy
> compliance. [...]

I apologise if I contributed to this misunderstanding of my view.  I
say such behaviour is compliant but almost useless to the community.
Meanwhile, the costs of AGPL3 would affect everyone.

On this point about whether obfuscated source is a net benefit or not,
I realise that my view is not universal and I accept that.

Regards,
-- 
MJ Ray (slef) Webmaster and developer for hire at | software
www.software.coop http://mjr.towers.org.uk        |  .... co
IMO only: see http://mjr.towers.org.uk/email.html |  .... op