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