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

[Thomas Dukleth]

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

I raised some historical objections to AGPL 3 when I met with Aaron
Williamson of the Software Freedom Law Center (SFLC) at the end of May.


1.  SOURCES OF OBJECTIONS.

I principally attempt to address well known objections to AGPL 3
specifically, which is section 13 of AGPL 3.  Other sections of AGPL 3 are
identical to GPL 3 and I mostly avoid addressing objections common to both
licenses in this message.  I also have not noted GPL 3 objections raised
in the context of since 2007.


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.

See GPL 3 discussion draft 1 comments on section 7 (d),
http://gplv3.fsf.org/comments/gplv3-draft-1.html ; discussion draft 2
comments on section 7 b (4),
http://gplv3.fsf.org/comments/gplv3-draft-2.html ; discussion draft 3
comments on section 13, http://gplv3.fsf.org/comments/gplv3-draft-3.html ;
and discussion draft 4 comments on section 13
http://gplv3.fsf.org/comments/gplv3-draft-4.html .  See AGPL 3 discussion
draft 1 comments on section 13,
http://gplv3.fsf.org/comments/agplv3-draft-1.html , and discussion draft 2
comments on section 13, http://gplv3.fsf.org/comments/agplv3-draft-2.html
.  The rationale for AGPL 3 discussion draft 2 is especially informative
and may give further thoughts for objections in its intended scope,
http://gplv3.fsf.org/agplv3-dd2-rationale.html .

There are also many other scattered places in which people have commented
upon AGPL 3 especially during the drafting period.

Many objections are merely repeated from problems with early draft
language which had been discarded.  The long draft comment period at
various draft stages and the relatively short period for the final stage
reinforced some mistaken understanding of the language actually adopted
for the license.  The misunderstandings go back to drafts of GPL 3 in
which AGPL 3 had been directly included originally as a clause which could
be invoked as a requirement upon subsequent modifiers.  Near the end of a
long comment process AGPL 3 was separated in its own separately
identifiable license differing from GPL 3 in section 13.


1.2.  MJ RAYS OBJECTIONS.

MJ Ray has raised some principled objections when the issue has been
raised on the Koha mailing lists.  His objections are shared by others who
made them during the GPL 3 and AGPL 3 drafting process.

See his reply in the koha list thread Support for Koha,
http://lists.katipo.co.nz/public/koha/2009-August/019713.html .  See his
reply in the koha-devel list thread what about 3.2 improvements under AGPL
? ,
http://lists.koha-community.org/pipermail/koha-devel/2009-September/032830.html
.  I have considered all of the significant objections which I know that
MJ Ray made in the past  including those on debian-legal even if I do not
cite them all.

In 2007, MJ had been raising some objections which I understood to
actually be objections to all versions of the GPL.  I believe that MJ has
mostly moved on from those concerns and I only address one such recently
repeated objection.  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.


1.3.  JOSHUA FERRARO'S OBJECTIONS.

I have had discussions about GPL 3 and AGPL 3 with Joshua Ferraro during
the time the licenses were being drafted and shortly after the final
publication of the licenses.  I consider objections which he had expressed
to me from that time.

[At the time that LibLime was starting to break completely with the Koha
community and introduce LLEK, I privately encouraged Joshua to consider
the advantages of some terms of GPL 3 and AGPL 3 to address problems of
recognition and fairness of which he had complained to me.  Sadly, Joshua
no longer allowed himself the opportunity to have sincere discussion.]

Joshua's withdrawing himself from the Koha community may mean that he is
no longer a direct active member of the  community, but the objections
which I know he had held long ago to AGPL 3 deserve consideration for
anyone else who may sincerely hold similar concerns.  Despite Joshua's
recent history with the Koha community I take his past objections
seriously and do not doubt the sincerity of anyone who may hold those
objections in common.


2.  MEETING AT SFLC.

I had not raised all of the principal objections to AGPL 3 during my
meeting with Aaron at SFLC.  I only raised the ones which I have thought
may pose especially difficult legal problems during my meeting.

I try to treat all the most significant objections in this message,
irrespective of whether I thought them troublesome enough to raise with
Aaron.  I identify the difficult ones which I raised with Aaron and his
answers about them.  Those who think that I have been remiss by not
raising some issues with SFLC or not raising them at all should inform me
and or raise those issues with SFLC directly.

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.


3.1.1.  SPECIFIC COMPLIANCE BURDEN REMEDIES.

3.1.1.1.  SOURCE CODE MANAGEMENT REMEDY.

Any or all of several procedures could make compliance easy.  Version
control could be used for the source code of changes specific to a
particular installation.  A script could copy the running version from the
file system.  A feature could be added to Koha itself to copy the source
code.


3.1.1.2.  MULTIPLE NETWORK LINKS TO SOURCE CODE REMEDY.

Some drafts of the license had specified that access to the source code
had to be provided as part of the same network session.  Problems with
that draft language were obvious in that the language would have limited
the options for providing access to the source code without being
necessary to protect the interests of the user.  Such language did not
survive the revision process.

I have thought of using multiple links for the license requirement of
"providing access to the Corresponding Source from a network server at no
charge".  I had suggested that in a minimal standard of compliance only a
set of diffs to the upstream version would need to be made available in
addition to direction to the upstream version.  Obviously, the modifier
would need to synchronise his diffs with a particular upstream version
snapshot if not working from a release.

I find nothing in the license language would disfavour such a means of
providing access to the source code for a modified version.  Obviously, if
the upstream source code would cease to become available from some network
location, then users would need to be directed to another location.  Some
possible inordinately complex set of procedures for obtaining the complete
source code of a modified version would be prohibited as an obfuscation
but providing a set of diffs to an upstream version seems perfectly
correct and not obfuscation.  Diffs actually seem preferable to me for
easily identifying changes and creating a patch for building a particular
modified version.

MJ has objected that using direction to the upstream version along with a
set of diffs for modifications is not compliant with the license.  Aaron
also cautioned me.

Aaron understood that I had meant that a modifier of the upstream version
could maintain diffs which could be assured would be available from the
modifier's network node.  Additionally, the modifier would periodically
check that an additional link to the upstream version is working.  Those
running an unmodified version would merely link to the upstream version.

Aaron seemed to perhaps doubt the reliability of a periodic check that
access to the upstream version is working.  Perhaps he was worried about
the potential of a multiplicity of links to lead to an excessively complex
set of build instructions.  Aaron mostly seemed to worry that when the
modifier lacked control over the availability of the upstream version, the
modifier would then fail to have exercised the responsibility required by
the license.

Ultimately, Aaron said that SFLC would not support a position on an issue
which contradicts the intent of FSF in drafting the license.  FSF has
never accepted linking to an upstream version as satisfying the obligation
to make the source code available.


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.

MJ has presumed that limiting bandwidth to the source code would require
the license to have additional permissions allowing such a bandwidth
constraint.  The likelihood that modifications of a particular
installation with the inability to afford much of a bandwidth demand for
their source code might become a major target for obtaining the source
code for their version is small.  However, we should consider the
possibility with the knowledge that Koha is being used in some countries
with especially limited financial resources where the provision for
network connectivity extraordinarily limited.

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.

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.


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.


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.


3.2.  COMPLETENESS OBLIGATION.

AGPL 3 introduces an important difference for source code only conveyance.
 The GPL allows the conveyance of a non-functioning program or merely part
of a program and hence the Corresponding Source need only  match the
non-functional or incomplete program conveyed.  Use of a program over a
network under AGPL 3 necessarily implies that the program is functional
enough to use and is as complete as the provided use.  Consequently, the
Corresponding Source must be a complete functional work.

A non-functional or incomplete version of an AGPL 3 covered program may be
conveyed independently of the obligations to a remote user.  The
guarantees of the completeness of the Corresponding Source for actual
remote network users are not more than what what we should reasonably
agree that users ought to have.  The freedom to share small sections of
code is not infringed by the greater guarantees to remote network users.


3.3.  SECURITY CONFIGURATION.

Joshua had raised a security objection on the presumption that AGPL 3
requires revealing the security configuration information as part of the
source code for the running version of a particular Koha installation.

Security configuration should be stored in configuration files which need
not have their values included in the source code for the running version.
 Including generic default security configuration files in the source code
made available would be required if security configuration files need to
be used by the running program.  However, such files should not contain
the security values used for an actual installation as part of the
Corresponding Source.

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.


3.4.  DATA.

None of the FSF software licences cover data or the output of programs as
long as the data is not essential for running the program.  Configuration
files generated by running the program are simply not required.

Programs which output other programs, such as the compiler GCC, might be a
case where the output of a program might be regarded as data but might
also be presumed to be covered by the license.  However, the case of
programs as output is generally a question of the license for any linked
libraries of the compiled program rather than the license for the compiler
itself.

There was a case where the GPL 2 license for Open Office had been briefly
invoked with improper language or perhaps mistakenly embedded in output
documents.  [I do not remember the details.]  Somehow the invoking
language had been read to improperly impose a GPL 2 license on the output
documents.  The mistake in the license invoking language for Open Office
was quickly corrected.

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.


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.  They have not
been well tested over many years as GPL 2, which has had a 19 year
history.

Changes in GPL 3 and AGPL 3 from GPL 2 have been taken with the intention
of correcting for problems which have been found where GPL 2 terms had
been insufficient to protect users' rights in various circumstances over
the course of GPL 2 history.


3.5.1.  NOT COMPLETELY NEW.

Most of the substance of GPL 3 is inherited from GPL 2 with some
additional clarification of language.

Additionally, there are a set of options in GPL 3 section 7 for adding
additional terms to allow greater compatibility with other free software
licenses.  Options include adding a requirement to give attribution to
particular authors independent of copyright holders.  Each of the options
which allow for adding terms have been tested in the particular language
and history of other licenses.

GPL 3 section 11 is a new section for providing a limited form of patent
protection.  The new section was inspired by the patent protection terms
from Apache License 2.0 which had been introduced in 2004.

GPL 3 section 13 allows incorporating a GPL 3 work into an AGPL 3 work. 
AGPL 3 section 13 is a new section for protecting the rights of software
users' over a remote network.  AGPL 3 terms are otherwise exactly the same
as GPL 3 terms.  The new section is modeled on the small experiment of
AGPL 1 from 2002.  AGPL 1 had a much smaller scope from lacking GPL
permission to include GPL covered work within an AGPL 1 program.

The collection of terms together and the particular language of GPL 3 and
AGPL 3 is new as of three years ago.  Even where terms have been inspired
by other licenses, the terms as expressed in GPL 3 and AGPL 3 are
different.


3.5.2.  TESTS FROM ADOPTION.

All of the core GNU projects have upgraded to GPL 3 to my knowledge.  Many
other projects have upgraded to GPL 3 and it may now be the most popular
choice for new free software projects.  GPL 3 may be used by twenty
percent of active free software projects and a little less than half of
GPL free software projects, although, the portion of total free software
projects is very small.  Remember that the vast majority of free software
projects are abandoned.  I have not been keeping score but have made some
conjecture from clues which I have seen.

AGPL 3 projects at least number in the hundreds.  Very few AGPL 3 projects
are prominent.  StatusNet (formerly Laconica), the software underlying the
Identi.ca microblogging service is probably the most prominent AGPL 3
software.

Black Duck Software has some useful statistics taken from a wider range of
sources than any other set of statistics,
http://www.blackducksoftware.com/oss/licenses/ .  Black Duck also has a
list of projects using GPL 3, AGPL 3, or LGPL 3,
http://www.blackducksoftware.com/oss/project-list .

For greatest length of history in widely used software, most of the core
GNU projects have at least a two year history using GPL 3.


3.5.2.  TESTS IN COURT.

I do not know of any case where GPL 3 or AGPL 3 have been tested in court.
 The number of cases where GPL 2 have been tested in court is very small.

A copyright license which helps keep everyone out of court should be
considered much more successful than one which draws people into court. 
The belief that license terms are enforceable in court is sufficient for
the license to be effective.


3.6.  COMPULSION OR COOPERATION.

Every license and every contract depends upon the goodwill of the parties
entering the agreement.  There are always evasions which those choosing
not to cooperate can use.  Social responsibility and social pressure
provide the cohesion which binds parties in a manner which legal documents
cannot.

Legal documents provide an agreed formal method for binding the social
cohesion of parties.  Legal documents also provide for less effective and
much more expensive force of law remedies for some failures of social
binding.

The FSF licenses are designed to encourage and reinforce the natural
social desire of people to cooperate.  The fact that the licenses have
some language of compulsion is a function of their nature as legal
documents in which law is meant to be enforceable.  Accepting a copyright
license is still the voluntary choice of the user in the context of
copyright law where the user otherwise may have nothing other than fair
use or fair dealing rights to the copyrighted works of others.  Users have
the free choice of what software to use and consequently what copyright
licenses to accept.

MJ raises an objection to the compulsion of cooperation from the language
"ensure cooperation" in the AGPL 3 preamble.  However, "guarantee your
freedom to share" and "you must give the recipients all the rights that
you have" in the language used in the GPL 2 preamble has the same
expression of compulsion of cooperation.  Identical and similar language
is present in other parts of the AGPL 3 and GPL 3 preamble such as
"guarantee your freedom to share" and "you must pass on to the recipients
the same freedoms that you received".

If all the language in the license would be entirely permissive and wholly
dependent upon voluntary cooperation, then the license would be tantamount
to placing a work in the public domain.  Cooperation over the public
domain is strictly voluntary.

The language of compulsion serves as a helpful reminder when there are
difficulties of cooperation.  The potential of enforceability helps
parties who do not know one another to establish a basis of trust needed
for cooperation because they know that they are bound by the same terms.

Some people have asserted that free software would fare better if there
would be no copyright law to protect intellectual work.  In the absence of
the restrictions of copyright law, I suspect that there would be more
secrecy over source code for lack of a basis of trust by unknown parties
not more cooperation of an imagined utopia.


3.7.  EFFECTIVENESS.

MJ Ray has claimed that AGPL 3 is easily evaded and ineffectual.

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.

Almost every license has some scope for evasion.  Those intent upon
violating a license are most usually merely seeking an expedient
disregarding the rights of users without taking the time to be careful
about implementing an evasion which would not be identified.  The worst
GPL 2 violations have shown great carelessness even where they have
attempted to disguise the violation.

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

Google has a business model based on providing remote network use of
software which is often a derived work of GPL software.  Google is so
opposed to AGPL 3 that during the GPL 3 drafting process they had
threatened to fork all GPL software at GPL 2 if an optionally invoked
requirement covering network services would be included in GPL 3 as it had
been in early drafts.  Google refuses to host AGPL 3 projects on Google
Code and has purged projects which have been unaware of the restriction on
Google Code.  Google believes that AGPL 3 is at least sufficiently
effective to take such an extreme position.  Google has also recently
preferred the BSD three clause license to any GPL license.

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.  The major
businesses participating in the drafting of GPL 3 all have policies to
avoid AGPL 3 because people at those companies believe it to be a
sufficiently effective threat to some business model which they may choose
to pursue.

Some people at various companies have also feared accidental triggering of
AGPL 3 terms.  Such a concern has prompted FSF to give an interpretation
that only works expressly designed for network use qualify for AGPL 3
coverage.  The FSF interpretation may be a reasonable practical
reassurance but may go further than an objective neutral legal
interpretation of the license.

Precisely because there is some means of compulsion to which MJ objects,
the license has a legal means to be effective.  As stated above for the
issue of compulsion, all law depends upon the good will and cooperation of
those agreeing to abide by the law.  Any effective copyright license
reinforces people's interests in cooperation over respecting each others'
rights.


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.  Yet, the same minimal standard of compliance satisfies any
version of the GPL.

Obtaining a tarball with hundreds of thousands of lines in various files
is preferable to not having any opportunity to obtain the source code.

We would all rather not be constructing diffs from various installations
of Koha against the main git repository to identify what is different and
how the difference functions.  However, we should be aware of the
reasonable limitations of any general purpose license.  We should not
reasonably expect the license to require our particular preference for
version control software.

The license will help us to a certain degree.  The remainder of what we
need for a vibrant free software community must come from social and
economic reinforcement of the cooperation which everyone values.


Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY  10003
USA
http://www.agogme.com
+1 212-674-3783