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