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

[Thomas Dukleth]

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