Hi, On Sun, May 9, 2010 at 10:37 PM, Lars Wirzenius <lars@catalyst.net.nz> wrote:

* It would further simplify things if there is an explicit policy that all code included in the project should be using the same license, or at least that all new code will use the same license. At the very least all licenses used by Koha should be compatible with each other.

Since Koha embeds the source for some third-party libraries, compatibility of the overall license chosen for Koha is the best that could be achieved for that kind of code.

* The copyright ownership of each file is a bit hidden. The copyright statements (years, owners) in each file do not seem to reflect actual status. This should be cleaned up at some point. Luckily, git has every change, correctly attributed, it seems, so it's just some hard work that needs to happen. This is somewhat unrelated to a license switch, but it's going to be important at some point, so it'd be good to keep it on the table.

As a related note, I'd like to gently remind contributors that if you are adding a new file, please don't blindly copy over the 'Copyright 2000-2002 Katipo Communications' statement unless your contribution is archeological in nature.

* GPL version 3 is the updated version of GPL version 2. The spirit is the same, most of the conditions are the same, but many of the details have changed. Where GPLv2 was written in an era of mailing data tapes around, GPLv3 is written in the modern world. In my opinion, the changes are for the better, but that is a personal opinion. I don't have a pointer to a summary of the changes; perhaps someone could dig one up?

A bit verbose, but: http://gplv3.fsf.org/rms-why.html

* GPLv3 and AGPLv3 allow mixing, we don't have to choose just one, but it'd be simpler to do so. However, it might be reasonable to have some of the backend code be GPLv3 to allow other projects to use it more easily. For example, the SIP2 implementation?

That points to a problem. Koha's SIP2 implementation is actually a fork of OpenNCIP [1], and I would like to merge in Koha's changes at some point and remove the fork. But even if the fork never gets resolved, there's a problem: OpenNCIP's license is GPL2, not GPL2+. As GPL2 and GPL3 are incompatible licenses, if we license Koha using the GPL3+, we couldn't use Koha's SIP2 support code until either OpenNCIP is relicensed to GPL2+ or we get specific permission from the original copyright holder (the Georgia Public Library Service). [1] http://sourceforge.net/projects/openncip/ Regards, Galen -- Galen Charlton gmcharlt@gmail.com

Hi, 2010/5/10 Chris Nighswonger <cnighswonger@foundations.edu>:

Or (better yet) simply ensuring that all such modified code is immediately contributed to the main code base would also seem to satisfy this requirement.

No, it wouldn't - not all contributions would (or should) get accepted into Koha's main line, and a series of patch messages in the koha-patches archives does not constitute a "standard" means of sharing software IMO. If Koha becomes licensed under the APGL3, a hosting firm would be entirely entitled to simply set up an FTP server that supplies tarballs of their customized versions of Koha. While publishing a public Git repository would be a better way of sharing such code, we can't mandate it or require that contributions be sent back to the project. Regards, Galen -- Galen Charlton gmcharlt@gmail.com

On Mon, May 10, 2010 at 1:25 PM, <david@lang.hm> wrote:

The requirement of the AGPL to provide the exact source code running that version will be seen as a problem to many security people.

There are many cases where orginizations will not upgrade immediatly on the release of a new version. Anything that requires that potential attackers can see exactly what you are running greatly magnifies the risk, especially for something that is going to be Internet accessable.

As a result, I would expect that moving to AGPL would hinder the acceptance/deployment of the project, not help it.

Then we already have a huge security problem given that all forms of Koha are currently available in a public repository and in all likelihood the vast majority of users are running it with no security significant changes made. (AAMOF, many run it with default the username/password still in place!)

As for moving from GPLv2 to GPLv3, what is the reason for making the move? is there code that you want to merge (either way) with a GPLv3 project?

Please read my original proposal for the reasoning behind the move.

It's already been posted that you use code from a GPLv2 project, so you would have to get that project to move to GPLv3 (or 2+) to continue using their code.

Koha is currently licensed under GPLv2 or later with the exception of OpenNCIP. This is not a blocker, but rather a "bug" to be "fixed." There are no show-stoppers to the move to GPLv3/AGPLv3.

Is the code that you will get from moving to GPLv3 worth the loss of the code that you currently get from GPLv2?

We will loose know code afaik in such a move. Please cite examples.

Do all the contributers agree with relicensing their code under GPLv3?

Every contributor who licensed their code under the "GPLv2 or later" clause agreed from the outset. So there is no need to secure any permission to change licenses.

The FSF claims that the GPLv3 is in the same spirit as the GPLv2, but many programmers disagree (which is why many codebases remain GPLv2)

What is the specific behavior that you think is happening under the GPLv2 that you think will be blocked by the GPLv3? I am not a contributer, just a lurker (not even running the program, yet..) but I have not seen any behavior being discussed that would be blocked by the GPLv3.

Again, please re-read my original proposal for the why and wherefore. Kind Regards, Chris

On Mon, 10 May 2010, Chris Nighswonger wrote:

On Mon, May 10, 2010 at 1:25 PM, <david@lang.hm> wrote:

...

The requirement of the AGPL to provide the exact source code running that version will be seen as a problem to many security people.

There are many cases where orginizations will not upgrade immediatly on the release of a new version. Anything that requires that potential attackers can see exactly what you are running greatly magnifies the risk, especially for something that is going to be Internet accessable.

As a result, I would expect that moving to AGPL would hinder the acceptance/deployment of the project, not help it.

Then we already have a huge security problem given that all forms of Koha are currently available in a public repository and in all likelihood the vast majority of users are running it with no security significant changes made. (AAMOF, many run it with default the username/password still in place!)

it's not the same thing to have all the released and development versions of the code available and to have a link from the running system to say 'this is the exact version of the code, with all patches and local modifications, that is currently running' David Lang

On Tue, 11 May 2010, Lars Wirzenius wrote:

On ma, 2010-05-10 at 11:46 -0700, david@lang.hm wrote:

...

it's not the same thing to have all the released and development versions of the code available and to have a link from the running system to say 'this is the exact version of the code, with all patches and local modifications, that is currently running'

It is true that local modifications may introduce security problems, but it is way more likely that there is a problem in the Koha code that everyone else is using as well. And the attacker does not need to know which version the target is running, they can just blindly try every known Koha security problem on every Koha site. That's what computers are for, automating boring things.

So I don't think it is particularly important for security whether the code is out there or not. You are either vulnerable to a specific attack or you're not, and if you are, you're living on borrowed time. Frequent security updates are key to server survival on the public Internet.

Can we put this sub-thread to rest now?

I disagree with your evaluation, and I'm calling out that I believe that many other people will as well. I especually expect to see problems from security people who do not have that much experiance with opensource programs. I don't expect that you will see specifc complaints from such people, I expect that instead what will happen is that Koha would just get eliminated as a possibility early in the process due to the use of AGPL. I'll drop this now, but I hope you don't go that route. David Lang

On 11 May 2010 12:29, <david@lang.hm> wrote:

On Mon, 10 May 2010, Chris Nighswonger wrote:

...

On Mon, May 10, 2010 at 1:25 PM, <david@lang.hm> wrote:

...

As for moving from GPLv2 to GPLv3, what is the reason for making the move? is there code that you want to merge (either way) with a GPLv3 project?

Please read my original proposal for the reasoning behind the move.

I've gone back and dug it up from the archives.

What is the code that you want to merge that is under the AGPL?

...

...

It's already been posted that you use code from a GPLv2 project, so you would have to get that project to move to GPLv3 (or 2+) to continue using their code.

Koha is currently licensed under GPLv2 or later with the exception of OpenNCIP. This is not a blocker, but rather a "bug" to be "fixed." There are no show-stoppers to the  move to GPLv3/AGPLv3.

If this is the case, all you need to do is to eliminate any GPLv2 code and merge one piece of AGPL code and the result can only be distributed under the AGPL.

This will de-facto change the code from the current GPLv2 license (due to the inclusion of GPLv2 only code) to AGPLv3 (due to the inclusion of AGPLv3 only of AGPLv3+ code)

If this is the reason, then you are really not considering GPLv3 as a license.

...

...

Is the code that you will get from moving to GPLv3 worth the loss of the code that you currently get from GPLv2?

We will loose know code afaik in such a move. Please cite examples.

Others have posted some existing GPLv2 code that would need to be replaced.

...

...

The FSF claims that the GPLv3 is in the same spirit as the GPLv2, but many programmers disagree (which is why many codebases remain GPLv2)

What is the specific behavior that you think is happening under the GPLv2 that you think will be blocked by the GPLv3? I am not a contributer, just a lurker (not even running the program, yet..) but I have not seen any behavior being discussed that would be blocked by the GPLv3.

Again, please re-read my original proposal for the why and wherefore.

From the message I found in the archives (http://lists.katipo.co.nz/pipermail/koha/2010-May/023803.html), it sounds like you believe that moving to AGPLv3 will cause significant additional code to be contributed that would not be contributed without that license.

However, you don't point at what code would be contributed, or who would be contributing code under that license but not under the existing license (or a plain GPLv3 license).

I think that such info would be important for such a license change.

Is there another message that I should be looking at?

The mere fact that the Koha community is growing is not a good reason for changing the license. Personally I would consider the fact that the community is growing to be a good indication that the existing license is good and not mess with it.

Hi David It's interesting who comes out of the woodwork when licensing comes up, it seems people have strong opinions on it, even people only tangentially related to the project. I think you are missing a lot of context to this discussion, it has come up quite a few times in the past, and the fact is the growing trend worldwide of Software as a Service, and the ghettoisation of code and users that can result from that is what is behind (at least for myself) this discussion. I think that users should have the right to have the source code of the software they are using, and I believe that this freedom is one of the 4 freedoms the GPL was designed to protect. I think that these freedoms outweigh some nebulous security concern, and that the important thing is that users are protected from lockin. If you have a better way to achieve this than APGL3, or GPLv3 + an additional clause, I'm all ears. Chris

On 11 May 2010 13:09, <david@lang.hm> wrote:

On Tue, 11 May 2010, Chris Cormack wrote:

...

It's interesting who comes out of the woodwork when licensing comes up, it seems people have strong opinions on it, even people only tangentially related to the project. I think you are missing a lot of context to this discussion, it has come up quite a few times in the past, and the fact is the growing trend worldwide of Software as a Service, and the ghettoisation of code and users that can result from that is what is behind (at least for myself) this discussion. I think that users should have the right to have the source code of the software they are using, and I believe that this freedom is one of the 4 freedoms the GPL was designed to protect. I think that these freedoms outweigh some nebulous security concern, and that the important thing is that users are protected from lockin. If you have a better way to achieve this than APGL3, or GPLv3 + an additional clause, I'm all ears.

You are right that I have not seen the prior discussions (I've only been subscribed to the list for a month or two). You are also right that I am not (yet) involved with this project (not even as a user yet, I haven't had the time yet to test and figure out how to enter my several thousand books). If you feel that this means that my opinions are irrelavent, please let me know and I will unsubscribe and search for another tool to consider using instead.

A little background on me since I am not an active community member yet. My full time job is in security as a major financial services company. I have been using Linux as my desktop full time for over 12 years at work (longer at home) and while I don't contribute much code to the projects that I use, I do use a lot of opensource projects and do a fair amount of testing, bug reporting, and (after becoming familiar with the project) support for other users on the mailing lists.

As for your concerns. Yes, if you believe that SaaS is a major problem, then AGPL is the license that you need (and no, GPLv3 is not good enough to prevent the problem you are describing). However your post at the start of this thread did not make it clear that this is what you were pushing for.

I don't happen to believe that this is a major problem, and definantly not a problem large enough to be worth the drawbacks involved with moving to a lesser used license like the AGPL.

Even though the GPLv3 allows code to be converted to AGPL, that doesn't mean that doing so won't annoy people who don't want to use the AGPL that you take code from (for examples of a similar problem, look at the outrage from people who release code under BSD licenses against project that are GPL and incorporate their code) , and you may not be able to submit any fixes that you have back upstream to them. If you maintain a dual GPLv3 and AGPL license, then you don't achieve your goal, anyone wanting to do things that you don't want them to do will just use the GPLv3 license.

I believe that if the open project moves rapidly enough in developing it's version, anyone who tries to maintain a fork is going to fall behind and find that they are better off using the community version than their own fork. In a good community with many different companies involved (which I understand Koha is), the combined resources of the rest of the community will outstrip the resources of any one company that tries to maintain a fork. You will occasionally have a company that misbehaves, or at least skirts the line, but I don't think adding restrictions to the license will really help much in this area.

Unless a company is going to go only the SaaS route, they will be giving their code to their clients, and any one of those clients can redistribute the code. So the probability of the source being locked up out of sight is relativly low.

But as the android problem with the linux kernel is showing, even if the code is available it doesn't nessasarily do the main project much good if the company working on the fork isn't interested in getting their changes merged back upstream. Perl is especially good for a company who chooses to make life hard for outsiders wanting to merge the changes back as there are so many different ways to do things and to obuscate what is happening. It doesn't even take malice on the part of the company, just hiring developers who use coding styles and perl features significantly different from the community will make merging things back hard enough that they become almost the same as writing the features from scratch.

So I don't believe that AGPL is really going to be effective at solving the problem that you are anticipating, and I do see drawbacks in using it as your license.

Objection heard. Lets hear from some others now. Chris

Hi, On Mon, May 10, 2010 at 9:47 AM, MJ Ray <mjr@phonecoop.coop> wrote:

Christopher Nighswonger wrote:

...

In light of the momentum the community has built up in the area of change in recent months, now would be a good time to resume licensing discussions and bring them to a final resolve.

I cannot contribute fully to this discussion at this time.  Please can we try to limit the number of simultaneous disruptive changes?  As you know, we have 3.2 releasing, new websites and urgent trademark challenges which I'd like to contribute to and my work is already spread a bit too thin.  Please can we leave this until after 3.2.0?

I, for one, do not want to attempt relicensing prior to release of 3.2.0 or as a condition for release of that version. Personally, while I am currently in favor of relicensing to GPL3+ (assuming that we can resolve the matter of dependencies on GPL2 code such as OpenNCIP) and think that the AGPL3 should be considered as well, it would be too disruptive to even think of doing this for 3.2. However, since the proposal is relevant for 3.4, I do think that now is as a good a time as any to start a discussion of this issue. Regards, Galen -- Galen Charlton gmcharlt@gmail.com

On Mon, May 10, 2010 at 9:47 AM, MJ Ray <mjr@phonecoop.coop> wrote:

No, that additional requirement is one of the disadvantages. AGPLv3 is still a fairly new licence and as far as I know, it's not yet entirely clear what is meant by "access", particularly for a modular system like Koha. It might mean that everyone who sees a page is entitled to the 227Mb source tarball. Who wants to pay for those downloads?

Github and the like provide very simple solutions to this problem both with ease of administration and ease of cost. AGPLv3 does not specify (see my previous response to Lars' post.) Besides, there are hosting plans available that provide unlimited bandwidth for very, very few $$$ per month if the FTP route was a necessity. <snip>

Fundamentally, AGPLv3 is based on an absurd idea that one can "ensure cooperation with the community" (source: AGPLv3 preamble).  However, cooperation by definition must be voluntary (source: ICA.coop/coop/principles.html ) so legal compulsion is not cooperation.

A careful reading of the second paragraph of the Preamble of GPLv2 (the current Koha license) will reveal the fact that the entire purpose of the license is to ensure cooperation with the goal of ensuring at a minimum three things: "...the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs..." It appears that any form of licensing is an attempt to ensure cooperation of some sort among some people. *All* licensing is, in fact, some form of coercion, period. The unfortunate fact of life is that there is somebody, somewhere who will do wrong even if you will not. It would be wonderful if it were otherwise. The we would not need licenses... or laws for that matter. By adopting *any* sort of license, then, we are "ensuring cooperation" at some level. The entire purpose of any GNU license is to provide "legal compulsion" of those who would use FOSS to abide by the wishes of the copyright holder regarding that code. FOSS would patently fail if there were no way to enforce the desire for the code to be free and open source. So the argument against the use of legal compulsion is really self-defeating in this instance. We cannot license *and* avoid the use of "legal compulsion."

So may we postpone the rest of this discussion to post-3.2.0?

As I stated in my original proposal: We are already very active atm, and now is the time to at least begin discussing this change. Kind Regards, Chris

On Mon, May 10, 2010 at 9:54 PM, MJ Ray <mjr@phonecoop.coop> wrote:

Christopher Nighswonger wrote:

...

On Mon, May 10, 2010 at 9:47 AM, MJ Ray <mjr@phonecoop.coop> wrote:

...

[...] It might mean that everyone who sees a page is entitled to the 227Mb source tarball.  Who wants to pay for those downloads?

Github and the like provide very simple solutions to this problem both with ease of administration and ease of cost. AGPLv3 does not specify (see my previous response to Lars' post.) Besides, there are hosting plans available that provide unlimited bandwidth for very, very few $$$ per month if the FTP route was a necessity.

Firstly, it seems unethical to impose even "very, very few $$$ per month" of extra cost on charitable libraries.

In that case, github has a free offering... no $$$ per any time increment.

Secondly, this leads to another of what I think is still one of the Great Unknowns of AGPLv3: if you don't host the source alongside, must the app go offline if it thinks the source has gone offline?

Where in the license does it say anything about hosting source alongside the application?

There are so many of these lawyerbombs around AGPLv3 that I feel the whole thing is best avoided by sticking with GPLv2, at least until others have trod on some of the big ones, in the absence of any pressing need to switch.

GPLvX was virtually untested in court until Progress Software Corp. v. MySQL began back in 2002. Apparently that line of reasoning did not stop the originators of Koha from selecting GPLv2+ when they released it in 2000.

...

...

Fundamentally, AGPLv3 is based on an absurd idea that one can "ensure cooperation with the community" (source: AGPLv3 preamble).  However, cooperation by definition must be voluntary (source: ICA.coop/coop/principles.html ) so legal compulsion is not cooperation. [...] It appears that any form of licensing is an attempt to ensure cooperation of some sort among some people.  *All* licensing is, in fact, some form of coercion, period. The unfortunate fact of life is

<snip> that there is somebody, somewhere who will do wrong even if you will not. It would be wonderful if it were otherwise. The we would not need licenses... or laws for that matter. [...]

I don't see how that's true, unless "cooperation of some sort" means something other than cooperation, such as mere trading. Free software licensing is usually just setting out the terms of trade, but AGPLv3's clod-handed attempts to force public sharing go beyond it.

View it how you will. In the case you propose, we are simply establishing an additional clarification to the terms of trade. The intent of GPL licenses is to preserve the open nature of code released as free and open source. Not only is it the right of the receiver to have access to the code, etc. but it is also the right of the author to have their intent that the code be free and open respected. The terms of the trade are such that in return for the right to use, etc. this code, you agree to release any changes you make to said parties. As I pointed out previously: All licensing agreements "force" some points. Just violate one and see how quickly it is en-forced. (Pun intended.) It actually seems to me that the matter of not forcing cooperation is in contradiction to the expressed desire to force cooperation in the matter of trademarks, etc. by de-listing, etc. Cooperation is, after all, cooperation.

Laws and licences do not prevent anyone doing wrong.  I'm sure all of us are quite capable of breaching a copyright licence without much work.

Quite right. If laws and licenses did that, we'd only need a few to fix all problems. What they do do is give recourse for redressing wrongs.

If anyone is hoping that adopting AGPLv3 will prevent bad people refusing to share progress with the community, you are doomed to fail.

I don't think anyone is under that illusion. As I said, "The unfortunate fact of life is that there is somebody, somewhere who will do wrong even if you will not."

So what is the burning desire for AGPLv3?

To put in place a mechanism for redressing violations of terms of license. We can chatter away about how a company reneged on its verbal obligations to contribute code back to the community,but we have nothing to fall back upon with any (even hopeful) force of law. It is not a panacea for all ills, only another hopeful obstacle in the path of misbehavior.

...

...

So may we postpone the rest of this discussion to post-3.2.0?

As I stated in my original proposal: We are already very active atm, and now is the time to at least begin discussing this change.

I am disappointed by this desire to press ahead with holding a discussion of such a complex topic at such a busy time.  It will limit participation and likely leave the discussion incomplete.

Participation will only be limited if we want it to. No one involved in this project is not busy. If we believe that we have a good thing going in Koha, we must make the time to do the not so nice parts of the project too. Kind Regards, Chris

Hi, On Tue, May 11, 2010 at 10:36 AM, Michael Hafen <mdhafen@tech.washk12.org> wrote:

This would be true if time were not a finite resource.  Unfortunately it is.  As much as we would like to have more time in a day it is simply not possible.  I agree with Galen; this is an unusually busy time for Koha developers because of the impending release.  I think that this is not the best time for this discussion.

To clarify, I am not calling for an end to this discussion, nor have I done so. I think that now is an appropriate time to talk about the licensing in preparation for 3.4, although if active developers want to send a bugfix for each email they add to this thread, I won't complain. Regards, Galen -- Galen Charlton gmcharlt@gmail.com

On ke, 2010-05-19 at 07:23 -0400, Chris Nighswonger 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.

For what it's worth, I agree: it's better if discussion is kept in one place, so everyone can easily follow it.

This would probably be a good time to point out that 3.4 will have the capability of doing a total db dump from within the staff client.

As it happens, I made a proof-of-concept implementation of this yesterday. It relies on a cron job to call mysqldump; possibly an on-demand dump might be better.

[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

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.

Thomas, I have to agree with Aaron here. You are confusing Koha's use of mysql-specific *query language* with the customization of the mysql server/client source code. This would be akin to thinking that including browser-specific javascript produces a derivative work of that browser. The OSS Exception you linked relates to client driver libraries. In our case, something like DBD::mysql may be a driver library. Koha as a whole is not. We don't distribute mysql source code and we do not build a custom mysql client. I see absolutely zero legitimate basis for considering Koha a derivative work of msyql, just the same as it is not a derivative work of Apache. Our application is *dependent* on those projects, but not derivative of them. I don't think we need to be concerned about whether mysql is licensed GPL 2 or GPL>=2 (or BSD or whatever). All we need to care about is that their licensing remains "open enough" for us to continue including a dependency on their software. Lars is correct that we only need to worry about the source that is in Koha when making a license decision. --Joe Atzberger

On 2 June 2010 15:20, Thomas Dukleth <kohalist@agogme.com> wrote: <snip>

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.

This is a concern not just for Koha, but for the Evergreen project as well should it decide at some point to move to GPL3 or AGPL3. I'm copying David Fiander, the author of the vast majority of the OpenNCIP code, to ask if he was directed specifically to place the code under the GPL v2 without the "or later" clause. I suspect that the omission of the "or later" clause might be a mistake, as I'm sure GPLS would have intended the OpenNCIP / Open SIP 2 to be "GPL v2 or later" to match the rest of the GPLS-originated code in Evergreen. The root COPYING license for Evergreen, committed 2006-01-30, uses the "or later" clause - http://svn.open-ils.org/trac/ILS/browser/trunk/COPYING - so I'm crossing my fingers that this is just an easily-corrected mistake. -- Dan Scott Laurentian University

Thomas Dukleth wrote:

4. VOTING METHOD.

M J Ray had suggested using some method for voting to consensus which would allow revoting. He needs to provide some details for how that would work along with a method of vote counting which maximises preferences.

On the issue of preferential voting generally, see the Wikipedia preferential voting article, http://en.wikipedia.org/wiki/Preference_voting .

That's a good start. 4.1. SUMMARY OF PROBLEM A problem with this vote is that the candidate options are very similar and we need to pick the one which is most acceptable to most people. The candidate which only has the most first-preference votes (which would win a first-past-the-post election) or even the best position in a preference ranking (which would win a single-winner single transferable vote election) may not be the best-supported one if it is too divisive and completely unacceptable to some project supporters. 4.2. A SUGGESTED VOTING METHOD The debian project uses a type of Condorcet voting with some tweaks. Its description is at http://www.debian.org/devel/constitution#item-A That's a sort of preference voting. But I think I lean towards some sort of range voting rather than preference voting. See http://en.wikipedia.org/wiki/Range_voting After all, we already see this in meetings, although most votes are uncontroversial and mostly a stream of explicit +1s or silent 0s. I think I would centre the range on 0 and ask people to vote on each option between -10 and +10, but try to avoid putting two options on the same number. We should understand -10 as the option is completely unacceptable and that voter will probably start looking for the exit. We should ask for a reason for any -ve vote, to see if that can be changed by some amendment to the option. I'd like those reasons to be announced anonymously and used as a start for some further discussion. Does that voting system make sense? Can we do better? 4.3. BUILDING CONSENSUS: FURTHER DISCUSSION OR BALLOT-REWRITING? There is an option in the debian project's votes for "Further Discussion" but when that wins, it's sometimes understood as a vote for no change, rather than automatically triggering a further round of discussion, proposals and voting. I think we won't have that problem because "no change" will be explicitly on the ballot, so should we include a "further discussion" option and commit to actually do another round if that option wins? If we don't like a "further discussion" option, one alternative would be to: 1. have a relatively long vote period, 2. allow revoting, 3. continue discussions while voting, 4. post interim results during the vote (2 or 3 times perhaps?) and 5. have a pool of people trying to build consensus among the voters could help us to gather around the best-supported option. Would that be better than including "further discussion"? It means that the vote will only run for a finite time, which is both good (there is a definite decision day) and bad (it risks dividing the community if the discussion goes badly and does not build consensus). The debian project allows revoting, but only votes after the discussion period has finished, so the ability to change one's vote doesn't seem to help to build consensus. Revoting's main purpose there seems to be correction of errors when filling out the ballot. If we have a single voting period, should we allow new compromise options to enter the ballot and defunct options to leave the ballot, up to (say) the day after last interim results before the vote closes? Thank you for your attention and I await your replies with interest. Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha

FairVote's argument against Score Voting (aka Range Voting) is mathematically flawed. FairVote began as "Citizens for Proportional Representation", and I believe their real interest in implementing Single Transferable Vote in the USA, like e.g. Australia uses in their Senate. Because IRV ("preferential vote") is the single-winner case of STV, FairVote pushes it as a useful "stepping stone". I do not believe they particularly care about the merits of IRV, and in fact they have made numerous blatantly false and misleading statements on voting for many years. Warren D. Smith, a Princeton math Ph.D. who has studied voting theory for over a decade, and sort of served as the "protagonist" of the book _Gaming the Vote_ responds specifically to several of the FairVote statements here: http://ScoreVoting.net/Irvtalk.html Here is a response to the specific (and actually quite absurd) criticism that Score Voting and Approval Voting violate "majority rule", particularly as compared to IRV. http://www.electology.org/majority The "right" metric of voting method performance (and you can basically prove it mathematically, as counter-intuitive as that may seem) is "average voter satisfaction" which can be expressed using ametric called Bayesian regret. Look at this graph of Bayesian regret values and notice how vastly much better Score and Approval Voting perform. IRV is actually almost bad as Plurality/FPtP. http://scorevoting.net/BayRegsFig.html Regards, Clay Shentrup The Center for Election Science San Francisco, CA

On Fri, Jan 14, 2011 at 10:14, Thomas Dukleth <kohalist@agogme.com> wrote:

Clay is described in the book as a fanatical advocate for score voting but good ideas need somewhat fanatical supporters to ensure that they have due attention.

Well, the description of me was from Rob Richie, the executive director of FairVote. He said something about how someone will need a restraining order against me some day, and claimed that I had been calling various third party members up at late hours to pitch Score Voting to them. Unless there was some major time zone change I inadvertently forgot to take into account, I think that's a fabrication. In my experience with Richie, spanning the course of four and a half years so far, I have found him to be extremely dishonest, when he can get away with it. For instance, he has claimed on numerous occasions that e.g. the 2009 Burlington IRV election was not a failure of monotonicity, when it is just a proven mathematical fact that it indeed was. The full ballot data was published, so this is not in any way in question. Warren Smith, the Princeton math Ph.D. at the center of the Score Voting movement (and quoted in Gaming the Vote) tried to catalog various FairVote lies, but eventually just gave up because they are too numerous to even keep track of. http://ScoreVoting.net/Irvtalk.html In another message, I will address the important issues of voting strategy

with score voting.

Discussions of "strategy" are frequently plagued with logical fallacies, and a lack of awareness of key concepts like Bayesian regret. Here are some links which help to inform on this complex and counterintuitive issue. http://www.electology.org/tactical-voting http://www.electology.org/bullet-voting http://scorevoting.net/UniqBest.html http://scorevoting.net/StratHonMix.html http://scorevoting.net/PleasantSurprise.html http://scorevoting.net/AppCW.html http://www.electology.org/threshold http://scorevoting.net/RVstrat3.html http://scorevoting.net/RVstrat4.html The deficiency in the

FairVote criticism of range voting to which I linked was that the scenario they give uses a range which is unduly high relative to the number of voters.

Their scenario has 100 voters casting ballots with a range of 0 to 99.

I don't know what the number of voters has to do with the range of scores. In any case, I think a 0-9 scale should be plenty.

The relatively large range allows merely two voters using a reasonable voting strategy of casting their greatest preference strongly at the maximum range of 99 to outvote all other voters expressing their greatest preference weakly near the minimum of the range at 1.

Well, yes. That analogy is pretty absurd in its sheer implausibility. However, the range they use is precisely what is advocated by some people. (I advocate 0-9, as I said.) http://scorevoting.net/Why99.html A reasonably low range relative to the number of voters along with voters

who use some half intelligent sense of voting strategy avoids the unreasonable case above. [In a later message, I will propose a means for resolving some issues of voting strategy.]

I will bet you a year's salary that your ideas here have been discussed to death on our Yahoo discussion group a myriad of times over the past 5 years. :) Some statements from FairVote founder, Robert Richie, seem to show that he

would advocate whatever non-plurality (non-first past the post) voting method would be most likely to obtain sufficient political support to be implemented for government elections.

Not my impression at all. I think he is incredibly resistant to changing his pro-IRV/STV platform, because it would mean having to admit he was wrong all those years. He could even lose his directorship of FairVote. Any real preference by FairVote may

be for a voting method which is useful as first step to proportional representation, the long term objective of FairVote. Instant runoff voting can be transformed into the single transferable ballot for proportional representation.

Exactly what I said. They support IRV, despite his severe problems, because they see it as a stepping stone to STV. I think that is naive of them because the USA is so rigged against PR (e.g. PR is illegal for Congress). So we believe that getting PR to any non-trivial extent (i.e. beyond a handful of US cities) will require FIRST getting Score or Approval Voting as a PREREQUISITE. And there are PR analogs of Score Voting which are better+simpler than STV. http://ScoreVoting.net/PropRep.html http://ScoreVoting.net/RRV.html = Reweighted Range Voting http://ScoreVoting.net/Asset.html = Asset Voting Poundstone reports that there has been sufficient support to institute

instant runoff voting in some jurisdictions because of well financed support from FairVote. Less well financed supporters of alternatives other than instant runoff voting appear divided because all voting systems are subject to some significant criticism.

Well, I would say we are divided BECAUSE of the rampant misinformation out there about voting methods, much of which is the RESULT of FairVote's inaccurate propaganda. Albeit a lot of it is also just an innocent result of the confusing nature of election theory and game theory in general.

I have not identified any adequate modification of IRV. IRV works by always eliminating some preferences. [Other preference voting systems attempt to compare all preferences without eliminating any.]

Right. E.g. Bucklin. Anyway Thomas, you seem quite intelligent and informed about these issues. If you have any interest in joining our efforts in any capacity, please let us know. You could be featured on this extremely fancy page. http://www.electology.org/about-us Best, Clay -- *Clay Shentrup* *Secretary, Director* *The Center for Election Science* *http://www.electology.org/* *206.801.0484*

Can anyone help me solving the zebra problem. Actually i need to make search in indian languages.. Thanks in advance. Regards Nova

Reply inline: On Tue, January 18, 2011 05:33, Clay Shentrup wrote:

On Fri, Jan 14, 2011 at 10:14, Thomas Dukleth <kohalist@agogme.com> wrote:

[...]

...

In another message, I will address the important issues of voting strategy with score voting.

Discussions of "strategy" are frequently plagued with logical fallacies, and a lack of awareness of key concepts like Bayesian regret. Here are some links which help to inform on this complex and counterintuitive issue.

http://www.electology.org/tactical-voting http://www.electology.org/bullet-voting http://scorevoting.net/UniqBest.html http://scorevoting.net/StratHonMix.html http://scorevoting.net/PleasantSurprise.html http://scorevoting.net/AppCW.html http://www.electology.org/threshold http://scorevoting.net/RVstrat3.html http://scorevoting.net/RVstrat4.html

I had read these and much more before I had proposed to present a message about strategy. However, even prior to reading much about score voting I had independently and intuitively taken much of the same conclusions about strategy. Finding strategies intuitively does not mean that I am immune from falling for some fallacies. Optimal score voting strategy may be intuitive to many people but does introduce a complexity to voting for which people are unaccustomed and raises the dilemma between honest voting and strategic voting. [...]

...

[In a later message, I will propose a means for resolving some issues of voting strategy.]

I will bet you a year's salary that your ideas here have been discussed to death on our Yahoo discussion group a myriad of times over the past 5 years. :)

I doubt that any of the following summary of strategy is original. People may have already proposed all logical variants to resolve issues of strategic complexity and the honest vs. strategic dilemma. There is a chance the scheme which I will present in another message for resolution may be an original contribution to voting theory specifically developed to solve the problem of finding a good voting method for the Koha community. [...] Difficulties of voting strategy are the most significant weakness of score voting (range voting) and need to be understood by the electorate and even better constrained by limitations to avoid mimicing the problems of voting methods which often fail to maximise voter preferences. Revoting to consensus may be helpful for some problems of voting strategy with score voting. Unfortunately, rational strategic voting undermines the informative value of honestly reported assignment of scores without applying strategy. Honestly reported information can be especially informative for discussing how to achieve consensus. The following consideration of voting strategy for score voting is lengthy and I suspect may be considered excessively tedious. Most people may think that voting should be simpler and that voting should not need an understanding of voting strategy. I agree that voting should be simple but also avoid the worst problems of plurality voting familiar to us all in which candidates which most voters oppose often win. Merely understanding that voting strategy can have an effect on which candidate wins may be sufficient for most people. The scheme which I will present in another message eliminates the problem of voting strategy complexity with score voting in addition to resolving the dilemma between honest and strategic voting. 1. NOMENCLATURE. 1.1. HONEST VOTING AND STRATEGIC VOTING. The literature has possibly confusing references to 'honest voting' as distinct from 'strategic voting'. 'Honest voting' (sincere voting) is merely an individual voter directly expressing the voter's internal preferences without considering how to best express them in a manner most likely to win in relation to votes cast by other voters. 'Honest voting' might be described as naive voting by not considering chances of the voter's prefered candidates winning. 'Strategic voting' is voting with an understanding of how an individual voter can maximise his preferences for candidates in the context of votes by other voters. 'Strategic voting' would only be dishonest if the rational strategy for some election scenario encouraged casting some votes contrary to actual preferences to give the voter's greatest preference the best chance of winning. Fortunately, score voting is least likely voting method to involve scenarios in which voting contrary to actual preferences might be a successful strategy for an individual voter. The distinction between 'honest voting' and 'strategic voting' may be confusing if one assumes that the goal of each individual voter is to have his own greatest preference win. Given the goal of winning, strategic voting is merely rational and should not be considered somehow dishonest. It would be irrational for individual voters to ignore the other voters and for individual voters to thus not attempt to have their own preference win. 1.2. APPROVAL AND RANKING IN SCORE VOTING. 'Approval voting' is simple yes or no voting for each candidate. 'Approval voting' is a type of score voting in which the range of permitted scores is limited to two values such as either 0 or 1. 'Ranking' is used to list relative preferences between candidates in order for 'preference voting methods'. 'Score voting' uses scores for expressing absolute preferences for candidates not merely relative preferences between candidates. 'Ranked approval voting' is a somewhat contradictory name which I have given for part of a voting strategy in which votes are expressed as adjacent scores clustered adjacent to either the highest or lowest scores in the permitted range. The clustering has elements of both 'approval voting' and 'preference voting methods'. Examples are given further below in the context of possible strategies. 2. STATEGICALLY POOR VOTING STRATEGIES. Strategically poor voting strategies can easily be avoided when recognised. However, some forms of 'honest voting' may also be strategically poor voting which is a problem which needs correcting in the voting method. 2.1. WEAK VOTING. Weak voting is applying something less than the highest scores in the possible range for the voter's greatest prefered candidates and something more than the lowest permitted scores in the range for the voter's least preferred candidates. Weak voting might be an honest expression of similarities between candidates but a poor strategy for maximising individual preferences in the cumulative result of all voters. Other voters using strong voting, applying the highest possible scores in the range for greatly prefered candidates and the lowest possible scores in the range for least prefered candidates, would outvote weak voters. 2.1.1. EXAMPLES OF WEAK VOTING. 2.1.1.1. WEAK VOTING EXAMPLE. Score range allows scores from 0 to 10. Candidates are A, B, C, and D. 300 people vote. 200 voters score candidates weakly: A at 7, B at 6, C at 5, and D at 4. 100 voters score candidates strongly with opposite preference ranking to other voters: A at 0, B at 1, C at 9, and D at 10. Calculating the averages: Candidate A: ((7 score * 200 votes) + (0 score * 100 votes)) / 300 total votes = 4.6667 average mean score Candidate B: ((6 score * 200 votes) + (1 score * 100 votes)) / 300 total votes = 4.3333 average mean score Candidate C: ((5 score * 200 votes) + (9 score * 100 votes)) / 300 total votes = 6.3333 average mean score Candidate D: ((4 score * 200 votes) + (10 score * 100 votes)) / 300 total votes = 6 average mean score Candidates C won. Voters who had used weak scores had some effect on the outcome in enabling C to beat D. However, voters who had used weak scores could have enabled their greatest preferred candidate A to win if they had used strong scores. 2.1.1.2. PARTLY CORRECTED WEAK VOTING EXAMPLE. Weak voting can be at least partly corrected by simply using the highest and lowest scores permissible in the range. Score range allows scores from 0 to 10. Candidates are A, B, C, and D. 300 people vote. 200 voters score candidates with corrections to use the highest and lowest scores: A at 10, B at 6, C at 5, and D at 0. 100 voters score candidates strongly with opposite preference ranking to the other voters: A at 0, B at 1, C at 9, and D at 10. Calculating the averages: Candidate A: ((10 score * 200 votes) + (0 score * 100 votes)) / 300 total votes = 6.6667 average mean score Candidate B: ((6 score * 200 votes) + (1 score * 100 votes)) / 300 total votes = 4.3333 average mean score Candidate C: ((5 score * 200 votes) + (9 score * 100 votes)) / 300 total votes = 6.3333 average mean score Candidate D: ((0 score * 200 votes) + (10 score * 100 votes)) / 300 total votes = 3.3333 average mean score Candidate A won. Correcting weak voting by using the highest and lowest scores permissible in the range allowed the majority preference for candidate A to win. 2.2. BULLET VOTING. Plurality voting could be used as a strategy. If many voters would use plurality voting as strategy, then a plurality result would be the unfortunate consequence in the absence of an absolute majority. Plurality voting as a strategy instead of a voting method is bullet voting. Voters might assign the highest possible score to their greatest prefered candidate and the lowest possible score to all other candidates. Such a voting pattern would reduce score voting to common bad plurality voting in which the candidate with most votes can win despite being opposed by the majority of voters. 2.2.1. EXAMPLES OF BULLET VOTING. 2.2.1.1. BULLET VOTING EXAMPLE. Score range allows scores from 0 to 10. Candidates are A, B, C, and D. 300 people vote. 98 voters score candidates: A at 10, B at 0, C at 0, and D at 0. 97 voters score candidates: A at 0, B at 10, C at 0, and D at 0. 97 voters score candidates: A at 0, B at 0, C at 10, and D at 0. 8 voters score candidates: A at 0, B at 0, C at 0, and D at 10. Calculating the averages: Candidate A: ((10 score * 98 votes) + (0 score * 202 votes)) / 300 total votes = 3.2667 average mean score Candidate B: ((10 score * 97 votes) + (0 score * 203 votes)) / 300 total votes = 3.2333 average mean score Candidate C: ((10 score * 97 votes) + (0 score * 203 votes)) / 300 total votes = 3.2333 average mean score Candidate D: ((10 score * 8 votes) + (0 score * 292 votes)) / 300 total votes = 0.2667 average mean score Candidate A won for having the highest average mean score despite being opposed by the majority of voters merely because of a poor strategy to express only the greatest preference. Computer simulations by Warren Smith show that plurality voting is the best strategy for an individual voter if there are a small number of voters, http://www.scorevoting.net/RVstrat3.html . In simulations of a three candidate election, plurality voting was found the best strategy for an individual voter if there are not more than ten voters. A plurality vote without an absolute majority should be avoided by a rule that the problem will either be corrected by revoting or the automatic substitution of required preference ranking. 2.2.1.2. PREFERENCE RANKING REQUIREMENT WITH BULLET VOTING EXAMPLE. Score range allows scores from 0 to 10. Candidates are A, B, C, and D. 300 people vote. Minimal preference ranks are required for scores preventing multiple 0 scores. 98 voters score candidates: A at 10, B at 2, C at 1, and D at 0. 97 voters score candidates: A at 0, B at 10, C at 2, and D at 1. 97 voters score candidates: A at 1, B at 0, C at 10, and D at 2. 8 voters score candidates: A at 2, B at 1, C at 0, and D at 10. Calculating the averages: Candidate A: ((10 score * 98 votes) + (0 score * 97 votes) + (1 score * 97 votes) + (2 score * 8 votes)) / 300 total votes = 3.6433 average mean score Candidate B: ((2 score * 98 votes) + (10 score * 97 votes) + (0 score * 97 votes) + (1 score * 8 votes)) / 300 total votes = 3.9133 average mean score Candidate C: ((1 score * 98 votes) + (2 score * 97 votes) + (10 score * 97 votes) + (0 score * 8 votes)) / 300 total votes = 4.2067 average mean score Candidate D: ((0 score * 98 votes) + (1 score * 97 votes) + (2 score * 97 votes) + (10 score * 8 votes)) / 300 total votes = 1.2367 average mean score Candidate C won. Required preference ordering prevented candidate A for having the highest average mean score despite being opposed by the majority of voters merely because of a poor strategy to express only the greatest preference. 3. OPTIMISED VOTING. In optimised voting, a voter applies the highest possible score in the range for the greatest prefered candidate and the lowest possible score in the range for the least prefered candidate. The difficulty is what to do about the candidates which are neither the greatest preference nor the least preference. If a voter assigns too high a score to one of the voter's middle preference candidates, then the high score may help defeat a candidate for which the voter has a greater preference. If a voter assigns too low a score to one of the voter's middle preference candidates, then the voter may help the candidate loose to a candidate for which the voter has a lesser preference. 3.1. SCALED SINCERITY. Scaled sincerity voting assigns middle preference candidate scores by evenly distribution (linear interpolation) across the range of permissible scores. Such an even distribution of scores for candidates would be similar to a Borda count in which weights (scores) are assigned according to relative preference rank. The most significant difference is that Borda would not have a weight of 0 for the lowest ranking preference. No analysis of middle preferences except relative ranking by the voter is needed for scaled sincerity, therefore, the strategy can be used in circumstances when no other strategy may be determined. In simulations of millions of election scenarios, scaled sincerity performed at least 91% as well as the optimum strategy, http://www.scorevoting.net/RVstrat3.html . 3.1.1. EXAMPLE OF SCALED SINCERITY. Example of scaled sincerity. Score range allows scores from 0 to 10. Candidates are A, B, C, and D. The voter has relative preferences A > B > C > D. Scores for the preferences are evenly distributed as well as can be managed within the range: A at 10, B at 7, C at 3, and D at 0. 3.2. MEAN BASED THRESHOLDING. 3.2.1. MEAN BASED THRESHOLDING GENERALLY. Mean based thresholding strategy uses the expected utility of the result for the voter to determine a threshold as a dividing point for optimising scores either high or low. See the expected utility hypothesis in Wikipedia, http://en.wikipedia.org/wiki/Expected_utility_hypothesis . The expected utility may be adjusted by a risk avoidance bias which would change the threshold. The mean threshold may be adjusted by combining the expected utility with some expectation or actual knowledge of how other voters may vote. Expected utility of the result can be calculated by the voter first considering honest scores for middle preference candidates and then calculating the average mean for the scores assigned for all the candidates. The voter assigns the highest permitted scores to candidates with a first considered honest score above the calculated threshold and the lowest permitted scores to candidates equal to or below the threshold. Such a mean based thresholding strategy was found to be the most successful strategy in simulations of millions of elections, http://www.scorevoting.net/RVstrat3.html . 3.2.1.1. EXAMPLE OF MEAN BASED THRESHOLDING. Score range allows scores from 0 to 10. Candidates are A, B, C, and D. In considering honest scores which might be assigned in the absence of strategy, a voter has the following preferences indicating the voter's expected utility for each of the candidates: A at 10, B at 6, C at 2, and D at 0. Calculating mean threshold of expected utility: ((10 score * 1 candidate) + (6 score * 1 candidate) + (2 score * 1 candidate) + (0 score * 1 candidate)) / 4 candidates = 4.5 mean threshold The voter assigns the highest scores in the permitted range to candidates with an expected utility above the mean threshold of 4.5. The voter assigns the lowest scores in the permitted range to candidates with an expected utility equal to or below the mean threshold of 4.5. Approval form with only highest and lowest scores: A at 10, B at 10, C at 0, and D at 0. Ranked approval form with scores adjacent to highest and lowest: A at 10, B at 9, C at 1, and D at 0. 3.2.2. RISK AVOIDANCE BIAS. The expected utility may be adjusted by considering a greater voter bias over risk avoidance. When the risk avoidance bias is sufficiently great, the risk avoidance has a decisive effect on expected utility of some candidates and consequently the position of the threshold dividing between optimising scores high or low. Ordinarily one of the great advantages of score voting is that scores can have a degree of candidate independent absolute value. Adding or subtracting candidates need not have any effect on how a voter asses individual candidates, in contrast to preference voting in which assessments are all relative to other candidates. However, the permitted range needs to be sufficiently large to account for meaningful differences between candidates. Candidates may exist for which a voter has an indispensably high utility that alternatives must be avoided or such a horribly low utility that the horrible candidates must be avoided. At either the high or low end of the range, the permitted range may be insufficient to include such cases and have the scale meaningfully differentiate candidates. Scores considered for candidates should have some sense of relative expected utility in relation to other candidates. For example, the permitted range for scores of 0 to 10 is useful for a voter to consider the expected utility of candidates A at 10, B at 6, and C at 0. However, candidate D may be indispensably valuable and may have an expected utility of 1,000 which is outside the permitted range. Alternatively, candidate D may have a horribly low value to be avoided that the candidate may have an expected value of -1000. Incorporating indispensable D at the top of the range with score 10 should squash the scale for the other candidates to scores near 0. Alternatively, incorporating horrible D at bottom of the range with score 0 should squash the scale for the other candidates to scores near 10. Distance between extreme alternatives within the permitted range should be maximised for risk avoidance. If some candidates are indispensable, they should have the highest permitted scores and all other candidates should have the lowest permitted scores to avoid the others. If some candidates are indispensable, they should have the highest permitted scores and all other candidates should have the lowest permitted scores to avoid the others. If there is only one indispensable candidate or only one horrible candidate for the voter, then the optimal voting strategy becomes a form of bullet (plurality) voting as described further above in section 2.2. In such a circumstance, bullet voting would not be a poor strategy as described above, but the optimal strategy for the voter. 3.2.2.1. EXAMPLES OF RISK AVOIDANCE. [Unlike other cases, 5 candidates may better show what happens to individual candidates.] 3.2.2.1.1. INDISPENSABLE CANDIDATES RISK AVOIDANCE EXAMPLE. Score range allows scores from 0 to 10. Candidates are A, B, C, D, and E. Either candidate A or B are indispensable to the voter with A preferred to B. In considering honest scores which might be assigned in the absence of strategy and ignoring the range restriction, a voter has the following preferences indicating the voter's expected utility for each of the candidates: A at 1000, B at 700, C at 10, D at 6, and E at 0. Calculating mean threshold of expected utility: ((1000 score * 1 candidate) + (700 score * 1 candidate) + (10 score * 1 candidate) + (6 score * 1 candidate) + (0 score * 1 candidate)) / 5 candidates = 343.2 mean threshold The voter assigns the highest scores in the permitted range to candidates with an expected utility above the mean threshold of 343.2. The voter assigns the lowest scores in the permitted range to candidates with an expected utility equal to or below the mean threshold of 343.2. Approval form with only highest and lowest scores: A at 10, B at 10, C at 0, D at 0, and E at 0. Ranked approval form with scores adjacent to highest and lowest: A at 10, B at 9, C at 2, D at 1, and E at 0. 3.2.2.1.2. HORRIBLE CANDIDATES RISK AVOIDANCE EXAMPLE. Score range allows scores from 0 to 10. Candidates are A, B, C, D, and E. Candidates D and E are both horrible to the voter with D preferred to E. In considering honest scores which might be assigned in the absence of strategy and ignoring the range restriction, a voter has the following preferences indicating the voter's expected utility for each of the candidates: A at 10, B at 6, C at 0, D at -700, and E at -1000. Calculating mean threshold of expected utility: ((10 score * 1 candidate) + (6 score * 1 candidate) + (0 score * 1 candidate) + (-700 score * 1 candidate) + (-1000 score * 1 candidate)) / 5 candidates = -336.8 mean threshold The voter assigns the highest scores in the permitted range to candidates with an expected utility above the mean threshold of -336.8. The voter assigns the lowest scores in the permitted range to candidates with an expected utility equal to or below the mean threshold of -336.8. Approval form with only highest and lowest scores: A at 10, B at 10, C at 10, D at 0, and E at 0. Ranked approval form with scores adjacent to highest and lowest: A at 10, B at 9, C at 8, D at 1, and E at 0. 3.2.2.1.3. INDISPENSABLE AND HORRIBLE CANDIDATES RISK AVOIDANCE EXAMPLE. Score range allows scores from 0 to 10. Candidates are A, B, C, D, and E. Candidate A is indispensable to the voter with A preferred to B. Candidates D and E are both horrible to the voter with D preferred to E. In considering honest scores which might be assigned in the absence of strategy and ignoring the range restriction, a voter has the following preferences indicating the voter's expected utility for each of the candidates: A at 1000, B at 6, C at 0, D at -700, and E at -1000. Adjusting the scale for the expected utilities to a scale of non-negative integers: A at 2000, B at 1006, C at 1000, D at 300, and E at 0. Calculating mean threshold of expected utility: ((1000 score * 1 candidate) + (6 score * 1 candidate) + (0 score * 1 candidate) + (-700 score * 1 candidate) + (-1000 score * 1 candidate)) / 5 candidates = -138.8 mean threshold The voter assigns the highest scores in the permitted range to candidates with an expected utility above the mean threshold of -138.8. The voter assigns the lowest scores in the permitted range to candidates with an expected utility equal to or below the mean threshold of -138.8. Approval form with only highest and lowest scores: A at 10, B at 10, C at 10, D at 0, and E at 0. Ranked approval form with scores adjacent to highest and lowest: A at 10, B at 9, C at 8, D at 1, and E at 0. 3.2.3. THRESHOLD ADJUSTMENT. 3.2.3.1. EXPECTATION OF OTHER VOTERS' PATTERNS. If an expectation of the candidate scoring patterns for other voters is known, then that expectation can be incorporated into the threshold calculation. See the threshold strategy as described by Clay Shentrup's organisation, The Center for Election Science, http://www.electology.org/threshold . 3.2.3.2. KNOWLEDGE OF OTHER VOTERS' PATTERNS. If there is actual knowledge of how other voters have already scored candidates in an ongoing election, then that knowledge can be incorporated into the threshold calculation. We should have knowledge of how other voters have already scored candidates during the voting period for revoting to consensus. However, consensus discussion should help everyone optimise votes more than a simple threshold calculation for individual voters. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783

Thomas, Before I even begin to respond specifically to your comments, I would ask you to read a couple of links that are specific to this. You seem to be exhibiting a lot of the concerns of "exploitation of sincere voters" with Score Voting. We believe this is a huge logical fallacy. Here's why. http://www.electology.org/tactical-voting http://scorevoting.net/RVstrat6.html (see the part about "No Math Skills") http://scorevoting.net/ShExpRes.html Here's a succinct thought experiment to illustrate the fallacy I'm talking about. Say we have these "expected utility values" for a random strategic or honest voter, using both Score Voting and some hypothetical "strategy-proof" system, as follows: Sincere StrategyProof voter: 6 Strategic StrategyProof voter: 6 (since sincere and tactical behavior here are identical) Sincere Score voter: 8 Strategic Score voter: 12 The fallacy would be to criticize Score Voting based on the notion that the sincere voter is harmed relative to the strategic voter. It's a fallacy because it's comparing two different voters under the *same* system, instead of the *same* voter under two *different* systems. Obviously the sincere voter is better off with Score Voting in this scenario, even though the strategic voter is even better off still. Another fallacy, which I discuss again below, is the "fallacy of added choice". For instance, say you get to use Score Voting instead of Plurality Voting. You claim to have a "dilemma", that you can't decide whether to vote sincerely or strategically with Score Voting. But that is a fallacy. You are clearly better off than you were under Plurality. If you think it is too mentally taxing to ponder whether to vote sincerely or strategically, the worst case scenario is that you can just vote in what is effectively Plurality Style, by just giving a perfect 10 score to a single candidate, and leaving all other candidates with zero points. Then you are absolutely no worse off than you were before. You have not been harmed. Nothing has been taken away from you. In fact, you could look at it in an even more extreme way. With Score Voting, your expected utility will be so much greater, that you could abstain from voting *entirely*, and you'd *still* be statistically more happy with election results. The infinitesimal effect that your ballot has on an election *pales* in comparison to the aggregate effect that the voting method has on the election. Now to respond inline, somewhat redundantly to what I just said... On Wed, Feb 2, 2011 at 2:01 AM, Thomas Dukleth <kohalist@agogme.com> wrote:

even prior to reading much about score voting I had independently and intuitively taken much of the same conclusions about strategy.

Well then you did better than I did. I made some pretty silly assumptions until Warren Smith corrected me. Mainly because I was approaching it from the point of view of a hypothetical voter in a hypothetical election, instead of as a real voter in a real particular election. Optimal score voting strategy may be intuitive to many people but does

introduce a complexity to voting for which people are unaccustomed and raises the dilemma between honest voting and strategic voting.

I don't think people are unaccustomed to rating things. Check out Yelp reviews. As for strategic vs. honest voting, the same is true of *every* deterministic voting method. And I think it's pretty clearly a fallacy to see this as a problem or a "dilemma". The current system effectively lets you give a "10" to just one candidate, and 0's to all the others. Our system would let you use intermediate scores, and not have to give every other candidate a 0. There's absolutely no dilemma. If you feel that it would be detrimental to you to have to consider which option to pick, you can just skip that consideration entirely and give only one candidate a 10, just as if you are pretending to be using Plurality Voting. I'm tempted to create a term for this, like "The Fallacy of Added Choice" or something like that, although I'm sure it already exists in the field of economics. Difficulties of voting strategy are the most significant weakness of score

voting (range voting) and need to be understood by the electorate and even better constrained by limitations to avoid mimicing the problems of voting methods which often fail to maximise voter preferences.

This seems massively refuted by mathematical analysis. The basic strategy with Score Voting is to give a 10 to the candidate you would have voted for with Plurality Voting, plus everyone you like better. The hard part of that is deciding who you would support with Plurality Voting, which you obviously already have to do anyway. Once you've voted for that candidate, it's trivial to give a 10 to all candidates you like better. And while this might not seem immediately obvious, it would clearly flow naturally from existing voter behavior. Right now, a Nader supporter who is strategic may vote for Gore. Under Score Voting, that decision would play out essentially the same. He would start by saying, "Okay, I'm going to give Gore a 10, and leave Bush with a zero." Then he would say, "oh wow, I can still go ahead and give Nader a 10 as well -- neat!" And that's that. No appreciable added complexity. No falling sky. I respectfully think you're trying to address a non-existent "problem". Revoting to consensus may be helpful for some problems of voting strategy

with score voting.

Well, if you don't have information, you can use the "zero info" strategy, where you just give a 10 to every candidate you like better than the average of all candidates. I believe that may actually be *better* than voting with information about the relative candidate strengths. But in any case, the "revoting" already happens naturally in real life, because of pre-election polls, primaries, etc. And even if you did NOTHING to improve the honestly reported information, it seems that Score Voting would still be a lot better than every other remotely feasible system. Most people may

think that voting should be simpler and that voting should not need an understanding of voting strategy.

You do not "need" an understand of voting strategy with Score Voting. You could just vote sincerely, and you'd still get a much better average satisfaction than you did with Plurality Voting, using all the strategy in the world. In fact, you could just stop voting entirely, and you'd *still* be better off as a non-voter in a Score Voting society, because all the other voters would be using Score Voting. Thanks, Clay -- *Clay Shentrup* *Secretary, Director* *The Center for Election Science* *http://www.electology.org/* *206.801.0484*

Feels like we're thinking way too hard about this. It might simplify things to look directly at our situation instead of getting too clever. We're at GPL2. Options are: - stay there - move to GPL3 - move to AGPL3 - some other scenarios that I don't think have been proposed by anyone other than as a "we could..."

From what I can tell, moving to GPL3 is not contentious.

From what I can tell, moving to AGPL3 is mostly not contentious but has some strong minority opposition.

So, would a meaningful vote be: - yes/no I approve of moving to GPL3 - yes/no I approve of moving to AGPL3 And we could even set the bar pretty high for acceptance (? 80% approval). This assumes my 'From what I can tells' are correct. The proportional voting schemes seem to make more sense if we're looking for more than one outcome--which we aren't. -- unless we want to have a certain percentage of the code under one license or the another, that would be kind of cool (no, I'm joking here, don't do that). -reed

On Tue, Jan 11, 2011 at 9:33 AM, Thomas Dukleth <kohalist@agogme.com> wrote:

On Mon, January 10, 2011 01:15, Reed Wade wrote:

...

Feels like we're thinking way too hard about this. It might simplify things to look directly at our situation instead of getting too clever.

Whether the issue is about what ballot design or what voting method best maximises the preferences of voters is an important one which goes well beyond this particular case.  Reaching some helpful conclusions about both ballot design and voting methods will be helpful for guiding the procedures for any future votes in which the voting method may effect the result.

If the discussion relates to decisions other than the immediate one then yes. I'm all for better representation than a simple vote would allow. And I do expect that other topics we may face could use that sort of treatment. Being raised in the US and now living in NZ it's all the more clear to me that I was lied to when they told me the US was a perfect representational voting paradise.

If a ballot with approval options expressed independently from one another would be constructed as described by Reed, what would the following overall result mean?

I approve of upgrading the Koha copyright license to:

GPL 3, invoked with an or later version option.  Yes wins.

AGPL 3, invoked with an or later version option.  Yes wins.

My unstated presumption there is is that the case of wanting AGPL but not wanting GPL3 if AGPL wasn't accepted is oddball enough that it made no sense to worry with. (Do you like cake or cake w/ icing? No, I demand cake with icing but without the cake. (Not a perfect analogy.)) So, it's not so ambiguous in the above case (which is even what I would expect the outcome to be). I agree tho that those assumptions should be made clear and opportunities for counter cases made before any vote is designed -- sort of what we're doing right now. -reed

Reply inline: On Mon, January 10, 2011 01:15, Reed Wade wrote: [...]

And we could even set the bar pretty high for acceptance (? 80% approval).

I would like to think that we might obtain more than 90% approval for a particular option with some procedure for voting to consensus. However, I worry that even 80% could be too high to be an appropriate measure of consensus in a diverse electorate. Our experience with community wide ballots is very small and we should be very hopeful that the experience will improve over time as long as we do not set ourselves up for disappointment with expectations uninformed by sufficient experience. An especially high degree of favour for any particular option may be unlikely in such a diverse electorate as the Koha community at large. The issue of copyright license upgrade is to be put to the Koha community at large directly. Free software and the copyright licenses which support it are for software user freedom. Programmers tend to have some familiarity with the copyright licenses under which they contribute code or under which they would like to contribute code. Programmers working on the same project may be liable to share some common ideas about the choice of copyright license. Most of the Koha community at large consists of non-programmers with more diverse backgrounds. Many librarians are involved with copyright in a very different manner to the authorship contribution of programmers. Many librarians whom I have met are afraid of copyright while I have met few programmers afraid of copyright. Discussion and summaries of options need to help better inform everyone. The possibility of a division of the electorate in the wide Koha community is one reason why voting to consensus is a good idea. Having some minimum number of votes for the election result to be meaningful seems reasonable. We need merely be careful to not overestimate the number of people willing to participate in a ballot. Remember that the upgrade option has two possibilities allowing upgrade in general to have a strong consensus while there may be more division on the two upgrade possibilities. Making a special effort to discover whether some people may have an especially strong objection to a particular option is important for having a full discussion to obtain a better consensus.

This assumes my 'From what I can tells' are correct.

The proportional voting schemes seem to make more sense if we're looking for more than one outcome--which we aren't. -- unless we want to have a certain percentage of the code under one license or the another, that would be kind of cool (no, I'm joking here, don't do that).

Voting methods under discussion intended to maximise voter preferences especially when the electorate has to collectively adopt only one of a few possible options. Proportional representation in electoral systems is a different issue. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783

[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

Reply inline: On Mon, July 5, 2010 14:45, MJ Ray wrote:

Thomas Dukleth wrote:

[...]

I reply to key points below. For the full text, please refer to Thomas's emails in the archive.

I will reply to the third message when I get time, but I have noted my own lack of time before.

Please read my message from 4 July in this thread, http://tinyurl.com/24nwjdv , together with my message from 2 July, the third message in the set which I had originally intended to be sent at the beginning of June. [The link is to the message in Nable. Apparently, a bug in the Mailman archive copy at Katipo truncated the message just before a line ending with a colon in the body of the message.] Aaron Williamson from the Software Freedom Law Center (SFLC) corrected a mistake which he had made about the scope of Corresponding Source for meeting AGPL 3 obligations to remote network users. One consequence is that the answer which I had given in section 3.1.1.3. is partly reversed from the message to which you have replied.

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

I also encourage people to give close attention to the computing as a service and data access issues raised in section 3.4 of message, which I agree with the Free Software Foundation (FSF) and MJ Ray are outside the scope of AGPL 3. Where I think that FSF and I disagree with MJ, is that FSF and I think AGPL 3 is helpful as part of an overall solution. [...]

...

3. OBJECTIONS.

3.1. COMPLIANCE BURDEN.

MJ and Joshua have previously raised the objection that providing the source code for the running modified version of a Koha installation is a significant burden.

The actual requirement should not be considered to specify anything unnecessarily excessive. No one would presume that failure to include every pixel's worth of modification would constitute lack of compliance. Some reasonable lag between changes in a running version and the availability of the source code for the new version would be expected and not a compliance problem.

Noting that this opinion is Thomas's because it is not attributed, upon what is this opinion based?

Yes, this opinion is mine and has no substantiation in the license itself. Any lack of compliance with the license terms is a lack of compliance with the license. I merely assert that it is impractical to be obsessive about trivialities in compliance. Omitting one line of source code could be a huge compliance problem about which we should be strict. However, if we adopt AGPL 3, we should have some proportionality and understanding about imperfection while we strive to provide automation to capture changes in the Corresponding Source which would be of benefit to everyone in complying well with the license.

Why consider it unnecessarily excessive to follow the AGPLv3 as written and provide complete Corresponding Source at the time the service is running?

I do not consider the license terms to be an excessive compliance burden. Yet, I have tried to think of the most difficult cases where people have the intention of complying with the license but have disadvantages which complicate their effort to comply. Consider a party without a support contract is running their own instance of Koha in a part of the world with poor network connectivity. Furthermore, someone may have the knowledge to modify the templates or CSS but not have sufficient knowledge to use a version control system. Such parties and many less extreme cases would need automation assistance to help them comply. When such parties with the perceived intent of complying with the license would fail to comply, our first effort should be to improve whatever automation we may create to help them to comply.

[...]

...

3.1.1.3. LIMITING BANDWIDTH REMEDY.

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

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

Aaron was even troubled by the prospect that those using verbatim copies of the upstream version would be pointing upstream. I think that I need to ask him about that again because AGPL 3 specific obligations in section 13 are only triggered on modification which creates a derived work. He had given me some answers without having a copy of the license in front of him which led to his one big mistake. I suspect that there is always some desire to customise something such as the CSS which would then trigger the AGPL 3 specific obligations.

...

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

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

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

This sort of misunderstanding does make me wonder whether the concerns were being considered accurately.

Even if I had been mistaken about your presumption, I believe that I was correct in thinking that you have been concerned about the bandwidth limitation issue. I know that bandwidth problem in the context of those with poor network connectivity and expensive bandwidth had been a significant issue raised by several people during the drafting of GPL 3 and AGPL 3.

Maybe we should have reviewed a summary list of the concerns before the meeting, but hindsight is 20-20 and we need to deal with what we have.

We can always ask more questions. I arranged a meeting in person because my telephone was not working when Aaron suggested that we speak on telephone about the questions which I had raised. During the course of my meeting I introduced concerns which I knew people have had about the license. I have reported in great detail because I think that the license reinforcement of our cooperative goal is equally important to the project as the software itself.

[...]

...

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

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

The bandwidth to the Corresponding Source may be limited but it must not be more limited than the bandwidth providing access to use the program over the network. This is a correction to the answer given in the remainder of the section.

...

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

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

Aaron has corrected his mistake about how to regard the Corresponding Source under AGPL 3 specific obligations. See my message from 4 July in this thread, http://tinyurl.com/24nwjdv . License section 6 (d) would apply when meeting AGPL 3 specific obligations.

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

There are hosting services which offer free source code hosting for free software.

...

3.1.1.4. SOURCE CODE HOSTING SERVICE REMEDY.

[...]

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

I will ask the question, although, you are welcome to ask yourself. I think that you are correct that if a party are not meeting the terms of the license then that party should discontinue what would otherwise be a violation of the license. However, no party making a good faith effort to comply with the license should ever have reason to take the software offline unless those defending their copyright interests have demonstrated unreasonably zealous enforcement efforts in the past. We should want a party to fix any license compliance problem which they may have. We should not want anyone to stop using the software because of a temporary problem. The license has protections for accidental violators such as the following in section 8. "Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice." I think that this guaranteed protection for only a first violation is less generous than it should be. There are some other weaker protections for accidental violators. Protection for accidental violators had to be balanced against the need for effective enforcement against actual violators. I do not think that the balance was struck correctly but I have no practical experience with the task of copyright license enforcement. I will also ask what we could do as a community to reassure accidental violators who would be presumed to be making good faith efforts at compliance that they will not suffer from any unreasonable license enforcement efforts. I suspect that the answer will be partly that people should first judge by the absence of unreasonable enforcement for the history of free software uses of free software licenses. Additionally, Koha support companies could provide source code hosting services and indemnify their customers against copyright violations of the software license for all cases except gross negligence by the customer.

...

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.

After correcting for Aaron's earlier mistake, the bandwidth for accessing the source code must not be limited to a greater degree than the bandwidth for using the program remotely.

Picking the one I know best, gitorious.com, finds no way to pay a token fee

The token fee was meant as something for a source code hosting contract for a possible source code hosting service provided by Koha support companies even in the absence of any other support contract.

and further, "The Website is available only to individuals who are at least 13 years old", which I guess would have implications for young users. http://en.gitorious.org/tos/

Picking another one I've heard of, github.com, finds US$7/mo as the cheapest option. Again, there's a "13 years or older" requirement.

Gitorious, http://www.gitorious.org/ , and GitHub, http://github.com/ , are both free for free software use but as you have identified limited to people at least 13 years of age. Sadly, younger people running Koha installations would need to find a 13 year old to vouch for them.

There's also a "does not warrant" clause about interruptions (G.12). http://help.github.com/terms/

Everyone should expect that every service will have some downtime. Even municipal emergency telephone services fail and go offline sometime.

Do any suitable guaranteed token fee services currently exist?

I was merely suggesting that Koha companies could offer such services not that they currently exist. Aaron had seemed to imply that parties with responsibilities for complying with the license need to control or direct their own compliance but could contract with others to provide such services.

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

Automation to help capture and upload changes along with free or token fee source code hosting services should address the problem.

...

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

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

The license requires that the Corresponding Source be supplied for whatever is needed to run the program with some exceptions. Security configuration files are not specifically mentioned but an exhaustive list of the scope of Corresponding Source is not feasible. The Corresponding Source does not extend to mere data such as usernames and passwords. If a configuration file for holding such security information is needed to run the program but not automatically generated, then the file should be supplied with default or empty values. Section 1 of the license clarifies the issue of automatic generation. "The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source."

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

Joshua's presumption had been that the only way to comply with the license would be to have an automated script blindly creating a tar file of the source code files at a particular installation. An automated script would not be required but would certainly be helpful in creating tar files or feeding a version control system especially for those running Koha installations who would not have the knowledge of what to do to comply otherwise. However, an automated script could easily substitute particular files for generic files with default or empty values to avoid exposing user data.

...

3.4. DATA. [...] MJ had raised the lack of coverage for data as an insufficiency of AGPL 3. He was raising a concern about vendor lock-in best addressed by encouraging the inclusion and use of features allowing users to obtain all of their data, and contracts between those running network services and their users to ensure that users have access to their own data. Lack of such coverage in AGPL 3 is not a reason to object to AGPL 3 for an issue it could never have addressed with any certainty.

Why not?

Copyright licenses are only effective in the domain of copyright. Software licenses specifically are only effective for software. Eben Moglen had reminded me during the GPL 3 drafting process that we already stretching what the license can do effectively.

The current proposal for AGPL 3 stated it would be "quite a measure of protection more against Koha related code becoming locked up on a saas platform somewhere in the nebulous "cloud."" http://lists.koha-community.org/pipermail/koha-devel/2010-May/011303.html

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

In other words, I felt the community was being missold AGPL3. It does not address saas. It's easy to think it would at first glance, but it actually doesn't.

What AGPL 3 does do is allow users of software as a service to take the software which they have been using a server which they do not control and move it to a different server including their own server over which they would have complete control. Quoting from the same FSF document. "If D runs his version on a server that everyone can use, you too can use it. Assuming he has followed the license requirement to let the server's users download the source code of his version, you can do so, and then you can incorporate his changes into your version. (If he hasn't followed it, you have your lawyer complain to him.)" You are correct in identifying the fact that AGPL 3 is not designed to address the software as a service problem as a whole. AGPL 3 does form part of what FSF thinks is a good strategy for addressing the software as a service problem. See the document linked from the footnote to your quotation. Who does that server really serve? / by Richard Stallman. - http://www.gnu.org/philosophy/who-does-that-server-really-serve.html . "If you must use a server, use a server whose operators give you a basis for trust beyond a mere commercial relationship. However, on a longer time scale, we can create alternatives to using servers. For instance, we can create a peer-to-peer program through which collaborators can share data encrypted. The free software community should develop distributed peer-to-peer replacements for important “web applications”. It may be wise to release them under the GNU Affero GPL, since they are likely candidates for being converted into server-based programs by someone else. The GNU project is looking for volunteers to work on such replacements. We also invite other free software projects to consider this issue in their design." To address saas dangers, we should take action

around portability of data and facilitiating marginal gains, making it easier to join and collaborate.

I agree. However, I think that AGPL 3 would address part of the problem by keeping the market from being captured by some parties with the financial resources to monopolise attention. I am thinking about problems of market capture which are generally more significant outside the library market in which Koha is currently used. User control over data is a problem which needs to be addressed. A feature to allow the library to download all their data has been created. People need to insist upon terms in their contracts which guarantee access to their data and provide them with a copy on a regular basis and on demand. We should think about ways in which Koha might be adapted to a distributed model with the prospect of increasing the responsiveness which users expect. Centralised servers may necessarily be most efficient for some library automation tasks. However, think about the prospects of a distributed peer-to-peer design for very large consortia or union catalogues. Users are often all too ready to sign away their freedom. We need to do our best to help them appreciate the benefits which freedom brings.

...

3.5. UNTESTED.

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

I apologise if I gave that impression. I objected that the meanings of many key phrases GPL 3 and AGPL 3 are not widely understood: they are lawyerbombs which may end up having their meanings defined by disputes involving lawyers.

I would like everything in the license to have been more precisely drafted and structured in a more straightforward manner. I started concentrating on wording complaints very late in the process when further changes were unlikely. I only had time to concentrate on obvious substantive issues for most of my comments to the license drafting period. There is a mix of simple careful language in the style of IBM lawyers and inconsistent colloquial language in the style of Richard Stallman. Despite the concern about clarity which I share with you to some degree, I think that the GPL 3 and AGPL 3 licenses are generally clearer than GPL 2. Much of the complaint which I have seen about the lack of clarity in GPL 3 and AGPL 3 concentrates on length relative to GPL 2. Greater clarity often requires greater length and the license cannot cure a decline in attention spans as part of contemporary culture. Some of the greater clarity at length was needed merely to avoid some terms being read in a manner which might harm the interests of the users which the license had been intended to protect. In addition to greater length for clarity, GPL 3 and AGPL 3 have additional terms for areas which GPL 2 had been found insufficient. The coverage of User Products is one example of newly added terms to cover the case where some embedded device manufacturers had allowed access to the source code but prevented user modification of the installed software on otherwise modifiable devices. Most every legal document has some problems. The question is whether the benefits conferred outweigh the problems. As a legal document, I believe that most lawyers prefer GPL 3 to GPL 2. Software developers may prefer the language of GPL 2 because it had less legalistic detail and the terms gave them more rights relative to users. Everyone wants to stay out of court where outcomes are uncertain and may depend as much on the judge as on the facts and arguments. Except for the coverage of additional areas over which there may be a legal dispute, I think that the greater legalistic clarity of GPL 3 and AGPL 3 will help to keep people out of court.

The FSF uses are not very helpful here because they can clarify the intent as needed most easily and they are unlikely to question themselves too harshly.

...

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

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

Sc * (Ci + Mt) = Co

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

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

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

...

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

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

I think that Chris Nighswonger and others answered this issue well in stating that it is a function of a license to be enforceable. I recognise that you think that the potential of enforcement spoils the spirit of cooperation. I agree that if you cannot keep the potential of enforcement out of your mind, then the spirit of cooperation might be spoilt for you. Some people including myself are actually reassured by the potential of enforcement if all else fails. Having that reassurance helps me put the potential of enforcement out of my mind and allows me to cooperate in a free manner. If the potential for enforcement would be one sided, then I would not be able to put it out of my mind. However, the potential for enforcement would apply equally to everyone, thus it would be in no one's interest to act unreasonably and seek to enforce the license against those making a good faith effort to comply.

[...]

...

3.7. EFFECTIVENESS.

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

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

If what you had meant is that software as service and data protection are not covered by AGPL 3 as raised in section 3.4 above, then see my reply there about how AGPL 3 helps with the overall problem.

...

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

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

I think that violations of the license should be given some helpful attention if we happen to notice them. If helpful attention is ineffective after much patience for some major license violation, then we should be prepared to act further. We need users in order to have "our own part of the river". We should be wary of market capture.

[...]

...

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

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

...

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

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

My information about Google's position during the GPL 3 drafting process comes from a reliable personal source. However, I do not know that my source for that information would appreciate being named. That source told me that there are logs or recordings of the discussion group meetings which could shame some parties if published. The approach which Google has taken to AGPL 3 projects on Google Code is well documented. You can search using Google to find the controversy. I agree with that the GFDL was mistakenly conceived and has outlived its usefulness. Only a documentation license compatible with the software license should satisfy.

...

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

I don't feel it's safe to draw that conclusion either.

I have several personal sources confirming that major companies represented in discussion groups refused to participate in drafting AGPL 3. Most anyone associated with FSF who had been there at the time will confirm that the level of detailed scrutiny which the discussion groups provided stopped with GPL 3.

I've criticised the exclusive drafting processes elsewhere before, including the bizarre invitations to participate which included no social enterprises and relatively few relevant not-for-profits.

There was much influence during the GPL 3 drafting stage by particular major constituents divided into small groups making comments and commenting upon the comments of everyone else. IBM's influence was certainly greater than what most people could have because they had three full time lawyers participating in the draft comment process. Other parties could have exercised some similar influence if they had the resources to invest. There is a reason to give some deference to organisations which have especially great power in the marketplace. Such organisations have great power to help or hinder the adoption of the license. If we support the basic goals of the license, we all want such organisations to help. Ultimately, the FSF board of directors decided the text of the license. The board defers significantly to Richard Stallman. None of the members of the board are inclined to compromise what they see as the core ethical principles of the license. The two significant compromises which I know had been taken to avoid threats from major companies were over patent protection and remote network use. Patent protection is much weaker than what had been desired by Richard Stallman. Remote network use became a separate license, AGPL 3, allowing the license to be easily identified and for avoiding covered software for those concerned about the effects of the license. The threatened alternative was a fork in all major GPL 2 software to retain the GPL 2 license terms. A fork by companies capable of making such a fork effective would have had a worse effect upon users than the compromise accepted.

...

3.7.1. MINIMAL STANDARD OF COMPLIANCE.

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

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

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

Obfuscating source code has never been acceptable and is a violation of the GPL. Providing a tarball or a version control repository of the Corresponding Source is a choice of the party providing the source code. We can exercise social and economic influence to encourage our prefered choice. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783

On Mon, Jul 12, 2010 at 10:16 PM, MJ Ray <mjr@phonecoop.coop> wrote:

Thomas Dukleth wrote:

...

On Mon, July 5, 2010 14:45, MJ Ray wrote:

...

...

There's also a "does not warrant" clause about interruptions (G.12). http://help.github.com/terms/

Everyone should expect that every service will have some downtime.  Even municipal emergency telephone services fail and go offline sometime.

So, basically, the "should Koha go offline" question remains.

That's a willfully excessive interpretation. IP connectivity is almost by definition inconsistent (it's packets). And bandwidth is always limited by the hardware. Are you thinking there should always be the same number of servers and identical switchgear (same model and software rev and wiring lengths to insure sameness) to support the application and the source code serving? You can always narrow that focus down to meaninglessness. -reed

[Subject changed accommodating requests for easier to follow branches of original thread.] Reply inline: Original Subject: Re: [Koha] Proposal To Switch Koha's License to GPLv3 and AGPLv3 or AGPLv3 On Mon, July 12, 2010 10:16, MJ Ray wrote:

Thomas Dukleth wrote:

...

On Mon, July 5, 2010 14:45, MJ Ray wrote:

...

...

3.1. COMPLIANCE BURDEN. [...]

[...]

...

Omitting one line of source code could be a huge compliance problem about which we should be strict. However, if we adopt AGPL 3, we should have some proportionality and understanding about imperfection while we strive to provide automation to capture changes in the Corresponding Source which would be of benefit to everyone in complying well with the license.

Sadly, while we may wish copyright law had some proportionality and understanding of reality, wishing doesn't make it so. Thanks to our colleagues in Big Music and Big Movies, copyright now seems pretty disproportionate and unsympathetic, with criminal law and amazing penalties for commercial infringement (and even not-for-profits and for-more-than-profits may be commercial).

The Free Software Foundation (FSF) has been giving support to people arguing against 'big content's' attempt to undermine the meaning of copyright law terms in court. Providing the opportunity to make copies is not equivalent to distribution (conveyance in GPL 3 terms). 'Big content' is able to buy the legislative process but logic is not for sale. I have not followed the general course of 'big content' court cases in the past several months. However, when I had lasted noted the course of events, logic and copyright terminology seemed to be much battered but surviving the attempt by 'big content' to twist their meaning in court.

So if we are going to suggest that people can be relaxed/late in meeting the Corresponding Source term, I think we're leaving them open to attack from any less sympathetic copyright holders (of Koha or included modules), as well as ourselves open to attack for advising them badly.

I have raised concerns about liability risks under AGPL 3 and sent a message to Aaron Williamson at the Software Freedom Law Center (SFLC) last week asking a sharply put question about how the Koha community could give reassurances about liability under AGPL 3.

...

...

[...]

...

3.1.1.3. LIMITING BANDWIDTH REMEDY. [...]

[...]

This is not only about "poor" connectivity and "expensive" bandwidth.

I've been and dug out my network connection contract, which includes a clause which allows the provider to "monitor network traffic levels and selectively slow down certain types of packet." That's on top of any bandwidth management we do ourselves. So that seems to mean our network provider may limit Corresponding Source download bandwidth, so it's out of our control whether we comply with AGPLv3 at any time.

I suspect that term arises from one of the interconnects like LINX and so most UK internet service contracts will include something similar.

Have many libraries got truly unlimited connectivity with free bandwidth any more? Koha support providers?

Unlimited bandwidth is not required. Demand for source code will always be finite. I will post the questions which I put to Aaron about obligations and liability which included your specific question about whether to stop remote network use of a program under AGPL 3 when the source code server goes offline.

...

...

...

3.1.1.4. SOURCE CODE HOSTING SERVICE REMEDY.

[...]

...

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

I will ask the question, although, you are welcome to ask yourself. [...]

Thank you. I will cc you if/when I get to asking it.

I asked this question of Aaron in my message to him last week.

...

[...] Additionally, Koha support companies could provide source code hosting services and indemnify their customers against copyright violations of the software license for all cases except gross negligence by the customer.

I've looked into the prices of such indemnity guarantees in the past and no client has been interested once told the price!

Indemnity may be granted without assessing a price. If a source code hosting service is providing a service, then they may be able to assume associated risk. Koha support companies may be in a position to have confidence about risks associated with Koha and assume those risks.

...

...

...

3.1.1.5. ALLOWED REMEDIES FOR OFFSETTING COSTS. [...] The token fee was meant as something for a source code hosting contract for a possible source code hosting service provided by Koha support companies even in the absence of any other support contract.

But if you're using a hosting service without paying some consideration, is a contract formed? I thought that was why a token fee was mentioned.

Yes, the token fee was my recognition from contract law of what would be necessary for a valid contract. I had imagined a hosting service bound by at least a token fee where the hosting service would be doing the work of managing the source code repository directly for the library where automation should substantially eliminate the need for personal attention from people who cost money. Such a service would be under the direction of the library with much responsibility transferred to the service. A service, such as Gitorious or GitHub, may be used for free software without paying any fee. Using Gitorious or GitHub would require some knowledge of administering git. Scripts which might be created to help the library automate the management of such a git repository would help. Such a service, would provide hosting of the source code but the repository would be more directly under the control of the library. There may be a scenario in which the library would be provided complete service by another party and would still retain complete control over everything to the fullest extent possible. I presume that the transference of responsibility via contract would require payment of at least a token fee where the retaining responsibility would not. In all this I should state that I am not a lawyer, although, I have experience doing legal research at the direction of lawyers. I have never researched contract law and have merely a well informed popular understanding of contract law. [...]

...

Aaron had seemed to imply that parties with responsibilities for complying with the license need to control or direct their own compliance but could contract with others to provide such services.

I think a market in compliance services is an evil bureaucrat's dream and not something which the Koha community should encourage by picking such an ununderstood licence.

People at libraries should not be frightened or overly anxious about copyright liability. Risks of copyright violation have to be managed for libraries every day. Providing access to materials with or without copy machines exposes libraries to the risk of being sued for facilitating copyright infringement. Library administrators unduly fearful of unreasonable action over any possible copyright violation would need to close the library. Reasonable policies help manage risks and AGPL 3 would be a small addition to all the other risks of libraries which would be duly addressed.

...

But maybe that's just my idealism talking after looking into how commercial broadcasters in the UK handle compliance by licensing it out to the smallest surviving commercial network company (Channel Television, which serves the 160,000 population of the Channel Islands) so that the fines are limited (because the maximum is currently set at 5% of company advertising income).

If we would introduce an AGPL 3 version of Koha, support companies would not have the power of regulated broadcast monopolies.

...

...

...

3.3. SECURITY CONFIGURATION. [...] Section 1 of the license clarifies the issue of automatic generation.

"The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source."

I don't think that effective security settings can regenerate automatically at the moment. Maybe they should and this is a bug in koha to report at bugs.koha-community.org which should block AGPL 3 adoption.

If we choose to upgrade to AGPL 3 for Koha 3.4, we should file some blocker bugs for issuing an AGPL 3 release until there is some automated support for complying with the license. There would also be blocker bugs for Open NCIP and NCIP 2 code license compatibility We are at least several months from the prospect of a Koha 3.4 release with or without AGPL 3.

...

...

...

3.4. DATA. [...] Lack of such coverage in AGPL 3 is not a reason to object to AGPL 3 for an issue it could never have addressed with any certainty.

Why not?

Copyright licenses are only effective in the domain of copyright. Software licenses specifically are only effective for software. [...]

That's a misleading place to cut. I meant: why not object to AGPL 3 for *not* being a significant "measure of protection more against Koha related code becoming locked up on a saas platform"?

A copyright license is not a data contract. I think that your particular request that the copyright license should address more is similar to asking why apples are not oranges or oranges are not apples. The fact that apples and oranges are not the same does not keep you from having both apples and oranges. Maybe you have a clever way of making an apple/orange hybrid. I would be happy to taste your hybrid, if you have one.

...

What AGPL 3 does do is allow users of software as a service to take the software which they have been using a server which they do not control and move it to a different server including their own server over which they would have complete control.

AGPL 3 is much more limited than that. Only the source code of the one public-facing service can be taken. Much other software, including the database, may remain locked up.

FSF is encouraging the development of software which uses a different database model ensuring that users can run a local copy of the database in which private information is encrypted but everyone can have a copy of the whole database. We should consider the possibility of such a distributed design for Koha. Such a distributed design may never be sufficiently efficient for Koha but the possibility should be considered.

[...]

...

Users are often all too ready to sign away their freedom. We need to do our best to help them appreciate the benefits which freedom brings.

I agree. Moreover, it would give a much better return than upgrading to a licence which doesn't address the main threat to this community and brings with it significant uncertainty and extra hurdles.

...

...

...

3.6. COMPULSION OR COOPERATION. [...] Some people including myself are actually reassured by the potential of enforcement if all else fails. [...]

It should be small comfort. Based on the lack of will to take a stand over easier-to-win smaller battles, I believe it would take something absolutely massive for the licence to be enforced and locking-in customers is below that "absolutely massive" level, so the only people who will keep to the licence are those who would do the right thing anyway.

I'm not dwelling on topics in this strategic section now.

...

...

...

3.7. EFFECTIVENESS. [...] Other parties could have exercised some similar influence if

[...] they had the resources to invest. [...]

They couldn't because they also needed to be invited by the FSF. Some organisations were invited belatedly and others never were.

I'm not dwelling on topics in this strategic section now.

A commitment of sufficient resources to the process may well have produced an invitation to participate in a GPL 3 drafting discussion group. I recognise that the drafting process had significant problems which FSF should strive to improve for the next time FSF runs a license revision process. The question is now which license serves the interests of the Koha community best.

...

...

...

3.7.1. MINIMAL STANDARD OF COMPLIANCE. [...] On this point about whether obfuscated source is a net benefit or not, I realise that my view is not universal and I accept that.

Obfuscating source code has never been acceptable and is a violation of the GPL.

I feel it's somewhat less clear-cut than that: if you're doing it to hinder others, then it's a violation, but what about if the obfuscated source code is their preferred form for modification? One person's neat coding that ignores community code guidelines is another's obfuscation.

The biggest problem in this regard is machine optimisation of source code which can be a form of obfuscation for humans attempting to read the code, especially when variables are renamed to one character. The prospect of legal discovery that the optimised form is not the form actually used for development should help reduce the temptation to convey machine optimised code as if it would be the Corresponding Source. Machine optimised code is generally object code. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783

Reply inline: On Tue, July 13, 2010 20:26, david@lang.hm wrote:

On Tue, 13 Jul 2010, Thomas Dukleth wrote:

[...]

...

People at libraries should not be frightened or overly anxious about copyright liability. Risks of copyright violation have to be managed for libraries every day. Providing access to materials with or without copy machines exposes libraries to the risk of being sued for facilitating copyright infringement. Library administrators unduly fearful of unreasonable action over any possible copyright violation would need to close the library. Reasonable policies help manage risks and AGPL 3 would be a small addition to all the other risks of libraries which would be duly addressed.

but the probelm is that the people at libraries understand what to do with books to comply with copyright. It's not nearly as clear what they would need to do with software (as this discussion shows, even programmers aren't clear on what is needed to comply)

Most programmers do not know about how to comply properly with the familiar GPL 2 license at the level of attention detail about which I have been enquiring. However, when those modifying the software basically respect the users, then misunderstandings are corrected when needed and there are no serious problems. If the Koha community would choose to adopt AGPL 3, we would need to develop an automated system which assists libraries in complying with AGPL 3 specific requirements. In most cases, libraries have contracts with support companies and support company contracts will likely assume the responsibility for AGPL 3 compliance. I am concerned about the other cases. I am concerned about the libraries doing everything themselves with only the mailing list for support. Those libraries need an automated system to help them. They would also have the experience of the support companies and other libraries to assist them.

...

...

...

...

...

3.3. SECURITY CONFIGURATION. [...] Section 1 of the license clarifies the issue of automatic generation.

"The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source."

I don't think that effective security settings can regenerate automatically at the moment. Maybe they should and this is a bug in koha to report at bugs.koha-community.org which should block AGPL 3 adoption.

If we choose to upgrade to AGPL 3 for Koha 3.4, we should file some blocker bugs for issuing an AGPL 3 release until there is some automated support for complying with the license. There would also be blocker bugs for Open NCIP and NCIP 2 code license compatibility We are at least several months from the prospect of a Koha 3.4 release with or without AGPL 3.

...

...

...

...

3.4. DATA. [...] Lack of such coverage in AGPL 3 is not a reason to object to AGPL 3 for an issue it could never have addressed with any certainty.

Why not?

Copyright licenses are only effective in the domain of copyright. Software licenses specifically are only effective for software. [...]

That's a misleading place to cut. I meant: why not object to AGPL 3 for *not* being a significant "measure of protection more against Koha related code becoming locked up on a saas platform"?

A copyright license is not a data contract.

[...]

especially in light of the e-mails on the list about how a dump of code is not that useful (the changes need to be merged and that is the responsibility of the submitting orginization) I have to ask again what you plan to get by changing the license.

it doesn't prevent the data from being locked up by hosting companies.

it doesn't get code into the upstream koha (it does make it possible to get a dump of the code, but this will be without even version control clues like you have with the libline code so it will be even harder to deal with)

so what is this solving?

The software license is part of the solution by making the version which any particular library is using portable. The library could install that version elsewhere under their own control with any effective access to the source code. If the library is using AGPL 3 software, lock-in would not be based on software code. Perfect version control is not needed to install a particular version on a server under the control of a library. AGPL 3 gives power to remote network users of software where they would not have it otherwise. Moving code from your version upstream would be better and AGPL 3 would make integrating code possible even if it would not necessarily be easy. AGPL 3 does not stop service providers from doing more or stop users from insisting upon more. AGPL 3 is not the whole solution, but it is part of a solution to the general problem of user freedom in the context of remote network use of software. Other remedies are needed to address other parts of the problem. [...]

...

FSF is encouraging the development of software which uses a different database model ensuring that users can run a local copy of the database in which private information is encrypted but everyone can have a copy of the whole database. We should consider the possibility of such a distributed design for Koha. Such a distributed design may never be sufficiently efficient for Koha but the possibility should be considered.

I haven't heard this before, could you point me at info on this?

See the document which MJ Ray had cited as one example. Who does that server really serve? / by Richard Stallman. - http://www.gnu.org/philosophy/who-does-that-server-really-serve.html . Richard is thinking most particularly of collaborative network programs such as facebook. See the Franklin Street Statement, http://autonomo.us/2008/07/franklin-street-statement/ , and http://autonomo.us/ generally. Autonomous was set up to explore network service issues and develop ideas which FSF and the GNU project could adopt in future after they have been carefully thought through. FSF will take its own good time to do more about network service issues directly but we do not need to wait upon FSF to resolve all the problems. We should do what we can for ourselves. AGPL 3 is part of the mix of things which can be done. The problem which it solves may be a small part of a larger problem. However, we should be pleased that it helps greatly in large set of client server user cases which include Koha. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783

[I have changed the subject of this part of my reply to a different thread most relevant to the issue raised.] Reply inline: Original Subject: Re: [Koha] AGPL 3 objections and replies On Wed, July 14, 2010 01:01, david@lang.hm wrote:

On Tue, 13 Jul 2010, Thomas Dukleth wrote:

...

On Tue, July 13, 2010 20:26, david@lang.hm wrote:

...

On Tue, 13 Jul 2010, Thomas Dukleth wrote:

...

...

...

...

>> 3.4. DATA.

[...]

...

The software license is part of the solution by making the version which any particular library is using portable. The library could install that version elsewhere under their own control with any effective access to the source code. If the library is using AGPL 3 software, lock-in would not be based on software code.

I disagree with this assertion. It's very easy to have AGPL3 software which talks to some other service that is not open. This would prevent people from setting up their own instance.

This could be something as simple as tieing in to some proprietary authentication server. you would be abel to get all the interface code, but unless you have the server to talk to you are out of luck. Yes, this simple example could be hacked around, but my point is that getting the source does not equate to being able to run your own instance of the service.

Corresponding Source for the object code form does "equate to being able to run your own instance of the service." The object code form is the form applicable to AGPL 3 specific obligations to remote network users. Section 1 of the license clarifies. "The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities." See the full explanation given at http://tinyurl.com/24nwjdv . [The link is to the message in Nable. Apparently, a bug in the Mailman archive copy at Katipo truncated the message just before a line ending with a colon in the body of the message.] I changed the subject to "Corresponding Source under AGPL 3" in my subsequent replies to accommodate requests for easier to follow branches of the origin al thread.

If you try to say that the AGPL3 means that every service needed to run the code must be available, that would prohibit using Oracle as a database, or Active Directory as an authentication service (things that I am sure someone is doing somewhere that I'm sure we would all agree are perfectly legitimate)

If Oracle would be used as an unmodified separate work with standard communication protocols and the SQL standard database language especially with DBI as a database independent abstraction, then Oracle would not be part of the Corresponding Source. Use of Active Directory as an unmodified separate work would be a sufficiently similar case with standard communication protocols, the LDAP standard, and the Kerberos authentication standard, then Active Directory would not be part of the Corresponding Source. Under most circumstances, free software could be substituted to provide identical functionality to use of Oracle or Active Directory. [...]

...

AGPL 3 is not the whole solution, but it is part of a solution to the general problem of user freedom in the context of remote network use of software. Other remedies are needed to address other parts of the problem.

I don't see AGPL3 being effective in blocking a bad actor. It's just too easy to setup whatever you don't want to share as a separate application and then modify Koha to access it via a web services call (or other RPC-like API)

Attempting to disguise one work as multiple works would fail on legal grounds because a clear case of bad faith would be evident as failure to comply with the license. Most likely the bad actor would also be careless enough to have otherwise failed in some details to create separate works under copyright law. In the history of GPL enforcement, the worst bad actors have been the most careless and given up once properly exposed. Our goal should not be to worry excessively about how some people might try to evade the license. Our goal should be to build tools to make co-operation the easiest and most profitable route with the license encouraging that co-operation. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783

My correspondence with Aaron Williamson at the Software Freedom Law Center (SFLC) about liability under AGPL 3 is quoted further below. The unrelated issue about third party module notices should have been in a different message. The messages are reproduced exactly except that I have corrected a mistake which I had made for the correct date of the #koha IRC meeting about voting on upgrading the license. The correct date is 13 July, today. I had misremembered the date as 16. I asked a following question focused on an aspect of the liability issue on which I had primarily intended to concentrate. That most recent message is quoted directly below and I am still awaiting an answer concentrating on that aspect of the issue. Overall, libraries are accustomed to having copyright responsibilities. Some responsibilities associated with a copyright license for there ILS software would be merely one more responsibility for which they would need to do something special. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 ---------------------------- Original Message ---------------------------- Subject: Re: AGPL 3 liability and unrelated question for 3rd party module notices From: "Thomas Dukleth" <koha@agogme.com> Date: Tue, July 13, 2010 15:10 To: "Aaron Williamson" <aaronw@softwarefreedom.org> -------------------------------------------------------------------------- Aaron, Thank you for your clear answer about an obviously old question of inadvertent license violation liability and cutting the scary straw man I could imagine down to size. There is one particular aspect on which I want to focus. If a copyright holder would ever have reason to contact a party whom the copyright holder considers an inadvertent violator of GPL 3 or AGPL 3 to help the violator understand how to comply with the license, is there any formal legal way for the copyright holder to set the clock back on the first time cure protection in section 8? Any means which could be exercised to repeatedly undue a first violation notice as long as the belief persists that the violating party is acting in good faith would be reassuring to well meaning parties. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 ---------------------------- Original Message ---------------------------- Subject: Re: AGPL 3 liability and unrelated question for 3rd party module notices From: "Aaron Williamson" <aaronw@softwarefreedom.org> Date: Tue, July 13, 2010 14:38 To: koha@agogme.com -------------------------------------------------------------------------- On 07/07/2010 02:45 PM, Thomas Dukleth wrote:

1. LIABILITY FOR AGPL 3 VIOLATIONS.

Q.1. If the Koha license would be upgraded to AGPL 3, what can the Koha community or individual copyright holders do to reassure those running the software that the license would not be enforced unreasonably or over-zealously against parties acting in good faith?

This question is as old as the GPL, and while the novelty of the AGPL might draw it into somewhat sharper relief until people become comfortable with that license, the issues are the same. It is true that inadvertent violations may somewhat easier if someone else is hosting your source code, but in the end every flavor of the GPL allows a single developer in a project with distributed ownership to enforce his/her copyrights. It is community norms and a general prevailing reasonableness among contributors that prevents this. As for the question of source-hosting server downtime, I don't know that anyone's brought the issue up before, but I think reasonable people would probably agree that "equivalent access" can be interpreted to mean something like "roughly the same bandwidth and uptime." Certainly equivalent doesn't mean *exactly* the same bandwidth at every microsecond, and reasonable server outages are to be expected. Does that mean a rogue developer couldn't attempt to pounce on someone for a brief outage? No, but I wouldn't represent him, and I don't know who would.

1.1. TAKING SOFTWARE OFFLINE.

Q.1.A. If the server providing access to the Corresponding Source under AGPL 3 goes offline, should the AGPL 3 software be taken offline?

For the reasons above, I think not.

2. UPGRADING THE LICENSE FOR UNMODIFIED THIRD PARTY MODULES.

Q.2. What is the best possibility for noting that unmodified third party GPL 2 modules, with an or later version option, are also available under GPL 3 or AGPL 3, with an or later version option?

I'd be inclined to put this in your top-level licensing file for Koha, or in another top-level file describing AGPL compliance. I would definitely *not* modify license headers -- people feel very strongly about changing license headers on code you haven't modified, even if the license itself allows you to distribute under another license. But I'm not sure it's necessary to do anything at all. The license of those modules is still GPLv2+ -- you're using them in a way that causes your license to be AGPLv3+, but others are free to use them independently under GPLv2. Aaron ---------------------------- Original Message ---------------------------- Subject: AGPL 3 liability and unrelated question for 3rd party module notices From: "Thomas Dukleth" <koha@agogme.com> Date: Wed, July 7, 2010 18:45 To: "Aaron Williamson" <aaronw@softwarefreedom.org> -------------------------------------------------------------------------- Aaron, Some questions arise for AGPL 3 responsibility or liability, and an implementation detail. The vote on whether to upgrade the license for Koha is coming 13 July. There is a general Koha IRC meeting 7 July. I have some simple answers of my own for liability in questions Q.1 and Q.1.A. However, answers which I have thought for those questions do not necessarily satisfy others and I do not know if some answers which I might give would be correct. I have some scenarios for supplying automated notices for question Q.2 but need direction about which is better or what other alternative might be better. 1. LIABILITY FOR AGPL 3 VIOLATIONS. Q.1. If the Koha license would be upgraded to AGPL 3, what can the Koha community or individual copyright holders do to reassure those running the software that the license would not be enforced unreasonably or over-zealously against parties acting in good faith? Participating in Koha development is open to everyone. Copyright is held by contributors; there is no assignment of copyrights for Koha. Koha incorporates the copyrighted work of people outside the Koha community for some modules which Koha uses. I am aware of the protections for innocent violators of the license in section 8. Those protections include a first time cure provision but few people have only one mishap or make only one mistake. Servers, switches, routers, power, etc. are all vulnerable to failing. Even the most reliable services suffer from an occasional outage. People running libraries are generally very cautious about potential liability for violation of copyright law and tend to avoid risks which others might think trivial. Even when libraries are part of institutions with significant resources, libraries tend to be poorly funded relative to their responsibilities with no provision for expenditure outside their normal course of business. I know of one important library automation systems developer and now library journalist who thinks that libraries would never use AGPL software. I can imagine that there are people who attempt to enforce their copyrights unreasonably. I can even imagine that there may be a programmer opposing AGPL and intent upon scaring people away from running AGPL software with a maniacal zeal. I do not know of any such actual person but I can imagine the possibility. Such a person might seek out AGPL projects to which he could contribute. He might then attempt to identify and pounce upon the smallest inadvertent violation of the license. Perhaps in the last fanciful concern I raise a straw man. However, those opposed to AGPL would raise many arguments about why AGPL software should not be used. We would need to be prepared to have answer for any fear which might be effective in scaring away a large portion of potential adopters of the software. 1.1. TAKING SOFTWARE OFFLINE. Q.1.A. If the server providing access to the Corresponding Source under AGPL 3 goes offline, should the AGPL 3 software be taken offline? As explained above, people running libraries have heightened concerns about legal liability. At the same time, libraries would find the risk of needing to take the software which runs the library offline as a means of controlling legal liability to be unacceptable. Faced with the possibility of needing to take such a choice those running libraries might be generally inclined to avoid AGPL software. 2. UPGRADING THE LICENSE FOR UNMODIFIED THIRD PARTY MODULES. Q.2. What is the best possibility for noting that unmodified third party GPL 2 modules, with an or later version option, are also available under GPL 3 or AGPL 3, with an or later version option? We would seek to avoid unnecessary maintenance of license statements for projects which the Koha community are not maintaining ourselves but which are incorporated into Koha as part of the Corresponding Source under AGPL 3 specific obligations. We may want to update unmodified third party modules under GPL 2, with an or later version option, using an automated script to download the source code for new versions of the modules from upstream sites. We would then need a good means of including license terms invoking GPL 3 or AGPL 3, with an or later version option as an alternative to GPL 2, with an or later version option. We could create a script which adds an additional header to all source code files. However, the source code in actual Koha installations would be unlikely to be altered with additional headers. Almost all installations of Koha use Debian packages with some additional packages from CPAN. There is also a recently introduced Koha Debian packages repository which includes modules which formerly had only been available from CPAN or elsewhere. We could have a single copyright file for Koha which identified the additional GPL 3 or AGPL 3 invocation, with an or later version option, for unmodified third party modules otherwise available under GPL 2, with an or later version option, which have been incorporated into Koha. Under such a scenario, the unmodified third party modules would not have their headers modified. Alternatively, we could add an additional copyright file to each of the unmodified GPL 2, with an or later option, third party modules. The unmodified third party modules would also not have their headers modified. The question implies the possibility of some other scenario which had not occured to me. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783

[This is the third 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 the second message for the schedule which I had originally intended. I delayed sending the original contents of this message to keep the chronology of events to which the messages refer clear.] Quoted further below is correspondence between Aaron Williamson at Software Freedom Law Center (SFLC) and myself over derivative works as applied to software generally and source code conveyance obligations under GPL and AGPL 3 specifically. There are four messages. I have yet to have a reply to the two most recent messages. [The text of the messages is quoted exactly except that I changed the form of quotation marks which Aaron had used in quoting from the license. In the exact form of his reply, there had been no distinction between his quotation of the license text and his quotation from my earlier message. There is some point at which I had used the wrong word in my first message which was not a misspelling. I would correct that mistake but I do not remember where it is now.] 1. DERIVATIVE WORKS IN RELATION TO SOFTWARE. In the first message which I sent to Aaron about derivative works I provided an explanation of how derivative works function in relation to software. Unfortunately, in my effort to be brief I oversimplified the issue to a degree which I should not have done for the present discussion. I have privately shared a very complete and lengthy explanation of derivative works in the context of software and various licenses. I spare the list such a complete and lengthy explanation of derivative works at the present time. Please understand that my explanation given in section 1 of the oldest message, from 27 May, quoted further below is an oversimplification. I corrected that oversimplification for an important issue of discussion on telephone with Aaron and in section 2 of the 29 June message quoted further below. 2. SPECIALLY RESERVED RIGHT TO BE WRONG. When I spoke to Aaron on telephone, after he had sent the message quoted further below from 2 June, he specifically reserved the right to be wrong. He explained that he had done some original research in answering in which he did not have full confidence, as he had not had the opportunity to discuss the issue with others at SFLC. I explained to Aaron that he should always reserve the right to be wrong as I always do. However, I seldom make it a special point to identify the fact that I have reserved that right. I believe that Aaron had meant to reserve the right to be wrong in the special context of the justification for why Koha does not need to include MySQL in the Corresponding Source. Aside from a modest muddle at the edges, I have no concern about the MySQL non-issue. I think that the issue for which Aaron should have specially reserved the right to be wrong is the issue for Aaron's claim that Koha does not need to include unmodified third party Perl modules in the Corresponding Source under AGPL 3. 2.1. MYSQL NON-ISSUE. During the course of my meeting with Aaron in late May I had misinterpreted the key reason which he had given or at least intended to give for why Koha need not be understood to be partly a derivative work of MySQL. Koha uses DBI::Perl to access MySQL. DBI::Perl is an abstraction which allows substituting another database other than MySQL. Koha has some MySQL specific code for which a Postgres alternative should be provided, however, it is not substantive enough to be of much concern for license compatibility. If the Koha community upgrades the Koha license to GPL 3 or AGPL 3, Oracle will not be pursuing the Koha community to obtain a special MySQL license to use an GPL 3 or AGPL 3 Koha with GPL 2 only. MySQL AB had pursued proprietary closed source software companies requiring them to obtain a proprietary license to MySQL merely for using MySQL as a database with MySQL specific calls. MySQL AB had asserted that without a special proprietary license mere use of MySQL created a derivative work which required abiding by the particular version of the GPL used by MySQL at the time. 2.2. PERL MODULES ISSUE. I think that at least for conveying the Corresponding Source under AGPL 3 we are required or should be required to include Perl modules. Aaron has given a different interpretation of the license. Aaron has stated that the source code only conveyance of Koha does not require including unmodified third party modules under AGPL 3 specific terms. He has stated that unmodified third party modules would only be required if Koha would be conveyed in object code form. I think that Aaron is mistaken. Aaron cites what he interprets as the distinctive definition of Corresponding Source for justification. GPL 2 section 3 gives distinctive definition of the source code for an executable work. GPL 3 and AGPL 3 section 1 also gives a distinctive definition for the Corresponding Source for a work in object code form. That definition is followed by a definition of the Corresponding Source for the source in object code form. "The Corresponding Source for a work in source code form is that same work." I do not read the lack of a definition for Corresponding Source in GPL 2 or the definition provided in GPL 3 and AGPL 3 as any more informative. Both the absence and presence of a definition seem to be a tautology such as 'the source code of X is the source code of X' or the 'Corresponding Source is the Corresponding Source'. Guidance is provided for understanding what should be considered part of a work for object code form about which people may be confused. AGPL 3 seems to me to introduce a need for comparable guidance for source code form because its specific obligations are only operative when a program is sufficiently functional and complete to have remote network users. Whether or not guidance is present in the license, the definition of a work is the same irrespective of the form in which it is embodied. The definition of a work comes from copyright law and court interpretation, but not from a copyright license. I provide an awkward alternative in my message from 29 June further below. The consequence which I describe below for Aaron's assertion to be correct is that the license would not be meaningful in a vitally important respect. I think that the confusion over the issue of including third party modules, which have not been modified directly, in a source code only conveyance under AGPL 3 is not really that AGPL 3 is untested as MJ has raised as an objection. I suspect that the nuances of AGPL 3 are merely unfamiliar to SFLC because they have yet to have sufficient need to examine the nuances closely. I doubt that SFLC has yet undertaken any enforcement action over AGPL 3. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 ---------------------------- Original Message ---------------------------- Subject: Re: Correspondence of Corresponding Source and derivative work relationships From: "Thomas Dukleth" <koha AT agogme.com> Date: Fri, July 2, 2010 06:31 To: "Aaron Williamson" <aaronw AT softwarefreedom.org> -------------------------------------------------------------------------- Aaron, Please note a correction in my explanation for the questions from my message of three days ago quoted further below. I had mistakenly suggested that the FSF practise of deference to source code only conveyance is merely a practical courtesy in not requiring the inclusion of unmodified third party modules. I still think that you seem to be reading an interpretation into the license for source code only conveyance which does not match the special condition of AGPL 3 obligations. In contrast to my own mistaken suggestion, I explained the issue best when I identified the fact that outside of the special conditions of AGPL 3 a source code only work conveyed may be non-functional or incomplete. The GPL cannot generally require that a broken source code only conveyance be fixed or that missing features be added. The 'correspondence' for the 'Corresponding Source' in a source code only conveyance need not be anything more than whatever source code happens to have been conveyed. As I explained in section 1.1.2 of my message from three days ago, the following difference is important for AGPL 3. "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 [for AGPL 3 specific obligations] must be a complete functional work which may imply some of the concern which had motivated the guidance provided in the definition of Corresponding Source for object code." The fact that there is no guidance covering conveyance in source code only form under AGPL 3 does not mean that similar guidance to guidance for object code form would not be useful and appropriate. The omission of such guidance does not imply that absent guidance should not be applied as appropriate. Please answer the questions from my message quoted below with reference to the emphasis on the difference identified above in Corresponding Source as applied to AGPL 3. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 [...] ---------------------------- Original Message ---------------------------- Subject: Correspondence of Corresponding Source and derivative work relationships From: "Thomas Dukleth" <koha AT agogme.com> Date: Tue, June 29, 2010 22:03 To: "Aaron Williamson" <aaronw AT softwarefreedom.org> -------------------------------------------------------------------------- Aaron, I have some remaining confusion about the requirements for conveying Corresponding Source in the GPL. Unexplained inconsistencies can result in the failure of running code and also the failure of license interpretation. The confusion I have follows from your assertion that Corresponding Source is different between a work in object code form and a work in source code form. The inconsistencies are undermining my capacity to intelligibly explain how GPL 3 or AGPL 3 would apply to Koha. The best I have managed is try to formulate a seemingly awkward explanation of the license which corresponds to an affirmative answer to question Q.1.A., Corresponding Source and Requirement Correspondence, further below. However, I am more inclined to believe that the correct answer is an affirmative answer to question Q.1.B., Corresponding Source and Work Correspondence, further below, which would contradict your assertion. Your interpretation has led me into my muddle. I hope that you can lead me back out again. I worry mostly about the integrity of the license to not be self-contradictory in relation to copyright law. The possible scope for evasion of the license intent is a lesser concern in this context than an interpretive problem which might undermine the license meaning more generally. The greatest hazard within the scope for evasion of license intent which may follow from a self-contradictory interpretation of the license risks undermining the source code obligation of those conveying GPL programs in object code. Please remember that my presumption of what constitutes a derivative work in relation to software under copyright law matches what I have understood the FSF position to be, as it has been explained over the years in relation to examples involving object code. I have presumed that source code and object code forms of a work had significant parity in relation to merely being a different embodiment of the work. The goal of the GPL is well understood to ensure that the user can exercise his rights, in part by ensuring access to the source code of a GPL program. The practical exercise of other user rights under the GPL follow from access to the source code. You identified an FSF practise of giving deference, with respect to the issue of including third party modules in the Corresponding Source, when a GPL program has been conveyed to the user in source code form only. Reasonable deference to the virtues of those conveying source code as the sole means of conveyance may be a helpful FSF practise. Such a deferential practise would be better than attempting be overly strict with those conveying in source code only form. Source code only conveyance serves the intent of the license especially well and those who have who convey in source code only form may be worthy of some deference for having started ahead of others who convey in object code form. There is a danger in attempting to treat the FSF practise of deference as anything more than a special courtesy for good will in license enforcement. Great care should be taken to avoid reading a basis of practise into a part of the license where the distinction cannot be fully supported without violating copyright law. Any valid interpretation of a valid copyright license should conform to copyright law as it would be interpreted by the courts if there would ever be a dispute on the issue in which the license is challenged. 1. QUESTIONS. 1.1. CORRESPONDING SOURCE CORRESPONDENCE. Q.1. What is Corresponding Source intended to 'correspond to' in GPL 3? Copyright law determines the scope of a work. The source code of a work is thus fixed by copyright law independent of whatever form, source or compiled, in which a work may be usually conveyed. Copyright licenses might impose disparate requirements to comply with the license in disparate conditions which all conform to the objective of the license. License terms may guide the user in the correct application of copyright law but must not contradict copyright law. 1.1.1. CORRESPONDING SOURCE AND REQUIREMENT CORRESPONDENCE. Q.1.A. Is 'Corresponding' Source intended to 'correspond' to the 'scope of the license requirement' to provide source code independent of the scope of the work? As an example of 'corresponding' to a requirement independent of the work, some possible software license with a different objective than the GPL might require a payment of $10 for object code conveyance and payment of $100 for source code conveyance. In this example, the 'scope of the license requirement' 'corresponds' to the type of software conveyance without impinging upon a domain specified by copyright law. As another example, some possible software license with some similar but much more limited objective to the GPL might require providing users only the opportunity to obtain source code for data compression used in a program for original object code conveyance and have no specific source code requirement for original source code conveyance. In this example also, the 'scope of the license requirement' 'corresponds' to the type of software conveyance without impinging upon a domain specified by copyright law. 1.1.2. CORRESPONDING SOURCE AND WORK CORRESPONDENCE. Q.1.B. Is 'Corresponding' Source intended to 'correspond' to the 'scope of the work' and thus the requirement to provide source code dependent upon the scope of the work? If 'Corresponding' Source 'corresponds' to the 'scope of the work', then a requirement to convey the Corresponding Source must have the same scope irrespective of whether the program has been conveyed to the user in source or object code form. The work is the work under copyright law and the scope of the work cannot change by the form in which it is embodied. Take the analysis given in the license of what constitutes Corresponding Source for object code forms of a work. Use that analysis to create the source code form of the same work. If that source code form of the work is conveyed in source code form only, the Corresponding Source obligation clearly cannot be diminished in such a case because the work is the same. Answering that works developed for source code distribution have a categorically different relationship to third party modules is mistaken. Compilers for programming languages in which programs are usually conveyed in source code form is one example of the falsity of a claim that object code forms and source code forms generally relate to a work which is substantially different. The definition of Corresponding Source for source code form is merely a tautology. "The Corresponding Source for a work in source code form is that same work." I have supposed that the lack of equivalent guidance as to the scope of Corresponding Source for a source code form of a work is merely than the need for guidance arose in the context of object code form conveyance where the is the hazard of a mismatch between the source code offered and the object code conveyed. 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 which may imply some of the concern which had motivated the guidance provided in the definition of Corresponding Source for object code. Sadly drafting the distinctive terms of AGPL 3 did not receive the same degree of scrutiny as had been given to drafting GPL 3. A diminutive folk conception of the scope of a work may be commonplace but in a legal concept folk conceptions should be understood as insufficiently precise. Ultimately, we hope that laws reinforce our most fundamental shared moral folk concepts. 1.2. INCLUDE MEANING INCLUDE. Q.2. Does a 'program include' mean 'include within the scope of the work'? Many programming languages use program 'include' functions to call module dependencies. Include functions are invoked variously with commands such as 'use', 'include', and 'require'. Such commands are very different from fork or exec, and also very different from communication with a third party program over a general purpose protocol. Includes include another program directly into the calling program irrespective of whether the program is in source or object code form. Includes function similarly to linking when compiling programs. Such 'include' relationships should mean that programs thus included are a dependency of the calling work in a manner which makes them part of the calling work. Similarly the calling work is a derivative work of the included work requiring license compatibility with the included work. Given the license tautological definition of Corresponding Source for a work in source code form, the license would not exclude 'included' modules from a work in source code form. 1.3. APPLICABILITY OF MODULE LICENSES. Q.3. Is the requirement to follow the copyright license for a third party programming module different when the program incorporating the module is conveyed in object code as distinct from source code only conveyance? [For the purpose of this question, suppose that in the case of the source code only conveyance alternative, a programming module is not conveyed but has not been internally modified. Such a supposition merely posits the case in which you had suggested that third party modules do not need to be conveyed to users even if the modules are clearly included as incorporated within the functioning of the program.] The GPL Wrapper FAQ question may address the issue the issue indirectly if the wrapper part is ignored, http://www.gnu.org/licenses/gpl-faq.html#GPLWrapper . However, the GPL FAQ generally refers to linking implying examples from object code form if there is a difference. 2. HOW DERIVATIVE WORKS APPLY TO SOFTWARE. I repeat my brief explanation of how derivative works apply to software with a small clarification. I have included a necessary exception which I had omitted in my somewhat briefer simplified form. The exception explains how Koha need not include MySQL in the Corresponding Source. In the interest of brevity, I do not present a fully nuanced set of exceptions. Exceptions addressing addressing parties creating some types of modifications directly or acting under the direction or control of a common party are excluded. I also do not give an account of community toleration of GPL licensed programs which may violate the GPL but which otherwise advance community interests in a manner which could not be advanced without violating the GPL. I present an analogy to how copyright law is well understood in comparable application to the copyright of books. 2.1. DERIVATIVE WORK RELATIONSHIPS. Functional calls to a program can invoke a derivative work relationship to the called program as a dependency of the calling program. Calls which act upon the called program as an entirely separate process, or over a standard communication protocol, or standard API: do not include the called program within the calling program and thus do not invoke a derivative work relationship to the called program. The test which I have used for determining a derivative work relationship is whether the work as a whole would function if a particular dependency would be removed and would the dependency has not been called as part of a derivative work relationship. If a call is sufficiently generalised to not exclusively require a particular dependency, then multiple alternative dependencies may be substituted and no derivative work relationship to the called program would be entailed. Given the rigid linear manner in which program control is generally coded, omitting a dependency for which no alternative can be substituted would usually be liable to cause the entire program to fail. A program which calls a dependency without a generalised protocol, does not call the dependency as an entirely separate process, and for which the particular dependency has no readily substitutable alternative: establishes a derivative work relationship to the called program. 2.1.1. COMPARABLE CASE OF DERIVATIVE WORKS APPLYING TO BOOKS. The relationship is analogous to the analysis one might give to a book where some new wholly original material is contained within book which also includes a collection of other works organised in some useful manner. Permission is need to include the other works in the book. The book would not have the same meaning intended in organising the various parts if a section would be omitted. 2.2. MERE DATA LINKING. Functional calls are very different from mere data linking. Mere data linking does not establish a derivative work relationship. An HTML hyperlink or other simple data link is an example of a mere data link which does not necessarily establish a functional dependency on the linked content by the program from which the link is being made. If the data resource to which a link is being made is unavailable, the program would probably continue to function and the user would merely not have the data from the particular resource. There is no functional dependency which would necessarily cause program failure if a data link would be omitted. 2.2.1. COMPARABLE CASE OF MERE CITATION OF OTHER WORKS APPLYING TO BOOKS. The analogous case for books is that of a bibliographic listing. Books may have HTML hyperlinks for bibliographic links if the book is presented in electronic format. However, both the paper version with no hyperlinks and the electronic version with hyperlinks have the same functional integrity. The book containing the bibliographic listing would continue to function correctly whether or not a work listed in the bibliography would be available to the reader. 2.3. FSF INTERPRETATION. As far as I have understood, the interpretation given in this major section for how the derivative works concept in copyright law applies to software is the interpretation which FSF has always advocated and the correct interpretation. Please correct me if my understanding is mistaken. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 ---------------------------- Original Message ---------------------------- Subject: Re: Questions about upgrading Koha to AGPL 3 or GPL 3 From: "Aaron Williamson" <aaronw AT softwarefreedom.org> Date: Wed, June 2, 2010 22:10 To: koha AT agogme.com -------------------------------------------------------------------------- On 05/27/2010 10:48 AM, Thomas Dukleth wrote:

1.1. DERIVATIVE WORK RELATIONSHIPS.

Functional calls to a program invoke a derivative work relationship to the called program as a dependency of the calling program. The test which I have used is whether the work as a whole would function if one would remove a particular dependency.

I think that this is too broad a definition of a derivative work, and is inconsistent with the FSF's traditional interpretation of the GPL. Your test would yield results that contradiction to FSF's historical interpretation. For example, when a program interacts with another program via fork and exec calls, the FSF generally considers them to be separate programs.[1] And when a program interacts with another program via standard interprocess communication or network protocols, the FSF has usually considered the programs to be separate works.[2] So I think your test is too rigid. If we accept this interpretation (and since the FSF has been espousing it for years, we would be in good company), then it is a simple matter to declare MySQL and Koha separate works without damning Koha to rampant exploitation. Though if you took away MySQL Koha would not function, Koha runs in a separate process from MySQL and interacts with it via standard protocols (i.e. Perl's DBI and Unix sockets or TCP/IP). However, if someone were to heavily modify Koha to give it a nonstandard interface allowing it to access all of Koha's internals, and then create a "separate" proprietary application that interacted with this interface, they would run afoul of FSF's interpretation that "communication of the [proprietary] component with a [] GPL'ed component via a rich, non-standard IPC or network interface that gives all the same functionality normally given by static or dynamic linking." Moreover, I think an effort to circumvent the license in this way would evince clear bad faith and would be unlikely to sway a judge. [1] See http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins [2] C.f. http://www.fsf.org/licensing/compliancelab.html

3. EXTENT OF CORRESPONDING SOURCE.

When you had to depart yesterday we were in the midst of discussing obligations under the license in terms of what constitutes the 'Corresponding Source' for the obligation to provide the 'Corresponding Source'.

Are the unmodified Perl modules and their dependencies which are distributed independently from Koha part of Koha, when considered as a work as a whole?

Considering AGPLv3 specifically, I think you avoid this issue because no non-source form of Koha is ever conveyed. If Koha could be compiled into binary form, then the source for the Perl modules, etc., would be a required component of the Corresponding Source. However, since Koha is only ever *conveyed* in source form, they are clearly not a part of the Corresponding Source: "The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities." [snip] "The Corresponding Source for a work in source code form is that same work." The result is the same under GPLv2 -- the complete corresponding source is only defined to include third-party libraries, etc., when the work is distributed in object code form. -- 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 ---------------------------- Original Message ---------------------------- Subject: Re: Questions about upgrading Koha to AGPL 3 or GPL 3 From: "Thomas Dukleth" <koha AT agogme.com> Date: Thu, May 27, 2010 14:48 To: "Aaron Williamson" <aaronw AT softwarefreedom.org> -------------------------------------------------------------------------- Aaron, I had read the paper about maintaining permissively licensed code within GPL works previously after hearing it discussed in a SFLC oggcast. Thank you for the link. 1. HOW DERIVATIVE WORKS APPLY TO SOFTWARE. Throughout my thinking about how copyright law applies to software I have taken a software dependency to generally imply a derivative work relationship to that dependency. Please explain where I may be mistaken. 1.1. DERIVATIVE WORK RELATIONSHIPS. Functional calls to a program invoke a derivative work relationship to the called program as a dependency of the calling program. The test which I have used is whether the work as a whole would function if one would remove a particular dependency. The relationship is then analogous to the analysis one might give a book where some new wholly original material is contained within book which also includes a collection of other works organised in some useful manner. Permission is need to include the other works in the book and the book would not have the same meaning intended in organising the various parts if a section would be omitted. Given the rigid linear manner in which program control is generally coded, omitting a dependency would usually be liable to cause the entire program to fail. 1.2. MERE DATA LINKING. Functional calls are very different from mere data linking. An HTML hyperlink or other simple data link is an example of a mere data link which does not necessarily establish a functional dependency on the linked content by the program from which the link is being made. If the data resource to which a link is being made is unavailable, the program would probably continue to function and the user would merely not have the data from the particular resource. The analogous case for books is that of a bibliographic listing. Books may have HTML hyperlinks for bibliographic links if the book is presented in electronic format. However, both the paper version with no hyperlink and the electronic version with a hyperlink have the same functional integrity. The book containing the bibliographic listing would continue to function correctly whether or not a work listed in the bibliography would be available to the reader. There is no functional dependency which would necessarily cause program failure if a data link would be omitted. 1.3. FSF INTERPRETATION. As far as I have understood, such an interpretation of how the derivative works concept in copyright law applies to software is the interpretation which FSF has always advocated and the correct interpretation. The precise application of the principle for the obligation to provide Corresponding Source may not always be clear when the user suffers no harm. The user has little incentive to complain when the user can easily obtain the Corresponding Source for unmodified dependencies of a program independently from the conveyance of the source code for base program which the user is using and which depends upon those independently available dependencies. 2. QUESTION ABOUT MYSQL. Please ask Eben Moglen or whomever may be well informed about the history of the matter whether an express dependency on another program such as MySQL, which is not modified directly, necessarily establishes a derivative work relationship to that other program as MySQL AB had claimed repeatedly. Koha is not a modification of MySQL directly, however, every program which uses some MySQL specific SQL not generalised in a database independent manner may be thought of as extending the functionality of MySQL. Remember that the general principle is that we want the license to work for everyone and not have someone add an API or different user interface at some programming layer apart from Koha and not follow the license for Koha if relying upon Koha exclusively for some functionality. This question is not merely an issue about what is reasonable between different free software communities when everyone has some common understanding of the spirit of the license and mistakes over details have no effective consequence. This is an issue where there are companies which are less well behaved than any company in the business of serving libraries with books and other information media would ever behave. I expect that Koha will at some future time include code which may be considered useful outside the domain of libraries. We will want the license to be respected for the benefit of the users in every activity to which the code may be applied. 3. EXTENT OF CORRESPONDING SOURCE. When you had to depart yesterday we were in the midst of discussing obligations under the license in terms of what constitutes the 'Corresponding Source' for the obligation to provide the 'Corresponding Source'. Are the unmodified Perl modules and their dependencies which are distributed independently from Koha part of Koha, when considered as a work as a whole? [The specific issue of MySQL is raised in the section above.] While the widest interpretation of the work as whole may impose some burden of compliance, there may be a safety of assurance of compliance in a wide interpretation. Yet, we do not want any mere interpretation with some margin for error, we want to know what is correct. We want to respect the license and have others respect the license in the same manner. Some Perl module Koha dependencies are Perl hooks for C programs which used in object form for which we would need to supply the source code. Some Perl modules are express dependencies which are much more significant than the case of MySQL dependency because there are no alternatives to some Perl modules. Such Perl modules have no alternatives comparable to Postgres as a possible alternative to MySQL. I refer to the text of what I had given as question 5 repeated below. "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. The Koha community needs 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.]" Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783

Thomas Dukleth wrote:

Each of us had to correct an earlier mistake in our analysis to see the issue clearly. As I have stated previously, the difficulty is not that AGPL 3 is new and untested as MJ Ray argues.

That's not what I argue.

The difficulty had been that AGPL 3 is sufficiently new that SFLC has lacked the familiarity of experience to already have well thought out answers to some questions about applying AGPL 3.

This ^^ is exactly what I argue. Even the expert lawyers that usually support our community haven't mapped all fairly obvious concerns yet.

1.2.1. SPECIFIC APPLICATION TO KOHA. [...] We should include Net::Z3950::ZOOM and the source code for Yaz for which ZOOM is merely a wrapper. [...] We should include DBI and the dependency which we currently require DBD::mysql. [...]

This makes the download size/cost problem a little bigger, as well as adding an element of repository management.

2.1. EQUIVALENT ACCESS TO PROGRAM AND CORRESPONDING SOURCE.

As the use is in object code form for a remote network user under AGPL 3, the "equivalent access" provision of section 6 (d) would apply. Limiting the bandwidth for accessing the source code to a greater degree than the limitation of the bandwidth of the program use for countries where network connectivity is poor and extraordinarily expensive would not be allowed. This change corrects the answer given for limiting bandwidth as a remedy to AGPL 3 objections given in section 3.1.1.3 of an earlier message of mine in this thread at http://lists.katipo.co.nz/pipermail/koha/2010-July/024391.html .

So I hope everyone reads this and understands the implication: if your source code download is being hammered, limiting its bandwidth means you should limit the bandwidth to your catalogue service too! A corner case question is whether putting the source code as a Disallow in the robots.txt http://robotstxt.org/ means you should list the whole Koha as Disallow. I know some libraries (those with rare books, for sure) like to have catalogue pages listed on search engines to help encourage membership.

A provider of free source code hosting services with ample bandwidth, such as http://www.gitorious.org/ and http://github.com/ , would be one option for hosting the Corresponding Source. Contracting Corresponding Source hosting services with a Koha support company would be another option. [...]

I remember that I have an outstanding question about availability linking and external hosting, but this raises another one: does this combine with the previous paragraph to mean that if your chosen cost-free source code hosting service denies bandwidth to someone, then your catalogue service should also deny them bandwidth? So, do any of the cost-free source code hosting services publish their block lists? I didn't find one. Regards, -- MJ Ray (slef) Webmaster and developer for hire at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op

On Tue, May 11, 2010 at 10:21 AM, Matthew Butch <matt@pennmanor.net> wrote:

On May 9, 2010, at 5:18 PM, Christopher Nighswonger wrote:

...

As I see it, the advantage and rational for moving to GPLv3 are primarily that GPLv3 is compatible with AGPLv3. This allows us to accept work licensed under either of these two licenses.

I don't know if that is true. From what I understand you can't mix GPLv3 and AGPLv3 code. You can link to libraries that are compiled with GPLv3 in AGPLv3 (or vice versa), but the code can't be mixed in the same code base. And AGPLv3 does not allow linked of GPLv2 libraries.

Combining is specifically permitted. Paragraph 13 of AGPLv3 clearly states (emphasis mine): "Notwithstanding any other provision of this License, you have permission to link **or combine** any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License." http://www.gnu.org/licenses/agpl-3.0.html Kind Regards, Chris