Review

It might be important to you that users of software you write are able to modify it, in which case you might release it with a copyleft license like the GPL. For example, imagine someone's making a device that will run Linux. They need to tweak Linux so it will work on this particular device, and they do that and sell you a copy. Because Linux is under the GPL, however, they also need to publish the source code for their tweaks.

Then along comes the web, and people no longer send out copies of their programs. Instead, the programs live on their server, and you talk to them with your browser:

This means that even if a program is under the GPL, the people interacting with it have no right to the source code. This was called the "application service provider loophole", and the AGPL was created to fix it. Mastodon is an example of AGPL software, and if you visit an instance you'll see a little "view source code" link. This isn't just something your instance is doing to be nice—it's required by the AGPL.

Or is it? A few months ago I read an interesting argument that you can easily bypass the AGPL: stick a "proxy" between the AGPL code and the user, which removes the source code offer:

How is this compliant with the license? The AGPL tells you that when you modify the program you must preserve its "offer the source to anyone who asks" behavior:

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.

The modified software still offers everyone the option to download the source, but then a different piece of software that isn't covered by the license runs a sub_filter 'source_url' '' and the user doesn't actually receive the offer.

Courts do care about intent and this is, of course, not what the AGPL authors intended, but it's not clear to me that what they intended is coherent? They mechanism they chose, a license that controls what you're allowed to do when making changes to the AGPL-covered software, doesn't seem like it would be able to prevent someone from making user-hostile changes to other systems between this software and the user.

Even if you think courts would see this differently, consider a case where modification and proxying are separated:

  1. Company A makes modified versions of Mastodon, BitWarden, or other AGPL software.

  2. Company A sends these to Company B, who hosts them behind a proxy that removes the source offer.

It looks to me like each company is compliant with the AGPL. Company A modified the software, but left intact the portion that ensures all users interacting with it receive an offer for the source. Company B wouldn't be affected by a requirement that if you modify the program you must offer the source, because they aren't modifying it.

(Not a lawyer, just an engineer interested in this sort of thing. Over time I've moved to non-copyleft licenses, including for server-side software.)

Comment via: facebook, mastodon

New Comment
12 comments, sorted by Click to highlight new comments since:

I don't think this works as a loophole in the case where the proxy serves no purpose other than to remove license notices. It might work in a case where the proxy was something transformative, had some other purpose, and failed to preserve licenses in a more passive way.

The key thing to know is that the US legal system runs on counterfactual court cases, and the ideology that informs judges' decisions is not a mechanistic programmer-ideology. In particular, they don't like to rule in favor of things that look like overt gamesmanship. So, when there's flexibility in the interpretation of terms, courts not only can choose interpretations that support the intent of the contract, they will systematically bias their interpretations in that direction. The details of the contract constrain what rulings they have available to choose from, but they usually constrain it less than you think.

I think there is also some path dependence in the legal system.

Imagine that someone sues Google for providing you outputs of some AGPL website in their search results. Almost certainly, Google would win.

Afterwards, the company that runs the link-removing proxy from an AGPL software can try using this as a precedent.

If necessary, more smaller steps can be made, navigating the courts to the desired decisions.

If the offer doesn't get displayed to the user, the modified version doesn't offer it.

That seems like a property of the system and not of the modified version? Which would be a pedantic point, except the license only makes requirements about what the modified version does.

Or if you don't think a court would see it that way, consider a slightly trickier case:

  1. Company A makes modified versions of Mastodon, BitWarden, or other AGPL software.

  2. Company A sends these to Company B, who hosts them behind a proxy that removes the source offer.

Who is violating the AGPL? Company A modified the software, but left intact the portion that ensures that all users interacting with it receive an offer for the source. Company B is not modifying it, and so isn't covered by section 13.

Edited the post to add this.

There could be an argument that hosting it behind a proxy counts as modification.

They define modification in the license:

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.

Since hosting it behind a proxy only requires making an exact copy, I don't think that argument would work.

My point (which I intended to elaborate, but didn't initially have time) is that hosting one of these modern software platforms involves a whole stack of components, any one of which could be modified to make apparently-noncompliant output without technically modifying any of the AGPL components. You could change the third-party templating library used by the Mastodon code, change the language runtime, even modify the OS itself.

Which means I mostly agree with your point: the AGPL is not strict enough to actually ensure what it wants to ensure, and I don't think that it can ensure that without applying a whole bunch of other unacceptable restrictions.

If company A doesn't offer source to company B, they're violating even standard copyleft.  It's unclear in the example whether company A or company B is offering the service to users - that'll depend on the specific business relationship between them.  It would take lawyers and time to figure out if there's been any infringement for a specific case.  

I'd guess there are variations of the arrangement that would infringe, and other variations that would not.  I'd also guess that there are ZERO real-world cases where anyone cares and is harmed enough to actually pursue it, and if they did, their software would be dropped from use worldwide long before anyone started publishing their modifications.

If company A doesn't offer source to company B, they're violating even standard copyleft.

In this example, A does offer source to B, and it's B that removes the offer before making the service available to users.

It's unclear in the example whether company A or company B is offering the service to users

Let's say B makes the service to users, and pays A to develop the software.

I'd also guess that there are ZERO real-world cases where anyone cares and is harmed enough to actually pursue it, and if they did, their software would be dropped from use worldwide long before anyone started publishing their modifications.

Why would the software be dropped from use? If someone had, say, offered MongoDB-as-a-service with this model during the time when Mongo was hot, my expectation is they would have had many customers.

Let's say B makes the service to users, and pays A to develop the software.

There's some subtlety in whether B is paying A as a contract, or buying software, or even just getting it for free as part of a bigger contract - it would come down to a judge to really decide.  It might be that nobody is violating, it might be that B is violating.  It's hard to see how A could be violating, as long as they didn't remove any required upstream capabilities and delivered the source to B.

Why would the software be dropped from use? 

Because the risk of lawsuit would be massively increased, by there being an ACTUAL lawsuit happening.

If someone had, say, offered MongoDB-as-a-service with this model during the time when Mongo was hot, my expectation is they would have had many customers.

Mongo didn't, as far as I know, pursue any AGPL violations.  There were a LOT of mongo hosting services around, none very successful, and none, AFAIK, that were making improvements to Mongo - AFAIK, they just distributed the Mongo source when asked, mostly ignoring the viral part of the license.  It's impossible to know whether that was because of AGPL or because people with that expertise used it to improve private instances that their lawyers said didn't trigger AGPL.

I've long been sceptical of the Affero-style licence terms.  It certainly DOES work in the sense that it (and GPL3 which makes use of it) is a forbidden license in many companies.  It probably does not work in the sense of letting the software be broadly used and forcing change/wrapper source to be published.

Fundamentally, I'm opposed for copyright to be applied to usage limits, as opposed to distribution limits.  It's fine to prohibit distribution of derivative works without source.  It's annoying (probably legal, but I prefer to just not try) to prohibit USE of code that you legitimately acquired and then privately modified.  I think it's fundamentally non-free software if I'm disallowed from using a modification for my own purposes (even if those purposes are accessible by others).

I know of zero court cases or even successful threats of such, which hinge on this clause.  Companies who are careful just avoid it, companies who aren't ignore it (and either aren't caught or the copyright owner realizes it's not worth pursuing).  Note that simple compilation or repackaging is a modification, so would trigger this, just as distributing a compiled or repackaged version does.

The fundamental tradeoff of getting your software/library to be popular and well used versus limiting the ways your customers can extend and use your software in less-publically-visible ways has changed in the last 30 years.  I think RMSs original goals (no printers you can't hack and recompile) have failed, even while the related concepts (high-quality software that you can adapt to your needs, even if you don't get the pre-adapted code to all your stuff) has become absolutely universal.  I also think that's a great thing. 

Huh, the AGPL doesn't work like my memory of the GPL here.

If it did, then I think the answer would be roughly: you don't need to proactively offer the source, you just need to make it available if someone asks. It would be fine to mail them a USB stick containing the code (though I'm not sure if you'd be able to charge for it).

So when Mastodon has a link to get the code, that's nice but it's not strictly required; and if someone removes that link, you still need to give the source to anyone who asks.

... But the AGPL says you have to "prominently" offer the code, through a network no less. That's not what I expected, and indeed I don't know how it would play out in the scenarios you describe, and mostly wouldn't want to guess.