GPLv3

Comment 3553: Test comment

This preamble is revised.

Comment 3554: Modification should not be a requirement to release source

I would like to use the AGPL as the license for my C++ class library; however, the problem with clause 13 as currently written is that it only applies if you "modify the program."

If I've done my job well, you shouldn't need to modify my library at all in order to develop network applications with it. It is a toolkit for developing applications of all kinds, with an emphasis on networking (it includes an implementation of SSL/TLS among many other things).

I would really hate to have to create my own open source license, when the AGPL could be modified to also cover libraries like mine. I would suggest language along the lines of, "if you incorporate the covered work into an application accessible over a computer network...."

Mike

Note that modify is a defined term in the license (to quote):

To "modify" a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a "modified version" of the earlier work or a work "based on" the earlier work.

The activity you describe -- incorporating your library into a larger whole -- would almost certainly require "copy[ing] from .. the work in a a fashion requiring copyright permission". Therefore, I think that this clause *would* cover your proposed scenario without modification.

Theoretical:

Alexis has a tarball of an AGPLed app, she installs it on her local machine and uses a local webbrowser to access the app on 127.0.0.1 on a local-only httpd, she then hacks on the code for a while fixing bugs adding features, and since nobody can access the code via a network she removes the download link since she thinks it clutters up the interface. This seems legit under AGPL3d2.

Bob sees Alexis on this app and asks for a copy. Alexis conveys the new tarball in the vanilla way using the GPL3 provisions of AGPL3. This also seems legit under AGPL3d2.

Bob takes his tarball and untars it on a public server and makes no changes to it (unmodified version). This also seems legit under AGPL3d2.

So bob is running an app derived from AGPL code as SaaS and has no link to the tarball of the code, but everybody has still complied with AGPL3d2.

Am I wrong? Can this be fixed?

I think you probably are wrong. Alexis' version still *supports* interaction over a computer network (even though she isn't taking advantage of it), therefore she can't remove the feature and distribute the resulting version without violating Section 13.

If she *were* to remove the ability for the thing to work over anything but 127.*, then Bob would have to readd things to make it work on the public network, and he's then bound by Section 13 when he modifies.

Certainly in the FSF's opinion, the AGPL would apply, and this may be sufficient if all you want is a "polite request to share the source" (note that this section really doesn't offer any guarantees of source distribution anyway since it only applies to the program, not the vendor of SaaS itself). IANAL, btw.

My own feeling is that you would do extremely well to contact a non-FSF-related lawyer. What you really want is to know whether someone could create a proprietary application using your library and prevail in a claim that it is not a derivative work. The FSF will not give you a good opinion here-- you need someone outside the Free Software movement (my lay opinion based on following SCO and other cases is that linking itself does not necesarily create a derivative work, and therefore might be allowed without any further permission necessary).

Again, IANAL. I have only read a few papers from the law community on the subject of derivative works and software, and the only thing I can tell you is that they do not appear to be inline with the licensing FAQ. Hence my advice is to get a non-partial attourney who knows this area of law and get some solid advice.

Comment 3555: No way to disentangle GPL from AGPL.

The discussion starter mentions: "If developers of some programs (such as IMAP and HTTP servers) prefer not to have these requirements apply, they should simply use the ordinary GNU GPL."

It's not clear how an author can publish his software under the GNU GPL v3 and ensure that he will only receive patches under the GNU GPL v3 or more permissive licenses. This seems to say that others can write patches and new components under the GNU AGPL. If I'm not interested in using such components, and want a true copyleft---a guarantee that I can use and modify and modifications to the software I write---how can I achieve this with these cross-licensing paragraphs?

This the sort of mess that happens when a last minute change is made to the GPLv3 without any public review.

Isolating the codebases by permitting only linkage between GPL & AGPL was a good idea, and then right at the last minute someone introduced a kludge to effectively permit relicensing of GPL code as AGPL code.

It's a symptom of the struggle between compulsory reciprocation and rights restoration. You can't have a licence that achieves both.

You can restore liberty in both cases, but the right that people are overlooking is privacy.

Either you violate privacy to compel reciprocation, or you restore the licensee's right to privacy (otherwise violated by copyright/patent - exploited in small degree by the GPL, and larger degree by the AGPL).

The FSF have got to decide whether they believe in privacy or not. If not, then the AGPL is what they should have moved the GPL to. If they do believe in privacy, then GPLv3 should have started migrating to restore privacy further, e.g. permitting distribution of binary derivatives without source (possibly on condition they were without charge and possibly on condition the source had not yet been published).

I don't see how this cross licenses anything. If I have an AGPL app which uses a GPL app or library I am required to distribute the GPL work through the AGPL work. the GPL code is still GPL, but the GPL is activated by the fact that I am required by AGPL to convey the GPLed code if it is linked to/required for the AGPLed work.

If I gain access to some GPLed work which would have otherwise not been conveyed, then great, it's still GPL. I can dissasociate it from the AGPLed work and use it under GPL. AGPL only places the additional restriction on those who choose to use AGPLed code, it does not make GPLed code AGPLed if it is linked to something using AGPL. A GPLed work is not required to convey itself or any other work, excepting in the case that it provides the interface for an AGPLed work over a network.

re: crosbie

Allowing binary distribution without requiring code is the opposite of the FSF's objective, calling closed distribution "privacy" changes nothing. I think the FSF in general agrees that GPL3 should have been what AGPL3 is going to be, but since having currently GPLed work up-convert to a license which a large subset of the community objected to was going to create a nightmare for adoption, it was moved out to this explicitly compatable license. Some of us who liked this prevision in the early GPL3 drafts are waiting for AGPL3 so that we can license our code under it instead of GPL3.

The level of adoption of each will determine by democratic meritocracy which ideal is more in line with the current mindset of the coding community. Everything I release will be AGPL unless I'm using someone else's code which is not A/GPL3 compatible (not likely, but possible).

Certainly this problem existed in drafts of the GPL v3 prior to draft 3. Fortunately somebody realized how much of a mess this would create and replaced it with a linking exception.

Therefore I would argue that this problem has been addressed in the sense that the licenses now just give permission to combine portions into larger works, but do not permit restricting rights beyond those which the copyright author already authorized.

Crosbie: I think the problem is not "privacy" but rather that compulsion and freedom are invariably opposite. Therefore copyleft and software freedom are often in conflict. My own view is that the FSF has taken a road that leads to a sort of "war on terror" approach to sacrificing essential Freedom in the name of extending copyleft as evidenced by the reason for the GFDL invarient sections clauses (forced advocacy in technical documentation), and the endorsement of the restrictions of this license. But this is just my own view.

Also I would point out that as much as I do not like this license, there are ones which are worse from the perspective of this balance. The OSL for example compels distribution of the software to any individual outside one's organization to whom you offer the use of the software over a network. THis is not a program modification but a use requirement. I suppose therefore that it is helpful for the FSF to help give people a reason not to conflate network use with distribution.

Einhverf, the 'compulsion' is caused by copyright's suspension of the public's liberty to published works. We can remove that compulsion at a stroke simply by abolishing copyright. We are then left with the public's liberty unstrained.

What the GPL achieves in very large part is to use copyright to compel nullification of its restrictions against the public, i.e. it requires that the liberties otherwise suspended must be restored for each work AND derivatives.

Compulsion in the GPL in this respect isn't counter to liberty, but in support of it.

Where the GPL dips a toe into the realms of unethical compulsion is its well intentioned obligation for publishers of derivatives to provide source code.

However, it needs to be recognised that source code is only kept secret because copyright renders its sale and consequent disclosure unnecessary. Why sell the source, if you can get rich on binaries?

In the presence of copyright, and with the entrenched mindset it has spawned that persuades people to keep source secret, it is forgivable to resort to copyright to compel disclosure where persuasion would otherwise have little traction.

Unfortunately, in believing the GPL is good, 100% good, people start believing that it is also ethical in every respect, and that compulsory disclosure is also ethical.

I am looking forward to the abolition of copyright. However, I am trying to point out that in the absence of copyright, compulsory disclosure is neither necessary nor ethical. To some extent this should inform the evolution of the GPL, but I fear the GPL will become ever more attracted to the power of copyright in violating privacy in pursuit of source visibility instead of restoring privacy along with liberty.

The lack of source code visibility is an economic byproduct of copyright, it is not a consequence of people enjoying their natural right to privacy.

Comment 3556: Interaction by proxy

It's not clear whether a CGI script or a procmail recipe supports such interaction. They don't manipulate network sockets, after all. Should I include the corresponding source for my httpd? cgi script? Interpreter for the CGI script? Libraries used by that interpreter? Shell? Kernel? Certainly the kernel supports interaction over the network.

In my view, Procmail is an interesting case. If you send automatic replies is that interacting with a user over a network? WHat if you use it as a mailing list? How much interaction is required for clause 13 to take effect?

A CGI script is a clearer case only on the surface because usually the CGI script and the user are separated by a network connection. But what about the defintion of "interact?" For example, suppose I look at an AGPL'd light-weight CMS. Seems safe to say that is covered. Suppose I now write a simple CGI script which takes out data from the db (or filesystem, or whatever) in a fairly non-interactive way (only "interactive" components are hyperlinks, etc. Users don't do anything other than read the content), and delivers it to the public. Does this trigger clause 13? I think not, but I do not know for certain. IANAL, etc.

Comment 3558: Sec. 13 rendered inoperable?

Here, the text says I can do pretty much as I please so long as I have a license and I do not convey the work.

In the definitions, it says mere interaction with users over networks is not conveying the work.

How, then, can the extra AGPL clause come into effect? The basic permissions seem to override it.

/ How, then, can the extra AGPL clause come into effect? The basic permissions seem to override it. /

I guess that's supposed to be because Section 13 starts with the word "Notwithstanding", so retracts this statement about an absence of conditions. It's all a bit silly, IMHO. The Section 13 condition to provide source surely should be here in Section 2, where it says there are no conditions.

Comment 3559: Why repeat the whole GPL?

Why not just use the LGPLv3 formula, saying "This version of the GNU Affero General Public License incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional restrictions listed below" (as opposed to "additional permissions" in the LGPL)?

Shorter, sweeter, clearer, no searching it to find out just where the differences are.

While LGPL just grants additional permissions, the AGPL has to put an additional requirement in place. The permission-exception model of GPLv3 (which is excellent, in my view, but that's beside the point) isn't designed to make it easy to add additional requirements (for obvious reasons). Therefore, if you have a legitimate reason to draft a more restrictive license (and I think we all agree the AGPL qualifies as such) the only way to do it is to do a good amount of cut and paste.

Comment 3560: "remotely through a computer network" should be changed ? (loophole)

I'll start with a simple example, just imagine an application running (covered by the AGPL) in an Airport via a touch-screen interface. The user is interacting with the system but without using the network (the users is not interacting with his own PC on the network) ? It wouldn't better to broad it to any kind of interaction ? To avoid companies to put "network-to-something" proxy.

I would replace the "remotely through a computer network" by something like "through any means".

I agree that "computer network" is perhaps too specific (is a cellphone network a computer network)? However I think it should only apply if I'm accessing the server from my own hardware. If I'm using a kiosk, then the server isn't interacting with my property, so I'm not so concerned about how it works.

This was thought about a great deal in the drafting of both this license and the original AGPLv1. I don't think anyone really felt that airport kiosks and ATMs should have to give source. The goal here was to address the world of AJAX and Web 2.0, not those kinds of applications.

The "accessing with your own hardware" is an excellent suggestion, but it may be too late in the process to try and put it in, because the amount of legal thought required to make that kind of change in a last call draft might be too great.

I think the "computer network" thing addresses the core problem, which is the web, and I actually think it may do well in the mobile phone network space too (although it might be dicey). I think we've got what we need for this version, but this is a good issue to put on the slate for AGPLv4. :)

There is an interesting point about network to something proxies. Heck network to network proxies pose interesting challenges.

Suppose you create an AGPL application. I create a derivative work of that AGPL application which has the option to be configured as a proxy for the web service request only. I leave the AGPL code download interface unchanged. Cool, you can get my proxy code.

Now, I install a differently modified version behind that proxy and configure it to pass the requests back. When you request hte source of the application you are directly interacting with, you get the code of the proxy, *not* the modified code of the real service. Does the AGPL prevent this, and if so how?

Interestingly, the problem with network-network proxies is not only possible under this license but pretty much guaranteed by it. I.e. proxying the source request may well be a violation of this section.

if this is really so important, I wonder if a non-Free license like Larry Rosen's OSL would be more appropriate.

I think the proxy issue is a bit off-topic for this comment. It's being discussed extensively on other comment threads.

Meanwhile, you are right that contract license could do more. One of the design goals of AGPL was to make sure it stayed a copyright license and not a contract.

Comment 3561: Let's protect folks from ACTUAL theft...

I think we should protect people from things like hardware theft and folks illegally obtaining the work by breaking security and downloading the work even if it was custom software only being used internally. This language looks like it guarantees actual thieves to have a license, even if they obtained it illegally (e.g. by actually stealing the media or illegally accessing the media that it was stored on).

/ This language looks like it guarantees actual thieves to have a license /

Note that this condition is on Section 5. Conveying Modified Source Versions, which starts "You may convey a work based on the Program", so if you don't actually convey a derived work (e.g. if you only use it internally), then this condition doesn't apply.

If you do convey a derived work, then you are already required to have made the source available. In this situation, you would be required to allow the theif a license, but they were already entitled to a license anyway, and you don't have to provide the source, and you can still sue them for the actual hardware theft.

FWIW, this isn't really an AGPL-specific issue; it's really a straight GPLv3 question. In fact, this very conversation was one had at length on GPLv3 Committee A before the release of GPLv3, and the general consensus was that it wasn't an issue, for reasons that jamesgnz points to, and others. See the Committee A legislative history for details.

Comment 3563: Phrasing could lead people to incorrectly ONLY send GPLv3-licensed code.

The "corresponding source" should be for the ENTIRE program, REGARDLESS of the code's original license. An evil developer could include MIT-licensed code that happens to be no longer accessible to anyone. It should be the ENTIRE program. Change the sentence to something like: "This Corresponding Source shall include the Corresponding Source for any work that is incorporated pursuant to the following paragraph, even if it is also covered by other licenses such as the version 3 of the GNU General Public License ." That way, you can download the ENTIRE program.

--- David A. Wheeler

Comment 3564: Loophole that defeats the intent of AGPL

Let's say I modify a web application that is under AGPLv3. I add a link on the main page that points to source.tar.gz on the same server that runs the Program. However, I don't want to give out the source in reality, and try to work around the AGPLv3's requirements by installing a HTTP proxy server. The proxy passes all HTTP traffic except files with suffix .tar.gz.

What part in AGPLv3 prevents me from doing this? The modified Program itself is making it possible to get the Corresponding Source, so I clearly have fulfilled the requirements of the AGPLv3. The proxy server is very clearly completely independent from the web application; the proxy is not a derived work of the web application, thus AGPL on the web application cannot affect the proxy server. It's more like that the proxy makes the network connection a bit flaky, but it would be ridiculous if *running* AGPL'd program behind a broken network connection would be a copyright violation.

If this kind of tricks are allowed, AGPLv3 is practically almost the same thing as GPLv3: there's no need to convey the source unless you convey binaries. Why is AGPLv3 being made if it cannot achieve its intended goal? Preventing users from getting the Corresponding Source seems to be so easy, that everyone who is even remotely interested in doing it, will do it.

IANAL, but I cannot see a way to make AGPL work as a copyright license. This seems to need an EULA-like approach (contract).

IANAL either, but:

I think that the EULA/Copyright question in this context is a red herring. Section 13 of AGPL is triggered upon modification, something that is clearly governed by copyright law.

The relevant question you are asking is, once those terms are triggered, are they strong enough to cover all the bases for protecting the web-users' freedoms? A legitimate and important question, but I don't think your example shows a loophole.

If you are the operator of both the proxy server and the web server providing the application, it would be clear that the network service you are providing includes both. You are clearly attempting to get out of your obligations under Section 13 on purpose. The fact that you use a piece of proprietary software in between your main server and the user is actually a red herring too. (It's kinda like, in a GPLv2 case, saying that the CD pressing facility that does source is different than the one that does binary, and it's not your fault if the source code CD's aren't readable in most CD drives but the binary CDs are.)

I don't think you'd have much of a leg to stand on, and I think the enforcement action would be successful, since you modified the work and then tried to get out of your obligations placed on you when you modify. You'll have to argue that you did provide an opportunity for your users to get the source, and oops, some proxy server was in the way and stopped it and that was out of your control. Then, the next question is "who is running the proxy server, and on whose behalf?" If it's clear that you arranged to have the proxy server in the way, then it quickly becomes clear you tried to avoid having to give the source.

I can imagine malicious violators trying to play tricks with this by getting third parties set up at an arm's length to do the job. But, the facts would bear out that the violator was trying to pull a fast one, and are they really going to hold out for the copyright holder to sue, and make the "aw, shucks, I dunno where that proxy server came from" argument to a judge?

I have spent half my career doing copyleft enforcement. I just don't see things turning out this way. I think the language as it stands get the job done.

Thanks for your reply, bkuhn. I'm happy if I'm wrong. :-)

Unfortunately, I think your comparison to defective source CDs doesn't apply to my example. If the source CDs are bad, I'm violating the GPL unless I provide replacement discs. Similarly, if I distribute binaries on a public server, but put the source code behind a broken network connection, I'm violating the GPL (at least if I don't fix the connection as soon as the problem is noticed). These are easy cases, because the GPL requires *me* to make the Corresponding Source available in one of the ways described in the GPL.

AGPLv3-draft2 requires that the modified *Program* must make the Corresponding Source available. There are no obligations for the author of the modifications nor the user running the Program on the server to make the source available (unless they convey the Program, of course). One can test the Program on a test server, and see that it really makes the source available, and thus fulfills the requirements of the AGPL Section 13.

This gets more troublesome if the modifications are done by a third party. In that case, I'm only running a Program, which I haven't modified or conveyed. Thus, I'm not bound by the AGPL. Installing the Program behind a broken network connection is not modification, and doesn't trigger AGPL. If AGPL required that the Program must be run only behind a working network connection, that would be a condition on use, and make the license non-free.

I think that to make the AGPL effective, it should require that if I run the Program (modified or not) on a server, *I* must make the Corresponding Source available to the remote users of the Program (that is, in contrast to requiring the Program itself to do that). To my understanding, this cannot be done with a copyright license. Also, such a requirement would be a condition on use, which would make the license non-free.

I don't disagree that there is a slight difference between the two cases under discussion. AGPL, as you point out, does go only as far as it can with a copyright license.

I'm taking this from an enforcement point of view. The intent of the license is clear -- that users who use a program over a network are provided with the source, and modifiers have an obligation to arrange the program in a way such that its source is provided.

With any copyleft ever invented, there are ways to scam the system that technically might be permitted with a certain reading of the text. Then, it comes to an enforcement question and whether or not someone engaged in bad behavior wants to fight hard that his legal theory is stronger than the copyright holders'.

I just frankly think it won't happen. I believe that people who don't want to share their network applications will just avoid the AGPL and code licensed under it for fear it could get them into hot water if they fail to share. I think those that use it will provide the source in traditional ways as well as through the program itself. The mechanism is strong enough, in my view, that it will have this social impact.

We (as a community) have long known that most copylefts could be made theoretically "stronger" (at least in some jurisdictions) by turning them into contracts or otherwise pounding or other tenants of freedom (such as the freedom to run the program for any purpose whatsoever). As you correctly point out, many of these techniques would push us into a "non-free" license, or otherwise act in ways that most of the Software Freedom community would see as antisocial, or at least unfriendly.

I think this AGPL draft does a pretty good job going right to the line of what it can get done in a copyright license while creating a very clear intent of the licensor that users get source, and requiring those who wish to circumvent the spirit of the license to jump through amazingly difficult hoops that might even be impossible in practice.

I agree that the intent is clear, but the actual license text is weaker than the intent. The intent was also clear with GPLv2's patent clause, but GPLv3 still ended up having stronger patent clauses. To me it seems, that lawyers to look at the exact wording of the license, not its spirit. (And if modifications to an AGPL'd software are made by a third party, the lawyers don't need to even look at the license, since merely running the Program doesn't require acceptance of the license.)

While I'm not a proponent of AGPL-style license, I think that those who want it, deserve it to be good. Let's hope that you are right, and people don't dare to do tricks I suggested in my earlier posts.

Can the license be changed such that anybody who conveys the work can only do so if the code is offered by the interface? This would not seem to be a freedom 0 issue as in-house use does not involve conveying the work.

This would result in only those who modify the code having a copy which would not offer code, and would therefor be bound by the modify wording in section 13 to re-include it if the interface was accesable through a network.

If I get such a work and take out the code reference I have modified the work and can be re-bound by the section 13 requirement to put it back before making it network accessible or conveying it.

is this hack legally workable re:copyright?

I'm not sure if I understand your question correctly. A copyright license may require that if you convey the Program, the Program must include an interface providing its source (would be an inconvenient requirement though). But you cannot require that such an interface gets added to the Program when someone just wants to run it without modifications.

larhzu's patent clause thing regarding GPLv2 and GPLv3 is not really relevant, I don't think. To my knowledge, GPLv2's patent clause don't have a known bug; v2's Section 7 does a very good job with its implicit patent license grant. The problem was that v2's Section 7 was confusing to some on what patent rights had to be granted. v3 makes the patent grants "more clear", but may or may not make the patent clauses "stronger" in the sense that they require more of the patent holder.

Comment 3565: Unclear when this applies

The text is unclear to me. This is clearer to me:

The terms of this license will continue to apply to the part of the combined work that is the covered work. The terms of GPLv3 will continue to apply to the part of the combined work that is the GPLv3 covered work.

Comment 3566: Does this actually have teeth?

I see two possible readings of this section both seem to be problematic. In the first reading, one must offer the source through the application, but are perfectly in your rights to use other technologies such as network filtering software to prevent such requests. Thus one can provide access in the covered work but not actually provide access to users. For example, a web server could be configured separately to give 403 errors in relation to requests for source code. In this reading, the AGPL makes life harder for developers but offers no guarantees to users since technological means can always be used to prevent the dissemination of source in accordance with the license (i.e. not effectively different than GPL v3 except in requiring additional interface components).

The second and more dangerous interpretation would be that such technological means would essentially be a violation of the agreement by which one is allowed to prepare derivative works. In this reading, the software violates Freedom 0 not only relating to its own use but relating to other software on the network, for example, by specifically banning certain configurations of other network devices such as proxy servers.

Furthermore it is unclear where the line is. If I write C-language stored procedures in PostgreSQL under this code, it would seem to require that an interface is permitted which allows anyone to download the code from within the db, yet there is no guarantee that these will be kept up to date.

I think this license is one of the worst ideas out there from the FSF to tell you the truth. It is either non-free or ineffectual, and it is burdensome for people to comply with.

Just to say this: My opinion is that the license is either ineffectual or simply non-Free by any reasonable standards of the 4 basic freedoms. I suppose it is too late not to have the FSF publish it but maybe they can list it as a non-Free license?

Any license which places restrictions on your *use* of the software is inimical to the definition of Free Software. If the AGPL prohibits you from interfering with dissemination fo source it does this, not only of the software delivered but of potentially other network components as well.

If the AGPL does not do this, it lacks teeth, gives developers headaches, and gives users nothing more than the GPL. Obviously the intent is to restrict *use* of the software (freedom 0) as a part of a copyright license and therefore I have come to doubt the FSF's continuing commitment to software Freedom. Shame on those who promote this.

To me, AGPLv3-draft2 seems to be a free license (in contrast to AGPLv1 and GNU FDL, which I consider non-free licenses). AGPL is a copyright license (not a contract), thus it cannot restrict usage of the software as long as you don't modify or convey it. I agree this makes AGPL weak, but maybe it isn't a serious issue in practice. See the discussion in this thread:

http://gplv3.fsf.org/comments/rt/readsay.html?filename=gplv3-draft-4&id=3564

I think the second is the only reasonable reading. The licensee is required to make the code available. How they chose to comply with the license is their business, if they chose not to comply they have no license to use the code, just like GPL.

The license is not burdensome because the cost of providing the option to ftp or http access to a file to those who already have access to run the program over the network is functionally $0. It could be put out as a torrent and seeded at a reasonable rate, the bandwidth/cpu would drop to almost nothing.

Freedom 0 is maintained just as it is under GPL, certain uses have certain requirements, just as you can not convey GPLed code without meeting GPL requirements. You can still use it to run nuclear power plants, military bases or catholic churches, the AGPL will not stop you. You can also run the code locally at 127.0.0.1 and not distribute it at all under both A/GPL.

If the intent was that the licensee must make the code available, the AGPL should say so: "If you modify the Program and let users interact with it through a computer network, you must make the Corresponding Source available to these users." This would leave no possibility to block access to the source with a firewall/proxy, because the *licensee* is required to make the source available, not the modified *Program*. The problem with this is that one could request a third party to make the modifications: if the third party would not run the Program on a publically accessible server, and you wouldn't make any modifications to the Program, no one would be required to give the Corresponding Source to the remote users.

AGPLv3-draft2 tries solve the above problem by requiring that all modified versions of the Program offer the source. But it still doesn't guarantee that the remote users would have a chance to get the source in case the modifications were done by a third party. You don't become a licensee until you do something that requires a license. Merely running the Program doesn't require a license in most jurisdictions, thus if you don't modify or convey the Program, you can safely ignore the whole AGPL. Installing the Program behind a firewall/proxy isn't modification of the Program.

If unlicensed possession of copyright material is not a copyright violation in most jurisdictions then it would seem to follow that AGPL can not make any significant impact on code distribution as long as it is a copyright license.

If conveyance and modification, are the only binding actions it seems to be needful to require both those who modify and convey to guarantee that all network-able interfaces offer the code(if your version supports such interaction), but this can not solve the problem of a not thus bound individual from accessing the interface with closed code and re-interfacing it with a network, thereby obscuring the offer.

A copyright license can require that all modifications are, for example, published on a public website or sent to the original author. While this would give the license more teeth, it would restrict the freedom to modify and run modified versions privately. I suppose (and hope) that the FSF doesn't want to remove this freedom.

I wonder if it were possible to see "running the Program on a publically accessible server" as public performance. If it were possible, the license could require that anyone "performing the Program publically" must make the Corresponding Source available to the audience. This idea sounds so obvious, that I'm quite sure that it has already been ruled out.

Thanks, Larhzo, that makes me feel a little better.

One other point-- the AGPL seems like it is a lot easier to accidently violate (for example modifying the source of an AGPL C program, compiling and running it for the public but neglecting to change the target sources of the source download interface) than the GPL v3. This seems to have the effect of potentially causing someone to forfeit usage rights to the software if patents are involved. So patents are now a Good Thing(tm)?

Comment 3567: Bad wording?

IANAL but this caused a parser warning.

Do you mean:

The above provisions not withstanding...?

Otherwise it seems to suggest that section 13 does not withstand other sections of the license (in other words may not ever come into effect given the basic grant of rights under section 2.

I parse the current text as: If you modify a program.... This provision does not withstand any other provision in this license.

Comment 3568: Not sure this is always possible

I am wondering about how a UDP-only DNS server (think of something like dbjdns) could accomodate these terms? I don't think TXT fields would work very well..,

Actually, my reading of the AGPL would require one to send the source code for the application back over the UDP DNS response, such as providing a default zone with a TXT record consisting of the Base 64 representation of the tarball of the corresponding source. Just because the interface exists and would theoretically function over a network, provided that routers could handle such UDP packets (no standards are broken) doesn't mean that this would actually get to the user in practice though. Especially if anyone's routers are set to refuse IP fragments....

AGPLv3-draft2 requires that the Corresponding Source is provided "through some standard or customary means of facilitating copying of software". DNS TXT records are don't fulfill this requirement.

A reasonable way would be replying with an IP address when someone queries "http.source.code" or "ftp.source.code". There should be a server behind that IP address, which would provide the source via HTTP or FTP. Unlike some early GPLv3 drafts that had the Affero clause, AGPLv3-draft2 doesn't mandate that the Corresponding Source is provided via the same network session that is used to access the application.

Comment 3569: not technologically neutral/future proof

BitTorrent distribution for example, would not have the source provided from 'a server' but from many.

Perhaps a better phrase would be 'through a network'.

Comment 3570: GPL-only?

I am unsure, but this seems to leave LGPLv3-licensed libraries uncovered by the distribution requirement.

Actually the LGPLv3 IS the GPLv3 + some special exceptions, like it says in the LGPLv3 it self: "This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below."

So any work licensed under the LGPLv3 is automatically licensed under the GPLv3 and hence falls under this provision. So I don't see that problem.

However X11, new BSD, Apache 2.0, etc licensed components of a combined GPLv3 + AGPLv3 is as others have pointed POTENTIALLY a problem.

Perhaps the following: "This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph."

Should be re-worded to something LIKE this(or something to that EFFECT): "This Corresponding Source shall include any and all parts of the source code of the work and any library that it uses regardless of which license(s) those part might be available under".

Or:

"This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph and any or all parts of that GPLv3 work that are available under other licenses pursuant to GPLv3 Section 7 and any and all parts of the Corresponding Source of this(AGPLv3) work available under other licenses pursuant to Section 7 of This License"

Another issue is Installation Information this Section doesn't address that at all, but I don't know if that is relevant.

Comment 3571: Technology specific

There are other means of interacting with a system remotely. For example, Interactive Voice Response (IVR) systems allow users to interact over the phone (assume in this case that 'prominently offering' involves 'please press nine to learn more about this system', and an eventual recitation of a URL).

Whether this kind of system is intended to be exempt from the distribution of modifications requirement or not, this is an ambiguous case:

If the intent IS to require provision of modifications in this case, the requirement is NOT triggered if the IVR system is being used over circuit-switched POTS (or anything else that is not a 'computer network'), which makes this a potential loophole.

OTOH, if the intent is NOT to require provision of modifications, and leg of the phone conversation happens over a computer network (ie. long-distance backbone, or the end user has VOIP service...) then the requirement is triggered erroneously.

I believe that the intent here IS to require distribution of modifications, so I would suggest eliminating this portion of the sentence, or changing it to 'through a communications network', or possibly just 'through a network' to eliminate the ambiguity.

Hmmm.... This poses a lot of problems. Since the license requires the source to be made available through the same session, unless you want th IVR to *read* the entire corresponding source to you over the telephone, I dont think this would be appliable to this interface. See my comments about UDP-only DNS servers and datagram size for other areas where the requirement may run you into problems (that is one big honkin TXT record being transferred over a 3MB UDP packet-- whill it get there? nobody knows...).

However, you do raise an interesting problem. Suppose I use an IVR app which is connected by a computer network to my PBX. Because I have a computer network between the application and the user is this interaction over a computer network? In fact does the PSTN count as a computer network itself?

Wouldn't it be better to say "directly interacts over a computer data network" so as to exclude questions like the IVR case? (Yes, a modem connection would qualify as a computer data networ, but a voice channel to an IVR would not.)

Comment 3572: Wrapper loophole as big as ASP loophole

This seems like it still has a wrapper loophole, where I can write GPL code (or even proprietary code) which accesses the AGPL code interface (perhaps through the network without touching/cohabitating with the AGPLed code) and re-interfaces it to the net, leaving the code offer obscured. How can we be sure if this is/not "combined" as referenced in section 13 of GPL? If I run the AGPLed code can I be required to include a code link on any public app interface which interacts in any way with an AGPLed app?

I can see the need to allow somebody to wrap an interface so as to access date, or other personal use which AGPL3d2 does not restrict, but to allow such a wrapper to provide SaaS seems like a semi-sized hole in the intent of the license.

I think this is being discussed in other comments; we might want to consider a merger of this with one of the others...

If you go and read the GPL v3, this would not be possible. This is because of the restrictions of the corresponding source and the interaction with the AGPL. But IANAL, and I can imagine that some circumstances might override that question.

If you want to know whether someone could do the same with a proxy, the concensus seems to be "yes."

If you want to know whether someone could do this with a GPL v2 wrapper, that may depend on the circumstances and you would do well to get advice from an intellectual property attourney from outside the Free Software movement.

IANAL, but I can see how things like web application proxies which modify HTML documents might get messy however (because the HTML output may constitute a copyrighted work). The best thing you can do is get an opinion from a non-partial attourney.

Comment 3573: AGPL and non-networked interactive applications

What exactly is considered interacting with the Program through a computer network? Nowadays, all interactive programs can made accessible through a computer network. One can use e.g. SSH, X11, or VNC. Does this mean, that if you modify *any* interactive AGPL'd Program, you must make it offer the Corresponding Source?

Furthermore:

Are the ESS-x systems computers? I believe they are (ESS5, etc). If so, then an IVR might be required to have an option to provide access to the COrresponding Source through the telephone connection....

Press 1 to go up one directory level. Press 2 to hear the contents of the ess-are-see directory (src) ....

beep

... Press 6 to hear the contents of the main dot see file.

beep

.... foreward slash asterisk. This work is copyright two thousand seven by the Society for Obnoxious Applications of the AGPL. Licensed asterisk forward slash end of line. Forward slash asterisk under the AGPL version three point oh or any later version at your option. This work comes with no asterisk forward slash end of line. Forward slash asterisk warranty either expressed or implied including the warranty of asterisk forward slash end of line. forward slash asterisk fitness for a particular use .... pound include double quote es tee dee I oh dot h double quote end of line.

.....

if parenthesis option underscore pressed equals equals tee dee em ef parenthesis nine close parenthesis open curly brace end of line. ....

THis could be quite fun...

Maybe fun, but wouldn't be allowed by AGPLv3-drat2, which requires that the Corresponding Source is provided "through some standard or customary means of facilitating copying of software". Speaking the source code doesn't fulfill this requirement. Speaking an URL from which the source can be downloaded should be OK. However, I agree that it isn't clear if interaction over regular phone is enough to trigger AGPL's requirements.

The point in my original question is, that it is illogical to differentiate between apps that themselves support remote interaction, and apps that can be used remotely via some additional tools (SSH, VNC). If only the first group would be required to provide the source, one could modify most AGPL'd applications so that they aren't accessible through a network without a separate independent tool (that is, a tool that couldn't be considered to be part of the original application).

For example, let's imagine that GNU Emacs were under AGPL, and I gave my friend access to my server over SSH. If I now modify Emacs, do I need to add an interface to provide the Corresponding Source, even though Emacs itself wouldn't support remote interaction?

We talked about the GNU Emacs example during drafting of AGPLv2. The answer is probably 'yes', but your remedy is trivial -- you can just make the source available in a directory on your machine.

Bkuhn, I don't think so.

The requirement is on the modified program, not the person offering use of that program. In your example, the modified version of Emacs offers no such interface. You would also have to modify EMACS to prominantly offer such an interface relating to a network server.

If it was on the *user* then it would be non-Free :-)

Comment 3574: Make it easier for average users to modify the Program

AGPL should require that the modified versions make the Corresponding Source available only if the unmodified version already has such a feature. This would make it easier for average users having no coding skills to e.g. fix typos from the Program. With the current wording, fixing a few typos could also require implementing a new feature, that would offer the Corresponding Source. This could need much more effort and skills than only fixing a few typos.

Comment 3578: Nice exception :-)

This means that the program must only offer an interface to download the corresponding source, not that the company offering the service must do so. This means that one could use the license to defeat itself.

For example, suppose I take your AGPL'd IMAP server and add code which allows the proxy of IMAP requests for anything other than the covered source to another IMAP server. This exception is arguably required since otherwise it defeats section 13. The effect is that you can download the source code of this new IMAP proxy.

Now I take the same AGPL'd IMAP server and make a number of enhancements. I set this up so that it is accessed via the proxy server. These modifications are then not publically available because the although the interface exists, it is intercepted *as required* by this license by a middleman.

The net effect of this is that the license ends up being self-defeating. I cannot proxy the source code request under section 13, and because of this, you cannot download the source code of my modifications.

Which raises a very interesting question: Why have this license at all?

This seems to be similar to other comments, which already have extensive discussion on them. It might be useful if you take a look at the comments that precede this one and see how your is different. It seems very similar to me as some of the discussions happening on other comment threads.

Comment 3582: Definition conflict?

This seems to be at odds with the definition of convey in section 0. Here, it states that mere interaction is not sufficient to be consider conveyance; here it seems that interacting is sufficient to trigger conveyance requirements.

Comment 3583: Bad: no clear definition of remote users

The term "user" is not clearly defined. If I get an "access denied" error page through a browser, am I a user of the web application? When I visit a portal, am I a user of the browser? Of the portal application, as well? Of the server-side scripting engine, perhaps? Of the web server? Of the kernel the web server runs on top of? Of the router OS? And so forth...

Where do we draw the line?

This ambiguity is really problematic, as it implies that there's no clear way to tell whether a modified version supports remote interaction, and hence there's no clear way to tell whether it is subject to the restriction specified by this section.

Comment 3584: Bad: use restriction, with a cost associated to it

This restriction compels whoever runs the modified version of the Program to accommodate the source code on the server or, alternatively, to set up and maintain a separate network server to provide source code: this may be a significant cost in some cases.

This is ultimately a use restriction (from the point of view of whoever runs the modified version of the Program) and effectively forbids private use of the modified version on a publicly accessible server. I'm *not* quite convinced that forbidding private use on a publicly accessible server should be considered as an acceptable restriction. Anyway, it's a cost (a significant one, in some cases) associated with running the modified version of the Program.

I did not see this comment at the time of AGPLv3 drafting; I had attempted to respond to as many comments as possible. I am commenting now since there is so much discussion on debian-legal and elsewhere linking to this ticket.

I should note that since March 2005, I do not speak officially for the FSF, (and therefore never did I even during the GPLv3 process), and my interest here is as an advocate and original inventor of the Affero clause. With disclaimer said, on to the matter at hand:

I believe that the restriction is not onerous. The objection stated in frx's comment is akin to objections to the requirements of source code provision in GPLv3. If you are putting the code into network production in AGPLv3, it is akin to distributing binaries of the software under GPLv3.

Indeed, I have seen objections to even GPLv2 compliance efforts over the "onerous nature" of distributing large amounts of source on the network when the binaries are much smaller and distributed on the network. I have also heard arguments that providing a source CD is too onerous. We don't accept these as arguments that the GPLv2 source provision requirements are onerous, and I therefore don't think we should accept similar arguments here. In the end, the license decides that if someone has the resources to distribute software under GPLv3, they have the resources to distribute source and it is required.

The requirement here is different but analogous. The only real difference is that it triggers at network deploy time and not distribution time. Some can argue that adding *any* restriction at network deploy time is onerous, and in that case, we simply must agree to disagree. But, if we can come to agreement that user freedom is worthwhile enough to add a requirement at network deploy time, then AGPLv3's is the least onerous the restriction can be.

Finally, the user always has the choice to not run the service if (s)he cannot comply with the license, just as the user has the choice to not distribute binaries if (s)he cannot distribute source as well under GPLv2 and GPLv3.

bkuhn: the only real difference is a critical difference, IMHO.

With the GPL, I have no restrictions when I run a modified version of a program. With the AfferoGPLv3, I have to distribute the modified version of a program, when I just want to run it on a networked server. With the GPL, I am compelled to distribute source when I distribute object code: in that case I have already set up some means to distribute software, the only restriction is that I am allowed to distribute source or object+source, but not object (without source). With the AfferoGPLv3, I am compelled to distribute source when I just want to run a (modified) program on a networked server: I have to set up some means to distribute source, and this could be a significant additional cost (in some cases).

Moreover, as MJ Ray points out in [1], reducing the freedom to "use, but not distribute" is outside the normal Free Software Definition. [1] http://lists.debian.org/debian-legal/2008/09/msg00034.html

Comment 3585: Bad faith "upgrading" of GPL to AGPL

"We don't suggest that all software should be licensed under the GNU AGPL. It is meant to be an option for developers who believe that the license's additional provisions on source availability will be beneficial for their applications." I believe my problems with the AGPL are perhaps best summed up by this paragraph, which assumes good faith by developers in their choice of licenses. I don't have the same faith in my fellow developers. This why I like the GPLv2. It prevents adding additional restrictions to my code. That way, I know other people cannot exploit my work. Now developers can take GPLv3 programs for which AGPL is *not* suitable, add improvements to them in the form of AGPL libraries, and release them with the full knowledge and understanding that the AGPL's restrictions will be onerous and unwelcome by the potential users of the software. These unethical developers will now offer a separate non-transferable license to be free of the restrictions thus imposed. The GPL software now becomes effectively propritetary. Nowhere is the one who adds the AGPL library to the GPL work required to abide by the AGPL restriction. He can host a further modified version on his own server without releasing his own source. He can even download other user's personal improvements to the GPL portion of the application, which must be made available under AGPL, and add them to his private, AGPL-exempt version. He can examine other user's personal improvements to the AGPL-covered portion which he wrote, and write his own clean-room version of the improvements for his private use. ("He" in this case could be a large corporation, such as Google.) Please, someone explain to me that I have nothing to worry about, and that this will not happen. I am losing trust in the FSF.

The act you describe as making code "proprietary" is exactly what google does now with GPLv2 code.

If I follow you logic your objection goes something like this:

A releases GPL code.

B modifies code from A with AGPL library and releases/SaaSs result. B also in-house modifies code from A and does not release/SaaS result.

C has access to code from A under GPL and code from B under AGLP, but does not have access to unreleased code from B.

This differs from GPL only in that C has access to some code from B which they otherwise may not. The library B added can be removed from the code B releases, the result is GPL where is the lock out?

Only the code released by the copyright holder under AGPL is not "pure" GPL. They wrote it and they could license it under BSD/MS-EULA/AGPL or any other license of their choice, it's their code.

The only restriction is:

if(you modify && you SaaS) then you must provide a link to source.

Don't modify || don't SaaS, and you can do basically anything you want with the code.

Hello dgandhi. Thank you for reading my comment and replying. Unfortunately, I must not have conveyed what I wanted to say correctly, because you missed my point. I will give a concrete example:

Google makes a version of emacs, called Google-emacs. They offer this as a web app (SaaS.) It has many new features and is popular. Now, they release a stripped-down version called Google-emacs-lite. This version requires a critical library called Google-web-library which is released under AGPL. Some of the additional functionality of Google-emacs is in the form of GPL libraries as well.

Some other people set up their own hosted versions of Google-emacs-lite and make private modifications. Some of the modifications are to the GPL portion and some of them are to the AGPL portion. These private modifications have to be made public due to AGPL. Google can make use of the GPL modifications in their full version, but Google doesn't have to release the code to the full version. Google can examine the AGPL modifications, but Google can't use them without being subject to the AGPL unless Google purchases a copyright assignment. However, Google can do a clean-room version and will be aided in doing so by being able to examine the source code.

Now Google's competitor, Yahoo, sets up a Google-emacs-lite server. They add additional functionality so that their version, now called Yahoo-emacs, is almost as good as Google-emacs. Google is taking all of Yahoo's work and incorporating it into Google-emacs. Yahoo wants to avoid exposing some of their internal business logic, which is needed to integrate Yahoo-emacs with their other services. Yahoo is also worried about criminals using the published source code to exploit bugs. Now, Google offers to sell Yahoo a license to use Yahoo-emacs without being subject to the AGPL. Yahoo agrees to pay Google a large amount of money for this.

Now here is my objection: The money paid by Yahoo to Google is not going to the true authors of emacs. It's a problem for any non-copyleft license. You write a program, and someone comes along and makes an improved version, adds distribution restrictions, and sells the right to be relieved of those restrictions. I could write a MIT-licensed program, and someone could make a shareware version.

I could write a LGPL program, and someone could make a GPL version and sell the right to use it under LGPL.

But this cannot happen with GPLv2! I am safe because it is a strong copyleft. No one can add additional restrictions and then sell the right to use the software not subject to such restrictions.

I am assuming that those who support AGPL believe that it is a *necessary* restriction, at least for certain classes of software. Then, they should not object if it were required that using other people's GPL code in an AGPL program would not grant the right to sell a GPL version of the AGPL work.

Above I gave an example of AGPL being used with SaaS. But someone could easily use AGPL on non-SaaS code. I can imagine creating an AGPL math library, where the use of AGPL would be solely to encourage commercial purchase of the code. And my objection is not to using AGPL itself but rather to the use of someone else's GPL math library as a basis for creating the AGPL version, and selling the right to use the whole thing under GPL.

Whoever is the first to add the AGPL restriction to a GPLv3 program and maintain full copyright ownership of all the added AGPL code has total ownership of the AGPL restriction, and can sell this usage right as if he owned all the code himself.

You might argue that it is better that Google would release some of their code at all. I agree that without AGPL, Google might not release their code. However, Google can't benefit from a community of developers that way. So with AGPL, the community gets a version they can use, but Google also gets help from the community. However, it is a rather one-sided help, because Google can take without giving (as before.) So now Google can get the best of both worlds. Their competitors can use the code, but only if they share it. But Google doesn't have to share. And Google can make money by selling licenses that let people do things they could already do with the GPL version.

My objection is that the benefit to the community (released code under AGPL.) is outweighed by the harm done. If I were an author of emacs, I would be so disgusted with Google's use of my code that I might lose faith in the GPL and prefer another license. I don't feel the same way about Google's private use of my code (if they would never release their source) because anyone can do that (even me.) They aren't using the code in a way other people can't. It's the asymmetry that bothers me, the fact that *they* can take without giving, and then "give" a version which prevents other people (even the author of the original) from doing what they do.

I came up with a partial solution that may be of interest: Do not license under GPL. Use AGPLv3 for *all* software, if feasible. Add a special permission to the AGPLv3-covered code that lets anyone use it without the AGPL-restriction, provided that they do not link it with any AGPLv3 code without a similar permission.

This seems to do what I want, but it is ugly and won't let me add any GPL code to my software unless I put it in a separate module. The best way may be to select some key code modules and apply the AGPLv3+exception to those, and keep the rest GPL.

So you can use my code under AGPL by removing the special permission, but since I own the copyright you need my permission to sell the use of it under any other license. And you can link my code with your GPLv3 code as if it were GPL. But cut-and-paste won't work, only linking.

Is this going to do what I want? Why should I have to do this?

I don't see how this usage of AGPL is any different from dual-licensing code under the GPL and a proprietary license, something the copyright holder can do today.

john1040:

You appear to be concerned with profit made from GPL code. I don't see this as in issue in itself for instance:

I can take GLPv2/3 code right now, and sell it to whomever will pay. I don't have to write a line of code, I simply have to make the source available to those to whom I sell the program.

I can make a proprietary patch to GPL code I can sell this patch under a non GPL-compatable license, those who buy/apply it would be unable under GPL to distribute the resulting patched app or code.

I can under GPLv2 entrench(or claim to entrench) patented code in an application and then enforce the patent, effectively holding veto power over use of the code. I can charge a patent protection fee ala microsoft/novel.

These counter-hacks of GPLv2 are at least as confining as those you mention for A/GPLv3. AGPL simply gives the community a tool to combat some of this. If Google(in your example) releases code with an AGLP library the community can develop in the library only, which would forbid Google from upstreaming the code without releasing it, since they no longer hold exclusive copyright, nor could they sell copyright exemption for the same reason. This I think fixes the asymmetry problem.

I view "counter act abuse by making everything AGPL" as a race to the top, not the bottom, some disagree. As the topology of how code is used changes, the bill of software rights which is the A/GPL needs to extend to these new frontiers. Otherwise we should all just be using BSD Licensing for all the use GPL will be if/when people just start renting Teraflops for fractions of a penny instead of owning hardware.

I think GPL3 should have had a SaaS provision, a significant vocal component of the community disagreed. AGPL is the compromise. Is it enough to ease GPL3 adoption? I don't know. I'll be using AGPL3.

john1040 has a valid point, which has nothing to do with money. I hope these examples make the situation clear:

If you have a LGPL'd library, you can write a GPL'd application to use that library. Now the Program as a whole is under GPL, although the library is still LGPL when it is separated from the Program. The original developer of the LGPL'd library cannot integrate code from the GPL'd application without making the library GPL. This is why LGPL is a weak copyleft license; applications using the library can apply additional restrictions to the Program as a whole.

If you have a GPLv3'd library, you can write an AGPLv3'd application to use that library. Now the Program as a whole is effectively under AGPLv3, because the AGPLv3 requires that also the GPLv3'd parts are subject to AGPLv3'd additional restrictions. The original developer of the GPLv3'd library cannot integrate code from the AGPLv3'd application without making the library AGPLv3 too.

If you have a GPLv2'd library, you cannot add any additional restrictions. If you write an application to use a GPLv2'd library, the application cannot have any code that couldn't be integrated back to the GPLv2'd library under the terms of the GPLv2. In this particular sense, the GPLv2 has stronger copyleft than GPLv3.

john1040: I'm not sure if I understand what you are trying with AGPLv3+exception. (A)GPLv3 explicitly says that any additional permissions can be removed. Thus anyone modifying the code under AGPLv3+exception is free to remove the additional permission, making the code pure AGPLv3. You cannot integrate such modifications to your original code base without changing the license from AGPLv3+exception to AGPLv3.

dgandhi: Making a proprietary patch to a GPL'd program is probably a copyright infringement. GPL requires that the changes are under the same terms as the original code (exception: GPLv3 allows the changes to be under AGPLv3 if the AGPLv3'd code is in a separate module).

larhuzu:

I agree that using somebody elses AGPL code would require an up/down grade (depending on your take) from GPL. But this is true of GPL also, If I add GPL code to BSD Licensed code I have to up/down grade to GPL. But BSD folks don't need to use GPL code, and GPL folks don't need to use AGPL code.

As far as I can tell AGPL preserves the four freedoms better then GPL, so I really don't see the reason for objection. If coders really feel that AGPL is restrictive it will receive little support, and people will not contribute to AGPL projects. Alternately, If people feel that GPL is ignoring the SaaS issue and decide to license everything they get their code in as AGPL then the dominos will fall that way. I expect that either GPL or AGPL will become a special use license, like the LGPL is today.

It seems to me that the OpenSource mantra of "the bazaar makes better code" has strategic significance here. While FSF does not care about that ideologically I think we can count on it having an effect on adoption, and the non-abuse of these licenses, as abuse will lead to lack of mindshare.

I spoke of a proprietary patch which is all original code, and distributes no GPL'd code (the author would have to clean up context in the diff to make sure, but it is possible). As the patch contains no copyright GPL anything it can not be restricted in any way by the GPL. If/when it is applied to GPL code the resulting code/bin is legally undistributable. The fact that GPL code was used as a reference does not "contaminate" the copyright of the result, contrary to FUD.

It's true for GPLv3 and BSD license, but it's not true for GPLv2 or AGPLv3.

The whole idea of *strong* copyleft is that all changes will be under the same terms as the original code. GPLv2 and AGPLv3 are strong copyleft licenses, while LGPL (any version) is weak copyleft. GPLv3 is somewhere between. With GPLv2 and AGPLv3 you will always get changes back under the same terms, while GPLv3 may have been combined AGPLv3 code, and LGPL combined even with proprietary code. If getting changes back under the same terms wouldn't matter, we would use only BSD or LGPL.

The additional "restriction" of AGPL is rather hard to trigger, that's part of why I don't see this as harming the strength of GPL, I can modify AGPL code, remove all code offers, and redistribute the result under AGPL. anybody who does not modify the code can now use it in exactly the same way they would GPL code as SaaS without providing code. Even if they do modify it they still have not triggered the difference between A/GPL until they SaaS it.

The four freedoms of GPL are not compromised, IMO by AGPL, therefor I see the pair as a pair of strong copylefts. AGPL provides more, not less code freedom then GPL3, and GPL3 more then GPL2.

As for code back under the same license, A/GPL are virtually identical, and for all practical purposes are the same except of special cases in the area of network service use. All modifications made to GPL code are GPL, the AGPL can only be attached by external interface(ie library) to GPL, as can any code for in house use.

I can write a proprietary library for GPL2/3 code and link it in house and use it for SaaS all day long. I can release the GPL code with the hooks to the proprietary code, but don't have to release the propiretary code, GPL simply denies me the privilege to convey code/bins of the conjoined work without A/GPLing my library code.

The code obstruction issue under AGPL is a general issue under all *GPL licensing AGPL does not make this worse, it arguably solves this problem to extent possible with a copyright based license.

Unfortunately it seems to be rather easy to trigger the AGPL's special requirement, because practically all applications can be accessed over a computer network (e.g. SSH, X11, or VNC). Please see http://gplv3.fsf.org/comments/rt/readsay.html?id=3573 (especially the Emacs example).

Think about AGPL'd plugin for the GIMP, which the GIMP developers would like to include to the official source tarball. Because the GIMP supports interaction through a computer network using X11, the GIMP must be coded so that it offers its source code. Practically it should be fine to provide a link to a directory on the local file system. Note that it's not enough to provide only the source of the AGPL'd plugin; one most provide source of the whole program as required by the AGPL.

If you want to create an installable binary package of the GIMP containing AGPL'd code, the binary package must also contain the whole source code tree. Otherwise the link to the source code wouldn't work. This increases size of the binary package considerably. This kind of problems make the AGPLv3-draft2 awkward for situations when the most common use for the application is not SaaS.

Today, most SaaS applications are written separately for SaaS usage. Personally I guess (and hope) that this changes in a few years so, that it is common to run the same apps both locally and as SaaS. It makes sense to require offering the source code only when the application is used remotely. The AGPLv3-draft2 doesn't achieve this.

To larhzu: Thank you for reading my comment and replying. My idea with AGPLv3+exception is one of copyright assignment and not licenses per se.

I will give a concrete example: http://www.opensource.org/node/152 scroll down to comment by albert76 concerning pbooks.

He says: "I imagine that banking customers would prefer the fee-based alternative for a license with a more commercial and private focus. It is because of the potential for a dual-license that I'll either require contributors to assign their copyrights to my company, or not accept contributions at all. "

He wants to use AGPL to sell a SaaS accounting program to businesses. Note that he believes his software will not be used by banks without paying for an AGPL-exempt version (commercial license.) As a side note, I would say that Free Software is software that is useful, and I don't see how a bank's use of my software is non-free even if it makes private changes. If the software as licensed under AGPL is not useful to the bank, and the bank's desired use of the software is not non-free, then I would say that the AGPL accounting software is non-free in the context of the bank's use of it. I would also say that a true Free Software believer would remedy this by offering a better license and that one who would only sell a non-transferable license which cannot be shared with other banks is a proprietary software vendor.

Now let me give an explanation of the reason for the AGPLv3+exception license. If albert76 links my GPLv3 program with his AGPL pbooks, he *does not need my copyright assignment* to do what he wishes with it. He already has my permission to link my code with his, and his AGPL-restriction applies only to his code, so he can sell a special license to the bank to use his code, by that bank only, without the AGPL-restriction. If my code were AGPL, this is no longer true. He can still use it, but to sell the bank permission, he needs my copyright assignment, because my code has the restriction too.

Now if I license my code under AGPL, but give a special permission to void the AGPL restriction if my code is linked only with GPL code or AGPL+same- permission code, then I am in the latter position with regard to albert76. However, the special permission effectively makes my code GPL, so other people can use it almost as if it were GPL, except that source integration is limited to linking.

My request is that the FSF think through the AGPL and its interaction with the GPLv3 to avoid such a convoluted license being in any way necessary or desirable.

Re: AGPL GIMP plugin.

If it goes upstream the url of the official SVN server on the spalsh screen would suffice to meet the requirement, would it not? As with GPL the source does not need to be distributed in tandem, it only need be made available.

If I modify and distribute/SaaS could I not put official+patch SVN urls on a splash screen? This sounds like a trivial fix.

To john1040: Seems that you are right, that AGPLv3+exception provides slightly stronger copyleft than plain GPLv3. With GPLv3, it's possible to combine the code with AGPLv3 and then offer a special exception to a *particular* paying customer: "As an exception, Foo-Bank is bound by the Section 13 of the AGPLv3 only if the modified Program is conveyed." Replacing GPLv3 with AGPLv3+exception, as suggested by you, prevents this kind of discriminatory additional permission.

I'm interested to hear what the FSF thinks about this example. I find this situation weird, because GPLv3 was supposed to be a strong copyleft license as opposed to LGPL, which is a weak copyleft license. If the GPLv3 had been intended to be a weak copyleft license, I would see no problem at all.

It's a bit late to say this, but maybe it would have been simpler to just keep AGPL and GPL completely incompatible with each other. It would have made GPLv3 stronger. Those who would have found the AGPL good for their projects could have had their existing code dual-licensed (or added a linking exception).

To dgandhi: It's a good question, and I don't know the answer. If you convey binaries (Section 6), *you* need to make the source available i.e. it's not OK to put an URL to upstream source, unless you and the admin of the upstream server have agreed that you can use the upstream server to convey the source (or at least I have understood it this way). But the requirements of Section 6 have nothing to do with Section 13, so it is possible that in this case pointing to upstream source is fine. I find the license a bit unclear about this. I hope someone is able to clarify.

Comment 3586: Linking to OpenSSL

Will it still be possible to link with the OpenSSL libraries as you can with the older license? My code uses libcrypto for all encryption functions, but I want to release it under the AGPL.

Mike

Comment 3587: AGPLv3-licensed software can be non-free

Some AGPLv3 licensed programs can be useless for a reasonable and free use if licensed under the AGPLv3. This means that these programs are not free, because freedom 0 is violated. I will give one example: a programming contest judge program At http://acm.uva.es/contest there is an online judging system for programming contests such as those the ACM runs. At http://acm.uva.es/contest/setup.html we find the rules for adding a new contest. At the bottom of this page there is a link to a sample Pascal program: http://acm.uva.es/contest/contest-judge-pascal.p If we download the Pascal program we find that it contains the answer to the contest. This program is a "judge" which must be kept secret from the participants in the contest. This is a common-sense measure and it does not constitute unfair or non-free use. If the judge program is subject to AGPL then it obviously cannot be used for its intended purpose. Programs of this nature are common in academia. One common use is to judge programming assignments. The GPL is used by many academics. If AGPL code cannot be used for judging homework and contests, it will partially discredit it among a select but very influential set of potential users. The matter is made worse by the fact that GPLv3 code can be upgraded by linking to produce AGPLv3-licensed code (see Comment 3585: Bad faith "upgrading" of GPL to AGPL.) A proprietary contest-judging program can be produced by improving a GPL version with AGPL code modules. A license would need to be purchased to use this program for its intended purpose. I hope that the FSF will consider this issue and rectify it. The problem is obviously broader in scope than the example given suggests. It is one of code privacy versus code freedom.

AGPL can apply to data.

Above, I argued that AGPLv3 can have problems (and be a non-free license) due to the fact that it prevents certain reasonable private use of software. In the example given, a contest judge program cannot be used under AGPLv3 without revealing the answer. I now realize that this problem extends to data files. According to this source: http://interviews.slashdot.org/ article.pl?sid=01/06/05/122240 GPL can apply to data files. If AGPL also does, then (for example) one might be required to distribute the entire contents of a online database if it were interfaced with AGPL code. This might include private user data.

This issue simply does not apply to offline distribution. An OS distribution doesn't include private data. The user adds this data after installing it. He never distributes it in this modified form. If he wishes to distribute a modified version, he removes the private data.

An entire online application, together with its necessary data files, is not necessarily in a state such that it can be distributed without violating the privacy of its users. In some cases, this would even violate applicable laws.

If AGPL is interpreted this way, then one may be prevented from using AGPL code at all for many purposes.

Here is an example of what I am thinking about:

An online programming contest judge program is subject to AGPL, so the answers can be read out from the source code by the contestants, which is undesired. Perhaps one way around this would be to re-write the judge program to use a data file rather than code to judge the answers. Now the data file can be kept private, since we suppose it is not subject to AGPL because it is not code.

But now, suppose I modify GNU Emacs to provide an interactive game which quizzes the user on his programming ability. I distribute the elisp source code under the GPL but I put the essential data file needed to judge the answers under a proprietary license. Is this allowed? Of course it is not (would say the FSF.)

So we see that in the first example, the AGPL must apply to the data file as well and there is no escaping it.

Comment 3588: Source Not Receivable through No Fault of Network Service or User

[I follow my original AGPL V3 discussion draft 1 comment on the subject and take all other parent and child comments relating to the issue to date into consideration along with the discussion draft 2 rationale. I hope the completeness of the context makes up for the tardiness of this comment.]

Many users who are able to interact with a Program over a network often have some restricted circumstances in the basic provisions for access to the Program which prevents them from taking advantage of the opportunity for access to the Corresponding Source over the same network connection. See my discussion draft 1 comment for some detailed considerations, http://gplv3.fsf.org/comments/rt/readsay.html?id=3501 . Both my treatment of the problem in my discussion draft 1 comment and comments of others in discussion draft 2 have missed the full breadth of this problem.

The bare problem is the same as in my discussion draft 1 comment. Independent third party blocking of access to the Corresponding Source can occur if the provider of the Program as a service is allowed to limit the network server access to the Corresponding Source to the same connection or same network session as the one used to facilitate user access to the Program and such network connections or sessions may have a significantly limiting constraint. Some constraints on access to network connections are routine and necessary in some markets but often have additional problematic restrictions of which the licensee would not necessarily be aware. However, the scope of the hazard is much larger than previously considered by my own previous comment or other comments.

This is very different from most other comments in which the blocking of access to Corresponding Source would be under the control or direction of the licensee. An independent third party could and often would act between the licensee and the user to innocently block access to the Corresponding Source without the knowledge of the licensee in circumstances where the Corresponding Source is not publicly accessible. An independent third party is not a licensee and not subject to the license.

The two word remedy which I proposed in my discussion draft 1 comment should eliminate the currently most prevalent form of the problem and minimise the larger scope for which I do not see a suitable complete remedy.

1. DISPARITY BETWEEN THE RATIONALE DOCUMENT AND THE DRAFT LANGUAGE.

The rationale for the second discussion draft states clearly that the draft "requires people who modify the software to publicly provide source when users interact with the software over a network." Rationale for the Second discussion draft of the GNU Affero GPL version 3. - http://gplv3.fsf.org /agplv3-dd2-rationale.html. However, the word 'publicly' is not present in the draft language. If 'publicly' is meant, as it should be, then 'publicly' should be used in the license language.

2. ACTORS BLOCKING ACCESS TO SOURCE.

In discussion draft 2, there has been much comment on the problem of something operating between the Program as a service and the user which would prevent access to the Corresponding Source where the opportunity for access would otherwise be available.

2.1. LICENSEE CONTROL OR DIRECTION.

Most draft 2 comments have raised the issue for cases where the licensee providing the Program as a service has control or direction over software preventing access to the Corresponding Source even if that control or direction would be at arms length. As has been rightly identified, any control or direction which a licensee exercises, despite any effort to distance himself, even to the point of directing third parties, should be clearly understood to be a violation under the terms of the draft language.

Some comments have brought up the use of network protocols such as UDP which may be known by the provider of the Program as a service to be problematic for providing "some standard or customary means of facilitating copying of software". The provider of the Program may be expected to know that the protocol is problematic for copying software and understood to be in violation under the terms of the draft language for using a protocol to provide access to the Corresponding Source which is known to be in violation. As has been identified, the current draft terms should be understood to obligate the provider of the Program to provide a link to another network location to access the Corresponding Source over a network protocol which does not have well known problems for copying software.

The current draft language is already sufficient to correct knowing bad behaviour of the licensee, however, a way to counteract the possible effects of independent third parties is still needed.

2.2. INDEPENDENT THIRD PARTIES INNOCENTLY BLOCKING ACCESS TO SOURCE.

Any provider of the Program as a service which requires user authentication, operates within a limited provider network, or requires special hardware to access the service poses the risk that an independent third party may innocently block access to the Corresponding Source provided over the same connection. There is no suggestion that restricted means for accessing the Program itself is a problem. The potential problem is from the actions of an independent third party controlling the restricted means of access which may have additional restrictions innocently blocking access to the Corresponding Source.

2.2.1. AUTHENTICATION ACTORS.

Authentication may be needed to use the Program as a service for the network service to ensure a user or the organisation with which the user is affiliated has paid for a service. Such payment may not necessarily be for merely running the Program itself but may be for providing access to fee based content or performing other services for the user such as shipping a package.

Authentication may be provided by an independent third party. Often only one organisation providing authentication may be available for a particular user to use the network service providing the Program. The user may be limited to using the authentication provided by an organisation with which the user is affiliated.

2.2.2. OPERATION WITHIN A LIMITED PROVIDER NETWORK.

An issue somewhat related to the UDP protocol issue is operating the Program as a service over limited provider networks. Unlike the UDP case, the protocol used may not be expected to be problematic for "facilitating copying of software". One example would be a operating over a wireless network frequency, the access to which is limited to a small number of licensed network providers in a geographic area to avoid frequency interference.

The restriction in this case is the small number of network providers. If the actions of one or two network providers block access to the Corresponding Source, a particular user may have no other option for access.

2.2.3. SPECIAL HARDWARE ACTORS.

An issue which has not been directly raised in previous comments, is a requirement for interoperating with service for using the Program, which may only be facilitated by a particular type of hardware. This may be an issue of hardware which functions on a particular frequency; can encode and decode a particular type of data at adequate speed; supports a particular protocol; or supports a particular authentication method.

If the market for the particular type of hardware has not fully matured, the range of devices available may be small. A user may not have the option of purchasing a device which allows both interacting with the Program and has the capacity to copy the Corresponding Source.

3. MECHANISMS INNOCENTLY BLOCKING ACCESS TO SOURCE.

Proxy servers have usually been mentioned being the mechanism by which access to Corresponding Source may be blocked. However, while proxy servers may be the predominant mechanism currently, there is still a large scope for other mechanisms to block access.

3.1. MECHANISMS DESCRIBED IN MY DISCUSSION DRAFT 1 COMMENT.

The following mechanisms except for the addition of limited provider networks were described in my discussion draft 1 comment in more detail and only described here in summary form. Limited provider networks provide an opportunity and usual practise of imposing similar additional restrictions to those usually imposed when using common authentication methods.

3.1.1. CONVENTIONAL USER AUTHENTICATION OR LIMITED PROVIDER NETWORKS.

The network service providing the use of the Program has customers which contract with the network service to provide a service mediated by the Program. Users have an affiliation to a network service customer but have no direct relationship to the network service. The network service customer is an independent third party.

3.1.1.1. PROXY SERVERS.

Network service customers maintain proxy servers so that all their affiliated users have access to the network service through the network service customers' network address, username, and password. Most network service customers configure their proxy servers to severely restrict the activity of their users for preventing what the network service customers consider inappropriate use of their proxy servers and the access to other networks provided by the proxy servers.

3.1.1.1.1. PROXY SERVER CONFIGURATION.

A network service customer may configure their proxy server to restrict their users from accessing any but a list of authorised network addresses or block users from downloading files over a specified size.

A network service customer may configure their proxy server to block off site connections. If on site connections are limited to on site terminals, the configuration of on site terminals alone may restrict on site terminals.

3.1.1.2. ON SITE TERMINALS.

On site terminals provided by the network service customer may be the only means for accessing the network service. On site terminals usually have their connections mediated by the network service customers' proxy service. Most network service customers configure their on site terminals to severely restrict the activity of their users for preventing what the network service customers consider inappropriate use of their on site terminals.

3.1.1.2.1. ON SITE TERMINAL CONFIGURATION

A network service customer may configure their on site terminal client software to prevent access to any network location other than the network service itself or prevent downloads exceeding a specified size.

A network service customer may configure their on site terminals to prevent users from copying files to external media.

3.2. MECHANISMS INTRODUCED IN THIS COMMENT.

3.2.1. SPECIAL HARDWARE.

A service for using the Program may require a particular type of hardware which provides needed functionality for interfacing with the service.

Pocket communication devices are becoming increasingly common as special purpose hardware. Unfortunately not all pocket communication devices may be completely configured by the user. We may prefer that GPL firmware will be available for all devices and that any device can be easily extended to add storage hardware or other enhancements as needed, but the market may not satisfy our preferences.

In the medium term, devices which work with particular network services may only be available with the most restrictive designs in particular markets. Some designs may limit the capacity to download or store the Corresponding Source to a degree which is insufficient for copying some source code. Restrictions may be imposed on some file types, the size of files, or some other factor. Devices with the smallest size and least expensive design often exclude other more flexible devices from the market.

In the long term, the market is liable to provide devices which satisfy our preferences. The flexibility and storage capacity of pocket devices is liable to increase but we need a license which will preserve the freedom of all users for now and in the future.

4. REMEDY.

Simply requiring the licensee to provide access to Corresponding Source from a publicly accessible network server should avoid or greatly reduce the problems described in this comment. The more public the network location for accessing the Corresponding Source the easier it would be for any user to access the Corresponding Source without the restrictions imposed by third parties controlling particular authentication systems, network providers, or special hardware. A publicly accessible network server is most likely to provide the opportunity for such a multiplicity of points for gaining access to the network that it should be fairly easy to find an alternate path to work around the possibility that access from some network connections may be impeded.

4.1. AUTHENTICATION FOR ACCESSING CORRESPONDING SOURCE IF NEEDED.

If some licensees believe that they should not be compelled to provide access to Corresponding Source for anyone other than actual users of the Program those licensees could use an authentication method for access to the Corresponding Source which would function on a publicly accessible connection. Each session using the Program could provide the opportunity to obtain a one time use user authentication code to use when obtaining access to the Corresponding Source.

5. POSSIBILITY OF SOCIAL PRESSURE WITHOUT CHANGING DRAFT LANGUAGE.

The license language should be clear and strong so that licensees will know what is expected of them without any need for social pressure to correct for problems created by lack of clarity or strength of license terms.

Social pressure tends to work most effectively on the already willing and to correct simple misunderstanding of the intent of the license. A special difficulty for correcting the problem identified by this comment is that the real problem is created by restrictions imposed by third parties who may be especially reluctant to facilitate the intent of compliance with a license to which they would not be not a party when providing indirect access to a covered Program.

Furthermore, I know of some potential licensees who have made statements asserting their disapproval of the intent of some copyleft terms placing user freedom above developer freedom and that they believe that common proxy server practises will make AGPL V3 ineffective in many circumstances. I will not improperly identify those organisations which have not yet acted against the intent of a license which does not yet exist. However, those organisations believe that they would have sufficient cover in the terms of the current draft license to evade the intent of the license while complying with the precise terms.

FSF may be able to have an adequate effect in applying social pressure on many licensees but not every developer will be willing to make an assignment to FSF. The license itself should be strong enough so that developers from small organisations do not believe they have unnecessary pressure to assign their copyrights to the FSF as the only means to obtain effective compliance with the intent of the license.

The license must be general enough to be universally applicable but specific enough to be clearly understood and easily enforceable.

6. SUGGESTED SOLUTION.

My suggested solution adds the words "publicly accessible" to qualify the network server from which the opportunity for Corresponding Source is accessible.

6.1. DIFF OF SUGGESTION CHANGE.

{{ Double braces mark material to be added.}}

" Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a {{publicly accessible}} network server at no charge, through some standard or customary means of facilitating copying of software."

In answer to privately received criticisms of my comment, I supply the following clarification and two new suggestions for changes to correct for rightly identified deficiencies in my now withdrawn originally suggested change.

1. LIMITING EXTRA BURDEN TO USERS WHO CAN MEET IT.

The principal objection to the form of the solution which I had proposed previously is that some licensees would neither have access to a publicly accessible network server nor adequate means to obtain such access.

I had not previously thought about non-public mesh networks or other cases where the licensee might be anyone with the most modest resources at any node in a non-public network. I wish someone had identified the mesh network or node issue when I introduced the problem in a narrower scope in a discussion draft 1 comment so I could have have thought about that case earlier.

I see this case for non-public mesh networks and possibly an employee acting on his own inside a corporate intranet and have a solution which is tailored to only impose a public accessibility burden on those who can meet the extra burden.

1.2. CORPORATE INTRANET USE.

Corporate intranet use was raised as a possible example where an extra burden might be required where resources may be insufficient to meet a public accessibility requirement. This puzzled me at first until I thought of one possible case of an employee acting independently of the corporation.

I had not thought that corporate intranets would really be relevant to the discussion of an independent third party blocking access to the Corresponding Source.

I had presumed that in the case where the corporation was the licensee that those with access to software interacting remotely within the corporate intranet would be employees of the corporation. As employees, they would be legally indistinguishable from the corporation in this context. Therefore, the employees would not be users who did not already have legal access to the Corresponding Source through the corporation even if they did not have personal access. Employees would not be users in their role as persons outside of the employment context because they would have no access to the corporate intranet except as employees. Treating everyone as only having a role as a natural person might be nice and perhaps preferred by me in the context of the license but insufficient in the real world, therefore, the law treats corporations as persons.

Any corporation, however tiny, which provides off premises use of their intranet to users who are actually users and not the corporation itself (which includes employees) would have more than enough resources to make the Corresponding Source publicly accessible. Remember, as I explained in my full comment, they could still implement one time use individuated pass codes issued during user sessions to ensure that only actual users can download to preserve expenses. Merely ensuring that the network location for access to the corresponding source is public was my intent, although, I would hope that few would bother with authenticating actual users to whom they have an obligation under the license.

Any corporation granting on premises use of their intranet to users other than the corporation itself (which includes employees) would not be likely to have an independent third party acting between themselves and the user. Without an independent third party acting between the user and the licensee, the issue raised by my comment would not apply.

Perhaps the licensee might be an individual corporate employee acting on his own independently from the control and direction of the corporation who runs the Program for others to use inside the corporate intranet. The Program may be used by other employees inside the intranet. The corporation may configure an intranet proxy server independently from the control and direction of particular employees in such a manner as to block access to the Corresponding Source. Such a case would then be analogous to the non-public mesh network case and as such the same solution would work.

2. DEGREE OF PROBLEM MANIFESTATION.

The likelihood of an independent third party actually blocking access to the Corresponding Source has been questioned. However, nothing needs to change for blocking to be common in some markets including the market for which I develop software. Furthermore, there is a strong prospect of a hazard which may effect everyone in the medium term future.

2.1. BIBLIOGRAPHIC LIBRARY PROBLEM INSPIRATION.

The cases which inspired my thought about this problem in the first place are not going away.

2.1.1. PROXY SERVERS.

In the bibliographic library domain in which I work on software, the most valuable software services providing access to premium copyrighted content universally use IP based authentication through an institutional proxy server. Some very severe restrictions are routinely applied to traffic over library proxy servers which block access to network locations outside of an approved list, limit download sizes, or otherwise have overly broad restrictions intended to ensure only appropriate use.

The practical effect of such proxy server restrictions to block access to Corresponding Source may be limited to a small portion of covered programs where the code is especially large or includes some content needed for configuration and testing which does not compress well.

2.1.2. GENERAL ACCESS TERMINALS.

The greatest existing problem is the one most widely applied in the most restrictive manner.

The most expensive services of all are only available over particular general access terminals at the library to eliminate the expense of providing service access to a larger number of casual off site users and even to an excessive number of on site users. Library general access terminals are routinely configured to prevent abuse and enable only appropriate use in ways which violate the Americans with Disabilities Act (ADA) and prohibit saving files or transferring files from general access computer terminals. After access to buildings, the handicapped lobby appears not to read enough to care about ADA compliance inside libraries.

Appreciating the degree to which libraries restrict handicapped and every user's accessibility should provide some clue about their likelihood of respecting the interests of free software users. In my experience, the handicapped accessibility restrictions are difficult to avoid in public libraries and often in academic libraries as well. Such restrictions are constantly frustrating because they disable keyboard functions which provide the most efficient use of programs and even disable the find inside the document function which allows identifying relevant text quickly.

The problem is not that all modifications of the Program in all contexts may be blocked but that modifications of the Program for the most valuable applications of the Program in the market are the very cases for which access to Corresponding Source is most likely to be blocked.

2.1.3. CONSEQUENCES OF EXISTING MARKET CONDITIONS.

If a user has only a limited non-public means for accessing the Corresponding Source, then any blocking of limited access point may leave the user with no alternative for obtaining access to the Corresponding Source.

I know of software developers who are opposed to the prospect of AGPL 3 but who are expecting that it will not have any practical effect upon them even if they use AGPL 3 because of standard practises of third parties in the markets where they develop software. These developers include some developers of bibliographic software but also others who expect that the manner in which proxy servers are configured in the markets for which they develop software will block the download of sufficiently large source code archives.

2.2. FUTURE OF WIRELESS.

The greatest concern expressed in my full comment is one that is much broader than the concern which had inspired my original discussion draft 1 comment.

Companies operating similar to the providers of cellular telephone services may become the exclusive providers of ubiquitous wireless networking available over their non-public networks in the medium term future. A business model based on overselling network access to provide some service at an attractive entry price point ensures stringent controls which block anything which may threaten additional revenue for the network provider. If the business of a network provider includes leasing use of its own approved software and charging fees for others to provide interactive use of software over its network all on approved devices for connecting to its network, then downloading modifiable software which may be run over its network may be blocked as a means to minimise loss of revenue. All the while, the network providers' practises detrimental to the interests of free software users may be publicly described as necessary measures to ensure network quality for all members of its network.

If you expect the market to provide sufficient competition to offer alternatives in a ubiquitous wireless future, then look more closely at the case of the cellular telephone business. The limitations of spectrum allocation and the expense of winning a bid for use of the spectrum and building the facility to provide ubiquitous network access creates natural monopoly conditions established and protected by governments.

In the long term, improvements in compression to allocate more space in the spectrum, reductions in costs, changes in government policy, etc. may be corrective. However, AGPL 3 must not be insufficient to protect against current realities or medium term possibilities.

3. LANGUAGE OF REMEDY.

A suggestion has been given that the wording from my former suggestion 'publicly accessible server' would need a formal definition for clarity.

I do not believe that it is necessary to describe what public means in the context of network accessibility. The common ordinary language understanding of public as being available to all people equally without special exclusions should be sufficiently well understood without having to state it.

I have not thought of the issue in terms of standard protocols. As my full comment explains, the more public a network is the more likely a user is able to have multiple options for connecting to the network in case one is blocked.

4. LIMITING SOURCE DOWNLOADING TO ACTUAL USERS.

A concern was raised that publicly accessible would mean that licensees would not be able to limit downloading of the Corresponding Source to actual users. I think that my full comment was not read sufficiently well for such a concern to be raised.

As I said above, I hope everyone would publish source code for anyone but I can understand some reasons why some licensees may wish to limit the opportunity to actual users and my full comment explains how easy that can be while providing a publicly accessible network location to ensure that those users have the best chance to obtain an unobstructed connection to the network server.

5. CURRENT PROPOSED SOLUTION.

While I dislike the idea of treating licensees differently by any characteristics of the licensee, I recognise the capacity of the licensee to meet the burden of a remedy is the difficulty with the solution which I had proposed. Therefore, differentiating licensees by their capacity seems to be a reasonable solution to the problem where no solution that treats all users identically seems sufficient.

Unfortunately, a clear exposition of the distinguishing licensee characteristics and conditional obligation seems to require more words than I had hoped would be necessary to correct this problem. Despite the unfortunate degree of additional words required, I believe that this issue is much too important and much too likely to be a serious problem to be overlooked on those grounds.

[I have numbered the suggestions for changes as if my now withdrawn earlier suggestion is suggestion number 1.]

5.1. SUGGESTION 2 CHANGE.

The clarity required seems to need an additional sentence.

5.1.1. DIFF OF CURRENT SUGGESTION 2 CHANGE.

{{ Double braces mark material to be added.}}

" Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. {{If you are required to provide access to the Corresponding Source in accordance with this section and you have a publicly accessible network server from which you could provide such access, then you must provide access to the Corresponding Source from a publicly accessible network server.}}"

5.2. SUGGESTION 3 CHANGE.

If it is really necessary to explicitly specify the possibility of restricting the ability to download the corresponding source to actual users, then the additional clarity seems to need yet another additional clause of some length.

I would prefer having the possibility of limiting downloads to actual users as a possibility which can be inferred from "offer all users" which is limited to users and not everyone. However, people might reasonably object that a publicly accessible network location implies a publicly accessible download. I do not wish license use to be less because some people would have some need to limit downloading of Corresponding Source to actual users and fail to recognise the reasonable inference of the possibility from the language already present in the draft.

5.2.1. DIFF OF CURRENT SUGGESTION 3 CHANGE.

{{ Double braces mark material to be added.}}

" Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. {{If you are required to provide access to the Corresponding Source in accordance with this section and you have a publicly accessible network server from which you could provide such access, then you must provide access to the Corresponding Source from a publicly accessible network server, although, you may limit the provision of the Corresponding Source to only actual users of the Program provided that anyone may have access to the network server from which actual users are identified.}}"

1. CURRENT PROPOSED SOLUTION CORRECTION.

In the transformation from the withdrawn suggestion 1 change in my full comment to suggestions 2 and 3 changes in my previous child comment, I seem to have lost the full clarity of the draft language for the addition sentence in my suggestions. The need to include the suggestion in a separate sentence lost the notice provision represented by the "offer" and some qualification of access to the Corresponding Source. Therefore, I propose a corrected form of my current suggestions 2 and 3.

I hope that along with a few other additional words in the correction that the phrase "as specified by this section" is sufficient to avoid repeating the whole language of the first sentence of section 13 to ensure that licensees who are able provide users the best opportunity to access the corresponding source do provide that best opportunity. As the examples of innocent independent third party blocking from my previous child comment show, an increasingly large number of users are otherwise likely to have their only point of access to some source code blocked.

If all licensees would comply with motivation for the license, the omission would not be a problem. However, we need a license with clear language precisely to ensure the compliance of those who may otherwise lack the proper motivation in the absence of a license.

The diffs are in relation to the AGPL V3 discussion draft 2, not the former version of my suggestions for changing the draft.

1.1. CORRECTED SUGGESTION 2 CHANGE.

1.1.1. DIFF OF CORRECTED CURRENT SUGGESTION 2 CHANGE.

{{ Double braces mark material to be added.}}

" Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. {{If you are required to provide access to the Corresponding Source in accordance with this section and you have a publicly accessible network server from which you could provide such access; then you must include in the offer to the users, as specified by this section, access to the Corresponding Source from a publicly accessible network server.}}"

1.2. CORRECTED SUGGESTION 3 CHANGE.

If it is really necessary to explicitly specify the possibility of restricting the ability to download the corresponding source to actual users then this suggestion provides such language.

1.2.1. DIFF OF CORRECTED CURRENT SUGGESTION 3 CHANGE.

{{ Double braces mark material to be added.}}

" Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. {{If you are required to provide access to the Corresponding Source in accordance with this section and you have a publicly accessible network server from which you could provide such access; then you must include in the offer to the users, as specified by this section, an opportunity to access to the Corresponding Source from a publicly accessible network server, although, you may limit the provision of the Corresponding Source to only actual users of the Program provided that anyone may have access to the network server from which actual users are identified.}}"

[Corrected repost for incomplete overlooked editing of suggestion changes.]

1. CURRENT PROPOSED SOLUTION CORRECTION 2.

In the transformation from the withdrawn suggestion 1 change in my full comment to suggestions 2 and 3 changes in my previous child comment, I seem to have lost the full clarity of the draft language for the addition sentence in my suggestions. The need to include the suggestion in a separate sentence lost the notice provision represented by the "offer" and some qualification of access to the Corresponding Source. Therefore, I propose a corrected form of my current suggestions 2 and 3.

I hope that along with a few other additional words in the correction that the phrase "as specified by this section" is sufficient to avoid repeating the whole language of the first sentence of section 13 to ensure that licensees who are able provide users the best opportunity to access the corresponding source do provide that best opportunity. As the examples of innocent independent third party blocking from my first child comment show, an increasingly large number of users are otherwise likely to have their only point of access to some source code blocked.

If all licensees would comply with motivation for the license, the omission would not be a problem. However, we need a license with clear language precisely to ensure the compliance of those who may otherwise lack the proper motivation in the absence of a license.

The diffs are in relation to the AGPL V3 discussion draft 2, not the former version of my suggestions for changing the draft.

1.1. SUGGESTION 2 CHANGE, CORRECTION 2.

1.1.1. DIFF OF CURRENT SUGGESTION 2 CHANGE, CORRECTION 2.

{{ Double braces mark material to be added.}}

" Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. {{If you are required to provide access to the Corresponding Source in accordance with this section and you have a publicly accessible network server from which you could provide such access; then you must include in the offer to the users, as specified by this section, an opportunity to receive to the Corresponding Source of your version from a publicly accessible network server at no charge.}}"

1.2. SUGGESTION 3 CHANGE, CORRECTION 2.

If it is really necessary to explicitly specify the possibility of restricting the ability to download the corresponding source to actual users then this suggestion provides such language.

1.2.1. DIFF OF CURRENT SUGGESTION 3 CHANGE, CORRECTION 2.

{{ Double braces mark material to be added.}}

" Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. {{If you are required to provide access to the Corresponding Source in accordance with this section and you have a publicly accessible network server from which you could provide such access; then you must include in the offer to the users, as specified by this section, an opportunity to receive to the Corresponding Source of your version from a publicly accessible network server at no charge, although, you may limit the provision of the Corresponding Source to only actual users of the Program provided that anyone may have access to the network server from which actual users are identified.}}"

Comment 3589: Remotely does not convey intended meaning well

[I raised this issue in an earlier comment on discussion draft 1 but my examples were grossly underinclusive. This comment is a revised form of my discussion draft 1 comment on the issue expanded to include extremely important overlooked cases and reference to the discussion draft 2 rationale.]

I am given to understand that the use of the word "remotely" is intended to protect private modifications in which the licensee and the user are one in the same. As such, I believe that popular understanding of the word 'remotely' is more likely to lead to misinterpretation of the license intent than it is to lead to a correct interpretation of the license intent. If remotely is understood as opposed to local, then use of the Program as a service over local networks via wired or wireless connections to the users' portable computers, or via general access terminals may be liable to be understood as excluded from the scope of the license.

1. SCOPE OF MISINTERPRETATION.

Examples of the scope of local wired or wireless connections which may be understood to be excluded against the intent of the license otherwise may be found everywhere provision is made for connecting laptops in which the Program may be running on the local network. Furthermore, the use of small portable computers with software provided from various local network points might evolve into a very significant provision for computing in which only data files are stored on a distant remote computer or users' portable computers.

Examples of the scope of local general access terminals which may be understood to be excluded which may be understood to be excluded against the intent of the license otherwise may be found everywhere provision is made for terminals at points useful to users in which the Program may be running on the local network. Such terminal points include general access terminals at bibliographic libraries, information kiosks, train ticketing terminals, etc.

Not all provision for connecting to a local network would be likely cases for the Program to be used locally and many might have access which would be understood to be distant and therefore not subject to misinterpretation. However, even where some remote use exists for some covered Programs other covered Programs may be provided exclusively via the local network.

2. DISPARITY BETWEEN THE RATIONALE DOCUMENT AND THE DRAFT LANGUAGE.

The rationale for discussion draft 2 clearly stresses the importance of having AGPL 3 apply as widely as possible. "A strong interpretation is also more forward-looking. When the web was first invented, it would have been hard to imagine that someone could interact with software through it. By keeping the GNU AGPL's scope broad, we can do our best to make sure that it will apply well when other methods for interacting with software are invented in the future." Rationale for the second discussion draft of the GNU Affero GPL version 3. - http://gplv3.fsf.org/agplv3-dd2-rationale.html .

If the scope of the license is intended to be broad, the language used in the license should make that breadth clear. Presumption of interpretation on the part of the FSF will not make the intended interpretation understood to licensees even if the FSF publishes a guide to understanding the license. The license language should convey the intent clearly in the license itself.

3. SUGGESTED SOLUTIONS.

Clear language expressing the proper intent can be provided with three simple words to qualify private use.

However, the use of 'remotely' may really be a spurious extra word and there may be no need to qualify private use in the context.

3.1. SUGGESTED SOLUTION 1.

"Remotely" should be removed.

3.1.1. DIFF OF SUGGESTION CHANGE 1.

[[Double brackets mark material to be deleted.]]

" Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it [[remotely]] through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software."

3.1.2. COMPLETED SUGGESTION CHANGE 1.

" Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software."

3.2. SUGGESTED SOLUTION 2.

"Remotely" should be removed and "all users" should be qualified with the parenthetical "(other than yourself)".

3.2.1. DIFF OF SUGGESTION CHANGE 2.

[[Double brackets mark material to be deleted.]]

{{ Double braces mark material to be added.}}

" Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users {{(other than yourself)}} interacting with it [[remotely]] through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software."

3.2.2. COMPLETED SUGGESTION CHANGE 2.

" Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users (other than yourself) interacting with it through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software."

Correction:

It should be clear from the context but in case it is not please read the two suggestions for possible changes in the draft language as independent not cumulative. I did not word the section headings properly in that case.

"SUGGESTION CHANGE 1" should be read as "SUGGESTION 1 CHANGE."

"SUGGESTION CHANGE 2" should be read as "SUGGESTION 2 CHANGE."

Comment 3599: make explicit references

should make explicit reference that the code to be made available *must be* the code running *now* on the current server, and cannot be a "copy" or "slightly old version"...

Comment 3603: not true over a network

Maybe this could be clarified. If there are cases when permission from the copyright holder is not necessary for someone to modify software (without distribution), nor to allow users to access the program over the network, then it would seem the extra provisions of the AGPL (over the GPL) would not need to be followed. People would be able to run AGPLed software on their own computers, and not allow remote users to access the source, as the host had not accepted the license.

Of course, section 13 says that users' rights to access the source code is "notwithstanding" any other provision of the license. So maybe this section 9 sentence should explicitly state that not accepting the license doesn't grant the right to run the program for users to access remotely. Or does that seem too much like a proprietary EULA, in that it attempts to restrict rights that the user already has?

Comment 3606: Modifier != operator?

This clause is directed towards someone who modifies the Program, but the preamble states that the intention of the licence is to require "the *operator* of a network server to provide the source code of the modified version running there to the users of that server". But generally the operator may not be the one who has modified the Program.

So say we have a web application that is modified by Person A, and the modified Program (as required under clause 13) does indeed "prominently offer ... an opportunity to receive" the Corresponding Source. The operator, Person B, then uses Person A's version without further modifications, but uses other means to remove the "prominent offer" from web pages as actually viewed by users.

The operator isn't in breach of clause 13, because it hasn't modified the Program, and the modifier isn't in breach because they included the prominent offer in their own version.

Comment 3607: The new BSD advertising clause?

Other people have already raised the question of what constitutes "interaction". I imagine what the AGPL has in mind is something like (say) Wordpress: software that runs on top of a LAMP stack, with which users "interact". But what if software further down the stack is also licensed under AGPL? A modified version of PHP or Apache, say, licensed under the AGPL. And perhaps under that, changes to various GNU tools, again licensed under the AGPL. Are these being "interacted" with by users?

Each of those programs each needs to provide its own, presumably *separate*, "prominent offer" of an opportunity to receive its Corresponding Source. You could end up with tens or hundreds of "prominent offers" on a single website. Hence my reference above to the BSD advertising clause. Perhaps it ought to read, "If your modified version provides an interface by which users interact with it [remotely] through a computer network", or similar. This would then restrict the obligations to the software at the top of the stack.

Comment 3608: AGPL is not enforceable in the United States

AGPL is not enforceable in the United States Disclaimer: IANAL I did some research on case law and I found that AGPL is not enforceable in the United States. As I understand it, under US law there are four legal positions in which a party can find itself with respect to a copyrighted computer program it possesses: 1. Copyright owner 2. "Owner of a copy" 3. Licensee, governed by a contract such as an EULA 4. Unauthorized possessor Dismissing 1 and 4 as irrelevant to the discussion, we find that a user of AGPL software will be in either position 2 or 3. The AGPL is not an EULA. Neither the AGPL, nor the GPL, nor the LGPL are EULAs. They are not contracts. So we conclude that a party which uses AGPL software is an "owner of a copy." The AGPL purports to restrict one's right to modify software that runs on a public server. It bases this on copyright law, which restricts the right to make derivative works. However, 17 U.S.C. 117 (a)(1) gives the "owner of a copy" of a copyrighted computer program the right to modify the program if "... such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner" Aymes v. Bonelli, 47 F.3d 23 (2d Cir. 1995) said that: “[b]uyers should be able to adapt a purchased program for use on the buyer’s computer because without modifications, the program may work improperly, if at all. No buyer would pay for a program without such a right.”6“[The defendants], as rightful owners of a copy of the plaintiff’s program, did not infringe upon the copyright, because the changes made to the program were necessary measures in their continuing use of the software in operating their business and the program was not marketed, manufactured, distributed, transferred, or used for any purpose other than the defendant’s own internal business needs.” (as quoted in http://www.copyright.gov/1201/2006/comments/granick_wirelessalliance.pdf) This right to modify was broadened in Krause v. Titleserv 03-9303 http://caselaw.lp.findlaw.com/data2/circs/2nd/039303p.pdf Discussion: http://www.techlawjournal.com/topstories/2005/20051107.asp Krause is important to AGPL because it includes the use of software over a network. The court found that the "owner of a copy" of a computer program could add new features essential to its business -- including customer modem access to use the program -- without permission from the copyright owner. Krause was sited recently in a similar case: Weitzman v. Microcomputer 06-60237-CIV, 2007 WL 744649 (S.D. Fla. March 6, 2007). www.thelen.com/tlu/StuartWeitzmanVMicroComputer.pdf The established law of the land in the United States is that the "owner of a copy" of a computer program has the right to modify that copy for its business needs. The AGPL cannot restrict this right without being an EULA and using contract law. So, a SaaS provider that is the "owner of a copy" of an AGPL computer program has the right to modify its copy of that program to further its business needs, and it does not require the permission of the copyright holder to do so. This means that it does not have to provide the source publicly for any modifications that it makes. The only way to prevent this is to use an EULA and contract law.

AGPL is not enforceable in the United States

AGPL is not enforceable in the United States

Disclaimer: IANAL

I did some research on case law and I found that AGPL is not enforceable in the United States.

As I understand it, under US law there are four legal positions in which a party can find itself with respect to a copyrighted computer program it possesses:

1. Copyright owner 2. "Owner of a copy" 3. Licensee, governed by a contract such as an EULA 4. Unauthorized possessor

Dismissing 1 and 4 as irrelevant to the discussion, we find that a user of AGPL software will be in either position 2 or 3.

The AGPL is not an EULA.

Neither the AGPL, nor the GPL, nor the LGPL are EULAs. They are not contracts. So we conclude that a party which uses AGPL software is an "owner of a copy."

The AGPL purports to restrict one's right to modify software that runs on a public server. It bases this on copyright law, which restricts the right to make derivative works.

However, 17 U.S.C. 117 (a)(1) gives the "owner of a copy" of a copyrighted computer program the right to modify the program if "... such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner"

Aymes v. Bonelli, 47 F.3d 23 (2d Cir. 1995) said that: “[b]uyers should be able to adapt a purchased program for use on the buyer’s computer because without modifications, the program may work improperly, if at all. No buyer would pay for a program without such a right.”6“[The defendants], as rightful owners of a copy of the plaintiff’s program, did not infringe upon the copyright, because the changes made to the program were necessary measures in their continuing use of the software in operating their business and the program was not marketed, manufactured, distributed, transferred, or used for any purpose other than the defendant’s own internal business needs.” (as quoted in http://www.copyright.gov/1201/2006/comments/ granick_wirelessalliance.pdf)

This right to modify was broadened in Krause v. Titleserv 03-9303 http://caselaw.lp.findlaw.com/data2/circs/2nd/039303p.pdf Discussion: http://www.techlawjournal.com/topstories/2005/20051107.asp

Krause is important to AGPL because it includes the use of software over a network. The court found that the "owner of a copy" of a computer program could add new features essential to its business -- including customer modem access to use the program -- without permission from the copyright owner.

Krause was sited recently in a similar case: Weitzman v. Microcomputer 06-60237-CIV, 2007 WL 744649 (S.D. Fla. March 6, 2007). www.thelen.com/tlu/StuartWeitzmanVMicroComputer.pdf The established law of the land in the United States is that the "owner of a copy" of a computer program has the right to modify that copy for its business needs. The AGPL cannot restrict this right without being an EULA and using contract law.

So, a SaaS provider that is the "owner of a copy" of an AGPL computer program has the right to modify its copy of that program to further its business needs, and it does not require the permission of the copyright holder to do so. This means that it does not have to provide the source publicly for any modifications that it makes. The only way to prevent this is to use an EULA and contract law.