[Koha] AGPL 3 objections and replies

[Thomas Dukleth]

[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