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

[Thomas Dukleth]

[This is the first of about three messages which I intend to send today
reporting on the current state of my seeking answers from the SFLC about
copyright licensing of Koha.]

I have re-examined copyright licensing in Koha and enquired with the
Software Freedom Law Center (SFLC) about the current licensing and what
would be involved in upgrading the base license.  There are some tentative
conclusions from my examination of the state of licensing in Koha and
current progress of my discussions with Aaron Williamson at SFLC.  I met
with Aaron last week to thoroughly discuss my findings and the questions
which I had posed via email.  A few more days will still be needed to have
a more complete response from SFLC including consultation between Aaron
and Eben Moglen, who has been travelling.

While I personally advocate upgrading the license of Koha to AGPL 3, I
think that we should be especially careful about considering how we might
take such a change legally to ensure that we give the same respect to the
license choices of others as we expect others to give to our license
choices.  I want to be especially sensitive to respect the views of anyone
who may object to such a change.  In examining the basic legal issues, I
have made a modest effort to be generally neutral and give problems the
attention which they are due.

I greatly appreciate the effort which Aaron has taken to consider some
difficult questions more deeply where some of his initial answers seem
confusing and unsatisfactory to me.

I present my findings and the answers which I obtained following each
question further below.  Some very important issues await further
clarification from SFLC and also FSF.  I have used the text of my message
to SFLC with some additional explanation which I introduced at my meeting
with Aaron interfiled with a report of our discussion.  [I will provide
the exact text of my original message to SFLC, if anyone is interested,
but I assume that most people would prefer to not read essentially the
same words twice.]

I will write a separate message treating objections which have been raised
to AGPL 3 and reporting my discussion of them with Aaron.

I will also post the message which I sent to Aaron following my meeting
with him in which I have sought additional clarification for answers over
which I had doubt and treatment of the one question which we did not have
time to discuss properly.  Remaining issues for which I have been seeking
answers are as follows.  How might my interpretation of derivative works
as applied to software be mistaken?  Is Koha currently a derivative work
of MySQL?  [Raised as question 2 further below.]  What would the
Corresponding Source obligation be for Koha?  [Raised as question 5
further below.]

I have not made an attempt to summarise the issues.  While further
responses providing clarity are pending, I think that an attempt to
summarise such important issues of copyright licensing would be much too
liable to be misleading.  When I have clarity from further response from
SFLC, I could then hope to summarise the issues reasonably.


1.  CONSIDERATION TIMING.

I had previously assumed that the Koha project would wait until first
resolving any dependency problems before formally considering upgrading
the license for the work as a whole under AGPL 3, with an or later version
option, or GPL 3, with an or later version option.  [Perhaps my
presumption was somewhat wishful thinking from my desire to delay an
adverse discussion with the one Koha community member who is known to have
strong principled objections to AGPL 3.]  However, a few developers are
now strongly advocating changing the licensing of Koha to AGPL 3, with an
or later version option, and seem to have the support of most all of the
active developers based on a straw poll at the May Koha IRC meeting.


2.  MOTIVATION.

Presumptions about motives are usually unhelpful in determining what
action to take.  If there is a danger that some motive might lead to an
insufficiently considered decision, then some attention should be given to
possibility of confusion from motives.

The current advocacy for AGPL 3 as a license for Koha is certainly
informed by the appearance of LibLime Enterprise Koha (LLEK) which is only
provided as a remote hosted service for which the users cannot exercise
user freedom over the software because they have no access to the source
code.  Happily, enough time has now past from the appearance of LLEK that
current advocacy for AGPL 3 should no longer be taken as an insufficiently
considered reaction to the sudden appearance of LLEK.


3.  QUESTIONS.

3.1.  CURRENT COPYRIGHT LICENSING IN KOHA.

Q.1.  Is Koha copyright licensing currently applied correctly?

A.1.  Aaron said that we ought to give some attention to improving the
correct uniform application of licensing in Koha as part of our effort to
consider upgrading the license and in preparation for that possibility.

See my findings in section 4 further below.


3.2.  MYSQL GPL 2 ONLY INVOCATION.

Q.2.  Are database calls necessary for the functioning of Koha, which are
coded expressly for MySQL, an obstacle to upgrading the licensing of Koha
to AGPL 3 or GPL 3 with an or later version invocation?

[During the drafting of GPL 3, MySQL changed license invocation statements
from GPL 2, with an or later version option, to simply GPL 2, removing the
option of users to modify and redistribute their modifications under GPL
2.

The invocation of GPL 2 for MySQL  includes a narrow exception to GPL 2
for creating MySQL client programming libraries under a specific list of
licenses which are more permissive than GPL 2.  This exception is
currently named the Sun FOSS License Exception,
http://www.mysql.com/about/legal/licensing/foss-exception/ .  GPL 3 and
AGPL 3 are more restrictive licenses than GPL 2, with the intent of
maintaining the protection of user freedom under more circumstances, and
are thus incompatible with GPL 2.  Neither GPL3 nor AGPL 3 are included in
the list of licenses for the Sun FOSS License Exception, and as more
restrictive licenses than GPL 2 they would not be listed.

MySQL AB had a business model based on selling proprietary licenses to
MySQL.  They had been well known for asserting that all programs
containing calls to MySQL are derivative works of MySQL and must either
also be licensed under the GPL or a proprietary license to MySQL must be
purchased.  MySQL AB or their successors, Sun and now Oracle, may have
never accused a program using MySQL with GPL 3 or AGPL 3 from violating
the terms of their last choice of GPL 2 only as the license for MySQL. 
Such a claim against a GPL use which does not match Oracle's continued
choice of GPL 2 only for MySQL might never be much of a risk, even if
merely to avoid adverse publicity against Oracle.]


A.2.  Aaron did not agree with my presumption that Koha is currently in
part a derived work of MySQL.  He used arguments about separate processes
of Koha and MySQL.  He was somewhat dismissive of MySQL specific calls in
Koha which do not incorporate MySQL source code or change the
functionality of MySQL at a low level in C or C++.

I thought that some of Aaron's suggested analysis of distinguishing Koha
as a separate work from MySQL with no derivative work relationship was
mistaken.  Whether a separate process is spawned was unconvincing as an
argument and did not account for programs which are accepted as a single
program and spawn multiple processes.  Express dependency on MySQL seemed
sufficient to me to establish a derivative work relationship.

Even if my presumption might be correct, Aaron seemed fairly confident
that there would never be a problem from Oracle over Koha using GPL 3 or
AGPL 3 as a license violation of GPL 2.  Perhaps more importantly, he
considered the possibility that some other party might make a similar
claim against Koha as fanciful.

If GPL 3 or AGPL 3 would be quickly adopted as the base license for Koha,
I accept that claims by third parties against the Koha community for using
MySQL in violation of GPL 2, would be fanciful and an adverse party would
be unlikely to have standing to bring such a claim.

Neither FSF nor SFLC had ever contradicted the claims of MySQL AB that
calls to MySQL mean that the calling program is a derived work of MySQL. 
Aaron answered that SFLC never had a client over which MySQL AB had made a
problem.  I explained to Aaron, that if SFLC did not believe that Koha is
presently a derived work of MySQL, if Koha would change to GPL 3 or AGPL
3, and if Oracle would happen to notice and decide to cause a problem in
relation to GPL 2 only licensing of MySQL; then SFLC should be prepared to
defend Koha's use of GPL 3 or AGPL 3.  Aaron conceded that he was not
perfectly confident that there could never be a problem over database
calls with incompatible versions of the GPL and that he could speak to
Eben Moglen, who has a better historical familiarity with the assertions
of MySQL AB.

Ultimately, I am concerned that we are careful about upgrading the license
for Koha to ensure that we give the same respect for the license choices
of others that we would hope to have from others over our own license
choices.  The consideration of license choice for Koha should not be
limited to what works in a cooperative free software community in which no
adversaries are expected.  Koha licensing should also be legally safe.

A fuller answer is deferred for Aaron's consultation with Eben Moglen.


3.3.  LICENSE UPGRADE PROCEDURE.

Q.3.  What would be the best procedure for upgrading the license
invocation of Koha from GPL 2, with an or later version option, to AGPL 3
or GPL 3, with an or later version option?

A.3.  Aaron said that how we proceed with a license upgrade is largely a
matter of what works politically within our community.

The practise adopted for upgrading the license ranges from very casual to
much more careful depending on the practise of the community.  I pressed
Aaron for what would be the safest method legally, independent of
community politics.

Aaron recognised from my findings of the current state of licensing in
Koha that we have some details to consider about applying licensing first
for GPL 2.  My suggestion about how to proceed if we choose to upgrade the
license follow.

We should invoke the license uniformly under GPL 2, with the or later
version clause, where necessarily applicable.  Many files do not have
license headers but are understood to be under a particular license from
their original commit which would most usually be GPL 2, with an or later
version option.  License headers should be added where they are missing. 
Files which are GPL 2 only should have headers identifying them as such. 
Some files, such as configuration and sample data files may not be
applicable to copyright.  I should add a follow up question about how best
to label uncopyrightable material.

See section 4.2.2.2 for the OpenNCIP and Open SIP2 implementation files
derived from Georgia PINES which we have discovered may be GPL 2 only but
have no license headers.  Aaron suggested that the code repository of
Geogia PINES should be examined to see if we may be misinterpreting a
particular license header where the work may actually be GPL 2, with an or
later version option, and some header may merely have been an unintended
mistake.  Other options are given in section 4.2.2.2.

Once we have defined the set of files for Koha as GPL 2, with an or later
option invocation, or other more permissive licenses, then we could change
all the headers to conform to a new license.  At the other extreme, we
could wait until we had GPL 3 or AGPL 3 specific code modifications before
changing specific headers.  I favour being sensitive to the original
license choices of those contributing work which is otherwise used
independently from Koha.  I also favour being sensitive to files last
edited by objectors to a license change for the project as a whole.  I
suggest a method of respecting the sensitivities of objectors in section
4.1, Copyright Holders.

See the SFLC whitepaper on respecting other license choices within a GPL
project.  Maintaining permissive-licensed files in a GPL-licensed project
: guidelines for developers / [Software Freedom Law Center, Inc.]. - 2007.
-
http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
.


If adopting AGPL 3, we should provide a mechanism for making compliance
easy for modifiers.  Significant compliance issues will be treated in my
message about objections to AGPL 3.


3.4.  GPL 3 TRANSITIONAL STEP TO AGPL 3.

Q.4.  If the license invocation is upgraded from GPL 2, with an or later
version option, to AGPL 3, with an or later version option; is it
necessary to first upgrade to GPL 3, with an or later version option, as
an interim step?

A.4.  Aaron said that the Koha community could choose whatever degree of
formality about upgrading to AGPL 3 as the community would find
appropriate.

He suggested that a note in an official blog that Koha would be making a
transitional change to GPL 3 before changing to AGPL 3 should be
sufficient.  I think that would should formally record any temporary
change to GPL 3 in the git repository before changing to AGPL 3.


3.5.  DEPENDENCIES NEEDING INCLUSION IN CORRESPONDING SOURCE FOR KOHA.

Q.5.  What would constitute the  'Corresponding Source' for Koha in terms
of dependencies, which would necessarily be part of the work as a whole
for Koha, but which are widely distributed as works as whole in their own
right with no relation to Koha in most contexts?

[Clarity on how the work as a whole necessarily includes dependent works
which also have uses independent of the work as whole is needed.  Some
direction about the scope of exceptions to Corresponding Source is needed
to help avoid improper overly broad or overly narrow misinterpretations. 
'System Libraries' including any essential 'Major Component' of the
operating system are exceptions.  The qualification "which are not part of
the work" limits the exception of "general-purpose tools or generally
available free programs which are used unmodified in performing those
[running and modification] activities but which are not part of the work".
 Direction may merely reinforce the obvious but that direction would still
be helpful.

Perhaps Apache would be excluded from the Corresponding Source as a
generally available free program used to run a work designed to run on a
web server.  Some may want to exclude MySQL even if it is the particular
database program expressly required.  Some may want to exclude generally
available but expressly required Perl modules.

Certainly, copyright law governs what constitutes the work.  The license
can specify exceptions to its requirements to allow the practical
realisation of its intent.

We need guidance on understanding the intended exceptions to avoid the
temptation to misinterpret the scope of exceptions to Corresponding Source
in an overly broad manner for practical expediency.  On the other side,
there may be a temptation to interpret the scope of exceptions too
narrowly and impose an unnecessary burden on compliance.  Significant
misinterpretation may risk undermining the meaning of the license which
helps the community function within a legal framework.]

A.5.  My meeting with Aaron ran out of time when we were starting to
discuss dependencies in the Corresponding Source for Koha.  Aaron was
clear that that what needs to be included in the Corresponding Source is
the same for AGPL 3 as it is for GPL.

In considering MySQL, Aaron had implied that MySQL would be excluded as
part of the Corresponding Source currently.  However, he will be
consulting with Eben about MySQL.

Perl module dependencies which are not part of the most basic Perl
installation would necessarily be included as part of the Corresponding
Source even following the analysis which Aaron presented for excluding
MySQL.  Whether the dependencies of the Perl modules themselves, such as
Yaz as a dependency of Perl zoom would also be included in the
corresponding source is uncertain in the same analysis.

I am waiting on clarification of the issue for dependencies in general;
MySQL in particular; and also Perl modules and their dependencies in
particular.


3.6.  OTHER QUESTIONS.

Examine my forthcoming other posts about clarifications and other
questions which I have put to SFLC especially in relation to objections to
AGPL 3.  I will be happy to pursue answers to any questions which others
may wish to put to SFLC from my local proximity to SFLC.  Anyone should
also be free to contact Aaron Williamson directly.

Aaron Williamson
Counsel
Software Freedom Law Center
1995 Broadway, 17th Fl.
New York, NY 10023
(212) 461-1911 direct
(212) 580-0898 fax
www.softwarefreedom.org


4.  CURRENT RELEVANT ISSUES.

4.1.  COPYRIGHT HOLDERS.

The copyright of the code is distributed amongst individual contributors. 
There is no collective assignment of copyright.

Some contributors might not be found to give their ascent to any license
upgrade of the base license for the project as a whole.  Some contributors
may either not ascent to upgrading the base license for the project or may
object.

In cases where individual contributors to particular files object to a
license upgrade for the project as a whole, great sensitivity should be
shown to their preference.  If needed, one way of showing deference to
possible sensitivities about a licensing upgrade may be to wait until
there is a new modification of code function for individual files to which
a license upgrade objector had been the last contributor before making any
upgrade to the license header for those individual files.


4.2.  COPYRIGHT LICENSE.

4.2.1.  LICENSE NOTICES.

Very many Koha files have a uniform copyright header invoking the license
as GPL 2 with an or later version option.

Many files have no copyright header but are understood to be licensed
under GPL 2 with an or later later version option for the other files with
which they are used.  Many of the files without copyright headers were
originally contributed with other files containing copyright headers. 
Other files without a copyright headers have been added with a presumption
that their license conforms to the license for the parts of Koha to which
the new file has been added.

There have been some imprecise references to the license version in the
documentation and in the code.  Given, some GPL 2 only dependencies
perhaps there is a problem stating the intention of the code.  A
clarification may be needed adjacent to the link to the GPL 2 license for
the about page ensuring that the or later version option would not be
missed,
http://git.koha-community.org/cgi-bin/gitweb.cgi?p=koha.git;a=blob;f=koha-tmpl/intranet-tmpl/prog/en/modules/about.tmpl
.  There are actually several errors of detail in the about page which is
largely ignored by programmers. 
http://git.koha-community.org/cgi-bin/gitweb.cgi?p=koha.git;a=blob;f=README
.  It is my understanding that there has historically been no real
controversy that contributors have intended the license to be GPL 2, or a
later version at the option of the user, whenever contributors have given
the issue any thought.  Possibly inaccurate or ambiguous statements which
have appeared in some help files merely represent insufficient attention
to detail in referring to the license without a completely formal manner.

There is a license file containing the text of GPL 2,
http://git.koha-community.org/cgi-bin/gitweb.cgi?p=koha.git;a=blob;f=LICENSE
.


4.2.2.  GPL 2 ONLY DEPENDENCIES.

Dependencies have licenses understood to be compatible with GPL 2 and not
incompatible with GPL 3 or AGPL 3 except for two dependencies which are 
incompatible with GPL 3 and AGPL 3.  Those upgrade incompatible
dependencies are GPL 2 only dependencies.


4.2.2.1.  MYSQL DEPENDENCIES.

MySQL is a GPL 2 only dependency for which there are MySQL only calls
required for the software to function.

While most database calls are fairly ANSI compliant, the installation
requires MySQL 5 and use the Perl module DBD::mysql not DBD::Pg.

Some incomplete beginnings of Postgres support had been added to the code
at one time but there are incomplete, have not been maintained, and would
not work without extra work by the user to supply missing support,
especially for installation.

The basic code to which calls to the SQL database are sent is in Koha's
C4::Context,
http://git.koha-community.org/cgi-bin/gitweb.cgi?p=koha.git;a=blob;f=C4/Context.pm
.

MySQL specific calls include all calls to InnoDB,
http://git.koha-community.org/cgi-bin/gitweb.cgi?p=koha.git&a=search&h=HEAD&st=grep&s=InnoDB
.  There is a backup script which calls mysqldump,
http://git.koha-community.org/cgi-bin/gitweb.cgi?p=koha.git;a=blob;f=misc/cronjobs/backup.sh
.

The above list of MySQL specific features in Koha is not necessarily
exhaustive.

Options for overcoming the problem of GPL 2 only code expressly designed
for MySQL without sufficient alternatives seem to be limited to rewriting
code and / or adding new code supporting other database options as an
alternative to MySQL exclusively.

[As reported further above, Aaron in his answer to me did think that the
MySQL dependency is an obstacle to upgrading the license of Koha
currently.  I suspect that Aaron's analysis is mistaken about MySQL and I
have sought further clarification from Aaron.]


4.2.2.2.  CODE FOR OPENNCIP AND OPEN SIP2.

Code modified from the Georgia PINES integrated library system,
http://gapines.org , is the other GPL 2 only dependency which is
[incomplete by my information] programming library code intended to
support automated circulation  standards for Open NISO Circulation
Interchange Protocol (OpenNCIP) and the Open Standard Interchange Protocol
(Open SIP2).

The code for OpenNCIP and Open SIP2 modified from Georgia PINES does not
have any license headers.  Where the GPL 2 only invocation from which that
code is derived differs from the GPL 2, with an or later version option,
invocation for other parts of Koha and there are no notices for the
difference; then notices must be added clarifying the distinction.  ved
work of GPL 2 only code and the files are distributed with Koha for which
there is presumption that files without copyright headers are intended to
be licensed under GPL 2, with an or later version option, there may be a
license violation currently which we should fix.  No one would be
antagonistic about this issue but we should fix the problem of missing
notices for such code to avoid creating confusion.

Code for OpenNCIP / Open SIP 2
http://git.koha-community.org/cgi-bin/gitweb.cgi?p=koha.git;a=tree;f=C4/SIP
.

Options for overcoming the problem of the GPL 2 only code derived from
Georgia PINES include:  persuade the copyright holder, the Georgia Public
Library Service, to update the license invocation terms to add an or later
version option; remove the code from an AGPL 3 or GPL 3 distribution of
Koha; rewrite the code such that it would no longer be a derived work of
the Georgia PINES code, perhaps code derived from Evergreen could serve
the same purpose.


4.2.3.  OTHER DEPENDENCIES.

Dependencies are listed in the various installation files such as the
instructions for a Debian GNU/Linux installation,
http://git.koha-community.org/cgi-bin/gitweb.cgi?p=koha.git;a=blob;f=INSTALL.debian
.

There is a report of licenses in Koha which uses some unknown deficient
automated code parsing method for identifying licenses of code in Koha,
http://www.ohloh.net/p/koha/analyses/latest .

Unlike the mistaken claim on the ohloh website, there is no four clause
BSD licensed code or dependency of Koha.

The required Perl dependencies and their dependencies in turn are all
available under GPL 2, with an or later version option; or permissive
Artistic or three clause BSD licenses.  The Artistic license and the three
clause BSD licenses are a permissive licenses with no problems for
upgrading the larger work as a whole from GPL 2 when the Artistic or three
clause BSD licensed code is a part of the work as a whole.

Koha uses two JavaScript libraries, jQuery and Yahoo User Interface
Library (YUI).  Both JavaScript libraries have licenses which allow
upgrading to GPL 3 or AGPL 3.

jQuery has disjunctive dual licensing for which the MIT/X11/Expat [choose
your prefered name] license is available as well as GPL 2 only.  The
MIT/X11/Expat license is a permissive license with no problems for
upgrading the larger work as a whole from GPL 2 when the MIT/X11/Expat
licensed code is a part of the work as a whole.

YUI is licensed under the three clause BSD license.


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


On Wed, June 2, 2010 16:13, MJ Ray wrote:
> Chris Nighswonger <cnighswonger at foundations.edu> wrote:
>> Given that this discussion has been somewhat carried on through the
>> wiki (http://wiki.koha-community.org/wiki/General_Meeting,_June_2_2010),
>> I thought it would be good to keep it on list as well.
>
> I only added a link back to this thread.  No new discussion was raised
> there.  I agree that it's good to keep it nearly all on list.
>
> Small update on the above from the meeting: thd will be emailing the
> list with a summary of discussions he's had with SFLC.
>
>> [...] A vendor would have to deliberately remove or disable
>> this functionality to prevent a client from retrieving a full copy of
>> their database.
>
> Of course any vendor locking clients in will disable that!
>
>> (Of course any client who contracts with a vendor
>> *without* writing data protection assurances into their contract is
>> asking for trouble to start with.)
>
> I feel that any client who contracts with a vendor without writing
> code access assurances in to their contract is asking for trouble to
> start with.  AGPLv3 is unnecessary with good vendors and does not
> prevent lock-in vendors from locking clients in.  Basically, it's much
> pain for no gain.
>
>> The matter of "onerous burdens on friendly hosters" has been addressed
>> in previous communications and so those arguments are not repeated
>> here.
>
> Yes, it's been addressed, not answered.  Let's see what thd reports.
>
> Regards,
> --
> MJ Ray (slef)  Webmaster and LMS developer at     | software
> www.software.coop http://mjr.towers.org.uk        |  .... co
> IMO only: see http://mjr.towers.org.uk/email.html |  .... op
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>
>