[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-tm... . 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/Cont... . 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/cr... . 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... . 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@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@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha