[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