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

[MJ Ray]

Thomas Dukleth wrote:
> On Mon, July 5, 2010 14:45, MJ Ray wrote:
> >> 3.1.  COMPLIANCE BURDEN. [...]
> > 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.

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).

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.

> > [...]
> >> 3.1.1.3.  LIMITING BANDWIDTH REMEDY. [...]
> 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.

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?

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

> [...]  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!

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

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

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

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.  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).

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

> >> 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"?

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

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

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

Hope that explains,
-- 
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