Hacker News new | past | comments | ask | show | jobs | submit login

Yet another example of someone who doesn't understand the AGPL and how it doesn't work to protect your (or anyone else's) rights. It really is an utterly broken, non-free license. I've written about this in the past (read the topmost two replies too):

https://news.ycombinator.com/item?id=30044019

In fact, the author of this article claims to quote the AGPLv3:

> If you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there

But that is absolutely not the text of the license. You can check for yourself. That's not how the paragraph is worded at all. If that were the text of the license, it'd be a non-free EULA, since that wording imposes a restriction on usage, violating Freedom Zero.

Instead, the AGPL is a non-free copyright license because it violates Freedom 1, by instead imposing restrictions on modification, as I described in the analysis I linked above.

I really wish the FSF would stop pushing this nonsensical license and misleading everyone into thinking it does things it doesn't. Their PR around it absolutely does not reflect the actual wording and consequences of the license. It's deceptive and harmful to the free software ecosystem.




> Step 5: Stick a reverse proxy in front that deletes the source code offer (No license implication, does not modify the AGPL software in any way, see Clause 9)

> Heck, this situation could easily happen semi-organically - a reverse proxy doesn't have to be designed to explicitly remove the source code offer, it could merely be a protocol translator/wrapper that has no support for that specific message/tag, which is something that happens all the time.

Hmm I would be unsurprised a judge interprets the writing/configuring of a reverse proxy that modifies the HTML output or blocks access to some pages to be the same thing as editing the AGPL code yourself.

Though if I’m right, this implies that anything (load balancer, templating engine, protocol conversion, auth, etc) that calls an AGPL app also has to be open sourced even if the AGPL app is unmodified and doesn’t call any of your code. I can see why pretty much every company bans the use (freedom 0) of AGPL even on dev laptops: https://opensource.google/documentation/reference/using/agpl...


> Hmm I would be unsurprised a judge interprets the writing/configuring of a reverse proxy that modifies the HTML output or blocks access to some pages to be the same thing as editing the AGPL code yourself.

That would mean anyone using an ad blocker (or any other userscript) on AGPLed websites is in violation of the license too.

This is actually a very complex legal issue, because HTML can be copyrighted, and so making changes to it can be subject to the license. It's why I mentioned that web apps can conceivably benefit from the AGPL in a somewhat reasonable way if they self-serve their own source code, to sidestep the AGPL's anti-developer aspect.

But for something like MongoDB, where the protocol does not convey copyrightable portions of the software? Doesn't work. The AGPL is out of the picture by the time the bytes flow out of the server.


It really wouldn't mean that, this is fallacious thinking, the law is not code and intent is important.


Indeed, which is why ad blockers are legal. And thus, it follows that my interpretation of the two-party scenario is also correct, because similarly to the user running an ad blocker, the person running a reverse proxy has nothing to do with the licensing requirements imposed on a different person who modified the code.


No, I'm afraid it does not follow at all. Your two-party scenario displays intent to interfere with contractual rights. It may be a difficult situation to deal with legally, but it's very different from a user running their own ad-blocker.

As others have said, your thinking here is very much "apply the contract as if it were code, and then think of exploits/bugs". I don't believe this maps to the real world legal system very well.


> Your two-party scenario displays intent to interfere with contractual rights.

Only if those two parties actually colluded with that intent, and you can prove it.

Personally, I don't want to be on the hook for proving this kind of nonsense in order to enforce my license. If I cared about SaaSification, I'd much rather use an outright EULA that forbids it and cut out all this nonsense of pretending you can solve the issue with a free software pure copyright license.


> Only if those two parties actually colluded with that intent, and you can prove it.

Let's think about it though -

Party 1 hosts the software, and does so on an open endpoint that is very hidden, most/all users access it through party 2's proxy - there's intent, right there. In civil cases in particular, the standard of proof is on preponderance of evidence and what's most likely, not 'beyond a reasonable doubt'.

Again, you're falling very much for "software guy interprets law as code" through all of this.


Party 1 develops the software, and hosts it on an open endpoint that is not publicly advertised. Party 1 has met their obligations.

Party 2 hosts the software, and does so behind a wrapper that does not forward the source code offer (this doesn't mean a wrapper that does s/source code offer//; it could be a protocol converter, WAF, or any other number of things that could lose non-protocol-relevant data like a source code offer).

None of this demonstrates intent. In fact, I have ended up in the Party 2 scenario accidentally already (in my case I was both parties, but that was a a coincidence), as I ran an (accidentally) modified AGPL service behind another public server that used it as a backend. There was no source code offer at all to begin with, but even if there had been, the nature of the system involved would mean it would be pretty much impossible for that offer to percolate past the frontend and back to the external users, just the way the protocols involved worked, no explicit malice involved.


Party 2 in this case appears to be in violation, serving a service without the offer.

Then there was no particular intent there, and I'm sure when you realised, you remedied it?

Honestly we've wandered so far from "malicious actors can sidestep the license here that I'm not sure what your point is.


> Party 2 in this case appears to be in violation, serving a service without the offer.

If Party 2 has not made any changes to the source code, they have no obligation to make any offer under the license, since the requirement only applies to parties who modify the program. Party 1's obligations are not transferred to Party 2 when the program is. The license applies as written, there is no "carry-over" of state.


You are equivocating. You are making subtle changes to the qualifiers of the condition at issue (again[1]). Doubly odd for someone exhorting others to "read[...] very carefully".

Whether someone has "made any changes to the source code" is not the applicable rubric.

In this case you are constructing a stronger condition than the actual condition—which is much lower: to modify the Program. Your clever reverse proxy doesn't subvert this. (It's not so clever.) You're modifying the program whether you've touched any files containing plain text source code or not. (Even then, you probably have; cf IaC.)

Aside from that, others' points about courts not being simple machines that exist to be hacked is very relevant to this discussion and many others that devolve into this sort of thing when hackers get involved[2].

Overall, this is astoundingly bad synthesis for something that has gotten so much traction.

1. https://news.ycombinator.com/item?id=30179334

2. https://news.ycombinator.com/item?id=25687897


Are you arguing that creating a program that interacts with another program is "modifying it"? Because then essentially all software is a derivative work of everything else and the entire industry is one giant copyright violation.

Come on. You're grasping at straws here. That makes zero sense. It goes against everything we know about how software licensing works. It is extremely well established that interacting with software through stable, external interfaces does not constitute creating a derivative work of the software.


I am arguing, specifically, that your reverse proxy respects neither the spirit nor the letter of the AGPL and does not provide the kind of protections that you're claiming it would.

(Separately, if ever the words "come on" make their way into your response, or you have to try to invent an argument for another person so that you can simultaneously take it down, then your own argument is probably junk. Here you've done both.)


You argued, specifically, that,

> You're modifying the program whether you've touched any files containing plain text source code or not.

And that is just not how copyright works.

(Separately, if you ever find yourself linking to completely unrelated comments by the person you are replying to in order to construct an attack on them personally, then your own argument is probably nonsense, and you're probably not a fun person to have around.)


Do less Twitter.


The license applies as written and as interpreted in a court of law.

When you were both parties, you were in violation. And as you say party 2 hosts the software that party 1 has altered, you appear to be relying on a contractual barrier between party 1 and 2 that makes them separate entities to 'shield' the party actually presenting the service from having any obligations. It's entirely possible that a judge could interpret the 'you' in clause 13 to include any parties who are providing the modified version to their networked users.

Either way it's probably not really some sort of 'gotcha' that just allows you to circumvent with impunity.


I'm not relying on the contractual barrier, I'm relying on the interpretation of the clause as applying strictly to the behavior of the program as designed and embodied in the source code, and arguing that there is no moral requirement stated in the license for ensuring that that behavior is ultimately exposed to end users, and in fact, such a requirement would go against the spirit of the AGPL as a copyright license and it was explicitly written not to require that.

Some people might disagree with that interpretation, which is okay because it's the kind of fine point nobody will ever agree on until it ends up in front of a judge. Which is why I bring up the two party example, to sidestep that question.


But your two-party example is quite possibly fallacious, that's the point here, they may well be considered one party by a court, or equally responsible.

Further, if the New York Times website can be considered a copyright work, and my proxy provides an altered version (say, one that credits me with writing all the articles), I've probably violated their copyright. I think your proxy could fall foul of this sort of thing too.

You may have identified an area where a legal morass could be found if it comes up, but again I don't think it's "one simple trick that AGPL holders hate".


Slightly off-topic:

I'm surprised by how many internal technical details Google is intentionally leaking with their documentation here. Stuff about //third_party and //experimental etc.


Oh all that is public knowledge. You’ll find references to the repo layout in just about every open sourced project that comes with Bazel BUILD files.


It's extremely intentional! I wouldn't even call it a leak...


Thanks.

I meant 'leak' in the sense of 'oil leak'. Not in the sense of 'unintentional disclosure'.


I'd be pretty surprised if a court ruled in favor of a strict reading of the AGPL like this. I'd like to see an example, if any court has done so.

It seems like you have some kind of personal grievance against the AGPL. Maybe it would be more productive to take up these concerns with the FSF and respectfully suggest a revised AGPL, instead of declaring it "broken" and telling people not to use it.


The FSF has long since ceased to listen to anyone. Stallman hasn't changed his views one iota in the past 20 years, on any issue, even ones where he's obviously wrong. I've even emailed him personally; he stopped responding after the second email. That one's been a lost cause for a very long time. Many people have tried.


> I really wish the FSF would stop pushing this nonsensical license

I read your comment you linked to. To me, the FSF makes a lot more sense than your argument does, your workaround--have a server that makes the required offer and run it through a proxy that deletes the offer before anybody can red it--is not a workaround, it's a violation of the license you agreed to.


It would be a lot more helpful if you explained the reasoning behind your understanding, instead of just making an unsupported statement.


Isn't it obvious?

If you put a reverse proxy in between you (serving the code) and the user of the software with the intent of disrupting any serving of the code, you are not in fact making the code available. Hence, you can't claim to be meeting your obligations under the license.

IANAL but I suspect a judge would look on these kinds of arguments with the same enthusiasm as sovereign citizen nonsense.


> If you put a reverse proxy in between you (serving the code) and the user of the software with the intent of disrupting any serving of the code, you are not in fact making the code available. Hence, you can't claim to be meeting your obligations under the license.

As I explained, your obligations under the license are as to what modifications you make to the code, not how you run the code. This is both explicit (if confusing) in the wording of the clause, and implied in the AGPL being a pure copyright license, and has been confirmed to be the intent by people involved in authoring the AGPL.

You are misinterpreting the license because the FSF has endlessly marketed it as something other than what it is, and so everyone thinks it actually restricts usage (while simultaneously thinking it's a free software license, which is impossible if you know how free software is defined), and so everyone loves to make this "a judge would not let this kind of clever workaround fly" argument. Unfortunately for everyone, judges look at the text of the license, not the FSF's marketing, and the text of the license does not say what the FSF's marketing implies.


Ignore that work-around, and focus on the other workaround where you split the work between multiple parties.


The loophole mentioned in reply 30044019 is certainly interesting. But it's also important to note that the enforcement of the license is also heavily depended on the law. After all that's what the document is designed for.

Hypothetically, a lawyer might argue that the act of setting up a filtering reverse proxy counts as active violation of the license. All and all, the eventual result will be determined by the court, not people reading the license online.

Of course, a clearer license without such possible loophole is better (i.e. the license should explicitly enforce _public_ access of the source code, not just access of the source code).


I don't know, it seemed to protect this author's rights just fine.


Only because the company in question didn't actually read the license. Read my analysis to see how broken it is.

This company likely violated the AGPL (as it is doubtful they followed the source offer requirement when modifying the code) - in the same way as 99% of third party AGPL project contributors violate the AGPL on a daily basis, every time they make a change on a GitHub fork. It's a horribly anti-developer license. But if this company had wanted to modify and host AGPL software legally, without providing source, there are workarounds they could've used, as I explained.


> in the same way as 99% of third party AGPL project contributors violate the AGPL on a daily basis, every time they make a change on a GitHub fork

The full clause is:

> If you modify the Program your modified version must prominently offer all users interacting with it remotely through a computer network an opportunity to receive the Corresponding Source of your version ...

The requirement is not just for modifying code strictly. It's for offering the resulting program to users.

If I fork an AGPL project to contribute to it, modify the code, but don't actually host the modified resulting binary anywhere, I see no issues here. Sure, if I started hosting it, I'd have to update the source code links, but if I don't, then there's no users, so no link changes needed.

Similarly, if the project is well built, for example if the build process in the repo builds a binary that includes the output of "git archive" to serve, that link will always be up to date for any build, so you don't even have to update anything to start hosting a fork of it.

In your (linked) comment about the AGPL, you seem to be arguing that just forking and modifying the source code violates that specific clause. That it's violating "offer users interacting with it remotely .. source code". That is what you're arguing, right? Why would that kick in if you change the code but don't actually host the service in question where users can interact with it over the network?


> The requirement is not just for modifying code strictly. It's for offering the resulting program to users.

This is the same misunderstanding everyone makes, and that the FSF wants everyone to make.

> your modified version must [...]

You are not required to offer anything to users. Your modified version is required to offer the resulting program to users. The requirement is confusingly worded, probably deliberately, but what it actually requires is for there to be a mandatory feature in your modified version such that it itself offers the resulting program to users. You are required at the time of modification to ensure that your modified version, at the time of execution, makes that offer (as part of its code).

Yes, this is hideously unclear, but that's what the text really says. The requirement is on you at the time of modification (also implied by this being a copyright license), and that requirement is for the modified version to work a certain way.

I can't find the link right now, but IIRC legal analysis including people involved in authoring the AGPL has confirmed that this indeed was the intent; they didn't want to put in a restriction on usage (because Freedom Zero), so instead they came up with this cute (and broken) hack that applies at modification time. Unfortunately, they conveniently forgot to mention this restriction violates Freedom 1 instead.

> If I fork an AGPL project to contribute to it, modify the code, but don't actually host the modified resulting binary anywhere, I see no issues here.

By modifying the code, you have invoked the clause of the license that you quoted. If your modifications do not include a functional change to the code, such that, if run, it offers the resulting program to its users, then you have violated the license.

> Similarly, if the project is well built, for example if the build process in the repo builds a binary that includes the output of "git archive" to serve, that link will always be up to date for any build, so you don't even have to update anything to start hosting a fork of it.

Correct. Almost no AGPL project does this. It is the only way to remain compliant with the license and still have a sane development process, but nobody gets that. Indeed, this is the only situation where using the AGPL does not impose an undue licensing burden on developers, and it sucks that, as part of trying to sell the AGPL as magic anti-SaaS pixie dust, the FSF has obfuscated this, and pretty much nobody is actually putting this feature into their AGPLed app build system, and thus causing everyone collaborating on those AGPLed apps to violate the license every time, because if this feature isn't in place already it becomes the burden of every single contributor.

> In your (linked) comment about the AGPL, you seem to be arguing that just forking and modifying the source code violates that specific clause.

It does, unless you first implement that `git archive` feature, and then make your desired changes. Which, as I said, nobody does.

> That is what you're arguing, right? Why would that kick in if you change the code but don't actually host the service in question where users can interact with it over the network?

Because, as I said, the clause is really all about what kinds of modifications you are allowed to make and what would happen if users interacted with it over a network - that doesn't have to actually happen.


I see your point. I'm still not totally convinced, and have two followups:

Firstly, the pragmatic and in my opinion definitely correct reasoning:

Even if there is a technical loophole, as you describe, it doesn't matter because no one will enforce this so-called violation. The copyright holders of the code will not care if someone forks their code, updates it, doesn't update the link, contributes back, and has zero users.

Someone who does not host a modified copy is following the spirit of the license, the spirit the developer intended, and as such has basically 0 real legal risk. They also certainly did not cause any damages in their infringement, so I doubt the courts would care.

Second, the pedantic technical bit.

> your modified version must prominently offer all users

If there are 0 users of my modified version, I have offered a link to "all users". I guess I have to offer a link to myself if I'm playing around with my copy locally, but I somehow feel like I can figure out how to get the source code myself.


> The copyright holders of the code will not care if someone forks their code, updates it, doesn't update the link, contributes back, and has zero users.

You're correct, but the whole point of licenses is having them work as intended. We don't run the free software ecosystem on goodwill and "I don't care if you violate my license as long as I like what you're doing". Licenses exist for a reason.

> If there are 0 users of my modified version, I have offered a link to "all users".

My reading of that is akin to "all potential users", as implied by the requirement being on what the modified version does; the code itself can only affect potential users since it has no idea of what actual users may or may not eventually exist.


> the whole point of licenses is having them work as intended. We don't run the free software ecosystem on goodwill

But we do run the legal system at least partly good will, and licenses only matter in the context of the legal system. Obviously a less ambiguous better worded license is better, but I don't think it's necessarily that big a deal.

> the code itself can only affect potential users since it has no idea of what actual users may or may not eventually exist.

I don't think the law cares about this though. The law can know perfectly well after the fact that I personally did or didn't have any users. That I did or did not offer source code to all 0 users of my non-existent copy I'm not hosting. I don't really see why the copyright license can't make conditions based on real-world usage and hosting; very few laws are pure functions that take only source code as input, almost all of them reference reality.

I guess you'd argue that I'm opening myself up to liability by forking, say, mastodon and modifying it because now someone could host my fork, and that someone (who isn't offering a correct source code link) would be causing me to violate the license... But that seems like the sort of reasoning that wouldn't last a heartbeat in court. The person running my copy of the code should have modified it further to have the correct link, they are the ones that failed to comply with the copyright license terms for the version they run.

By analogy, in copyright law, fair use allows "violating" copyright in some cases, such as to copy a page of a book for teaching material. Your argument reads to me like saying "But the teacher copied a page of the book, gave it to his students for class, and then one of the students sold that page without permission from the copyright holder! Aha, the teacher has violated copyright". Which no court would ever hold to be true, even if a very literal reading of the law may be more murky.


> should have modified it further to have the correct link, they are the ones that failed to comply with the copyright license terms for the version they run.

But by not modifying it in the first place, they avoid entering into any legal obligations to do so. See the problem?

> But the teacher copied a page of the book, gave it to his students for class, and then one of the students sold that page without permission from the copyright holder! Aha, the teacher has violated copyright". Which no court would ever hold to be true, even if a very literal reading of the law may be more murky.

Nope, the student is the one who violated copyright here, as copyright also controls the right to distribution, not just making copies. By making the sale, a copyright violation occurred. The teacher is likely safe under fair use, as you say.

If the teacher were to sell his original copy of the book, that would be legal under the first-sale doctrine: the copyright holder's interest in distribution rights for a particular copy is exhausted after the book was initially sold. But the interest in the right to make copies persists, and since the copy made for class was not sold by the original copyright holder, but rather only made and distributed under fair use, it is not bound by the first sale doctrine, and distribution rights are still controlled by the copyright owner (they re-appear when the copy is made). And hence, the student is in violation, as such a sale would not fall under fair use.

People love to throw around this idea that the law is all subjective and judges work off of common sense, but that's really not how it works. The law is incredibly detailed on these things and lawmakers aren't stupid. This is all written in the books. Yes, there is some leeway for good faith interpretations, but the legal system doesn't run on whatever the judge feels is right on any given day. This is all spelled out.


You really do not understand the way the legal system works. The law would be more than happy to accept that there exists something that generates a link or git clone command to stand in as a distribution mechanism for the source archive which a competent practitioner could use to derive the program in question.

It is not going to sweat binary vs. Source distributions, and in fact, as long as an argument is sufficiently cogent, a court of law can probably mavigate multiple layers of indirection.

The law deals with people; and is not an ignorant machine. There is flexibility. There is also a principle in law that is basically expressed as "the court will hedge against inefficacy". If there are competing interpretations, the one that actually best upholds the intent of the legal construct will be gone with.

AGPL is considered Anti-SaaS pixie dust, as you call it, so the courts would look at it as "have you met your obligation under the license to make available to the user all code to allow the user to recreate your system's deployment?"

If yes, solid. If no, you have issues.

Not a lawyer, not your lawyer, but read way too many books on the nightmare that is our legal system to entertain your interpretation of the AGPL being unnavigable by a court of of law.


> The law would be more than happy to accept that there exists something that generates a link or git clone command to stand in as a distribution mechanism for the source archive which a competent practitioner could use to derive the program in question.

The requirement is for the source code for the corresponding version is what is advertised. The vast, vast majority of AGPLed apps do not have any automatic mechanism to match the currently running version to such offer; if there's an offer at all (which there often isn't, making all forks and branches violations unless they add it first), it's usually a hard-coded link, and then the onus is on the person making changes to first modify that link to point to their version.

Yes, there are technical ways in which you can make the AGPL work in a vaguely reasonable way, avoiding this problem by automating your way around it. And nobody implements them. If people understood these requirements and actually implemented those mechanisms, we wouldn't have this problem, and people would also be aware of just how special and non-free the AGPL is because it's imposing requirements on modification beyond what a free software license can.

I'm not saying it has to be a source code archive, but if it isn't a source code archive, then you'd better find a way for the app to magically know what git repo hosted elsewhere should be used as the source code offer link, and have it automatically update for any forks/branches and always stay up to date. Having an automatically generated local source code archive, or outright serving the source code of the currently live app (e.g. for interpreted languages) are the only sane ways I can think of of automating compliance with this AGPL requirement. Anything that points to another server or repo isn't going to stay up to date as people make changes, and then you're back to square one.


What if the code calls

git rev-parse --abbrev-ref @{upstream}

when the server starts and then provides this link in the web pages?

The link will be updated automatically in the forks.

---

About the version, call "git show -s --format='%cs-%h'" to get the current commit.


For what it's worth, this is what is done for SearXNG (AGPL 3 license, rolling release): https://github.com/searxng/searxng/blob/master/searx/version...

It doesn't prevent people to hide / change the information, but at least by default it works even in a fork.


Since your past comment is not-repliable, I'll reply here:

> Step 2: Make a change to the code - oops, license violation! Clause 13! I need to change the source code offer first!

> Step 1.5: Change the source code offer to point to your repo

> Step 2: Make a change to the code and push it

> Step 3: Open a pull request with your change

> Your change includes the source code offer commit in the history, and cannot be auto-merged.

The simple solution is to make the program a quine - make it able to serve it's own source code. That way it will always be up to date!


> The simple solution is to make the program a quine - make it able to serve it's own source code. That way it will always be up to date!

Indeed! Unfortunately, the FSF isn't interested in educating users about this requirement and how to work with it (probably because it would make it plainly evident that the license imposes fundamental restrictions on how you can modify the software, making it non-free), and so almost no AGPL software out there actually does this :(.

I'd be a lot less uneasy about running Nextcloud and Grafana if they had this feature. At least it would make it a lot harder for me to accidentally violate the license by, say, misunderstanding whether any given file is technically source code (which triggers the AGPL) or configuration (which would not), or installing Gentoo packages that come with patches.


What existing sane license would be free comparably to GPL2 level for "normal users", while also preventing the case of Amazon and MongoDB?


None. For better or worse, stopping people from using (which includes hosting for third parties) your code without publishing the modified source code is incompatible with the Free Software Definition.

Any discussion around what a license trying to solve that problem should look like needs to start by accepting that fact, and going from there. Either we change the Free Software Definition, or we accept that such licenses can't be Free Software licenses. There's no magical solution that satisfies both. You can't have your cake and eat it too.


I get what you’re saying from a philosophical perspective, but I think there are a lot of developers and shops that might care more about achieving this “anti-SaaSification” goal than they do about what the FSF thinks.

You can try and use terminology like “EULAs” to liken them to big corporations that restrict usage, but so long as it’s an instance of “the little guy” restricting usage on the part of “the big guy”, I have a feeling those criticisms might not stick.

I’m not saying they’re right necessarily, just that falling back on definitions like the FSD in arguments presupposes that the people you’re talking to know what the FSD is, care about it and share your belief system.


You're presupposing I oppose the principle of anti-SaaSification. I don't. I understand the problem and why some people care about it. You don't want big corporations to host and sell access to your code without contributing back. I get it.

What I oppose is what the FSF does, which is mislead people into thinking this is achievable within Free Software without making deep fundamental changes to what Free Software means. And I especially oppose the AGPL for its utter brokenness and unsuitability for almost any purpose.

> You can try and use terminology like “EULAs” to liken them to big corporations that restrict usage

That's correct terminology though. I'm not trying to use scary words to be scary. That's literally what EULAs do. If it sounds scary it's because it is a deep change to how a license behaves and people need to be aware of that.

If you want to release your software under an EULA that prohibits SaaSification, I have absolutely nothing against you - more power to you! It's your software. I have nothing against proprietary software either, I use it every day (though I prefer free software where possible, for a multitude of reasons).

Just don't try to hide the fact that that choice of license makes it non-free.

In fact, I'm a lot more reluctant to use AGPLed software than lots of proprietary software, because the AGPL is worse in that it pretends to be a free software license, giving you the code, and then sets up a landmine for anyone who actually makes a change to step on, and it has been marketed in a way that confuses everyone involved. As I mentioned in the reply to my analysis comment, I already accidentally violated the AGPL once because I ran a script that unknowingly patched some AGPL code without following the terms. If the code hadn't been there to begin with, or the AGPL had been correctly recognized as non-free and thus not amenable to such patching, that wouldn't have happened.


None. Being able to make money using other people's software in any way you want is a fundamental part of freedom 0. People using the software for commercial purposes are just as much of a normal user as anyone else.

>“Free software” does not mean “noncommercial.” On the contrary, a free program must be available for commercial use, commercial development, and commercial distribution. This policy is of fundamental importance—without this, free software could not achieve its aims.

https://www.gnu.org/philosophy/free-sw.en.html


And the AGPL does not limit commercial use, commercial development, or commercial distribution any more than the plain GPL (either v2 or v3) does. It just increases virality a bit, but personally I am of the opinion that that is an essential ingredient of allowing free software to remain free.

I also do not understand why "you need to share the source when you expose" is apparently so much worse than "you need to share the source when you distribute".


> I also do not understand why "you need to share the source when you expose" is apparently so much worse than "you need to share the source when you distribute".

Because distribution is an act controlled by copyright, while usage (which includes exposing) is not. That Free Software licenses are pure copyright licenses is a fundamental tenet of Free Software (which follows from Freedom Zero). We call licenses that restrict usage EULAs. You know, like the Windows license.

Thankfully, the AGPL isn't actually an EULA. In turn, it doesn't effectively accomplish its goal of avoiding SaaSification. Instead, it tries to work around this fundamental issue by imposing restrictions on how you can modify the code instead, therefore making it not Free Software, since such restrictions violate Freedom 1 of the Free Software Definition. Kind of like some of those weird nonfree "shared source" licenses.


The FSF seems to regard commercialization of private forks, and indeed the whole concept of SaaS/ASP as a bug or loophole in a free software license that needs to be fixed.

If you're free to exercise software freedoms, there is nothing whatsoever stopping that case. As marcan points out above, stopping this is fundamentally incompatible with software freedoms.

I have been pointing out this inconvenient truth for months, and I am glad to see someone else with this same conclusion because the flaming I received in response to this logical conclusion (which does not seem to have any subjective component) from free software people was making me wonder if I had gone crazy.


You might be right that there is a small addition in the runtime of the program, but there often is in GPL3 programs. For example, in CLI programs you are supposed to provide an option to display the license and where to get the source code.

I don't think this small addition to guarantee the integrity of the free software ecosystem deserves such strong language as "non-free". My feeling is corporations would love to take your argument and run with it to reduce the mindshare of AGPL. It's a classic PR tactic to pick on some small imperfection that serves a critical purpose and use it to gain an asymmetrically large advantage.


Your theory is wrong. A reverse proxy does not an arms-length transaction make. You can run the website through as many proxies as you want, it's still you running the code to show the end user a website, and you have to redistribute the source if you're using a modified AGPL program—and the theory of the GPL licenses generally is that by linking to a (A)GPL library, your new work counts as a modified version of that library. And sham transactions with separate entities would likewise just be treated as you just doing all the steps.

You're committing the same fallacy as a lot of software people: thinking that the law is a rigid computer program. Contracts are not executed like computer programs.

There's plenty of thorny issues with the GPL (and AGPL), such as imprecision over what constitutes a modified version vs. just an aggregation with other programs. But what you've identified is not really one of them.


> You're committing the same fallacy as a lot of software people: thinking that the law is a rigid computer program. Contracts are not executed like computer programs.

"Contracts are not executed like computer programs" doesn't mean you get to interpret contracts however you want, ignoring what is actually written. When I was working at Google, I had an argument with Chris DiBona about open source contributions that ended up with him banning me from that process, and telling me to "go to employment legal". I instead went back to my employment contract, and found that the wording was subtly screwed up; they got the Boolean logic wrong when transcribing wording sourced from California law into an Irish contract, and ended up turning an OR into an AND. And that meant I could contribute to open source in my free time at home with no worry of Google owning my code, so I did, and I'm absolutely confident no Irish judge would say "oh, you see, your contract says one thing, but clearly what Google meant was what's written in California law and so you're in violation". What matters is what's written down, not whatever the person writing it thought they were writing. This wasn't a case of a typo or an obvious correctable mistake; this was a change in the way the requirements for a clause applied, clearly with a different meaning from the original text, with no room for error. Whether it was an intentional change or not is not my problem.

If you dig deep enough into the history of the AGPL, you will find that not only am I right in my interpretation of it as a copyright license that applies to modifications, but that this was all completely intentional and amounts to a clever hack to try to give EULA-like powers to a non-EULA license, because the FSF knew they couldn't pass off an outright EULA as a free software license. And, like most clever hacks, it doesn't work properly in all cases, and the workaround I described is completely legitimate. And it's still nonfree, because instead of violating Freedom Zero it violates Freedom 1 (but they got that one to pass by without most people noticing, it seems).


You're confused. It's true that the AGPL only applies to modifications, but programs that link to (A)GPL libraries are considered modified versions of those libraries for purposes of the GPL. So if you link to an AGPL'd JSON library and use it throughout your website's source code, your website is a modified version of that product.

And as for your workaround, here is the text of the AGPL:

>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

You setting up a reverse proxy doesn't mean that users suddenly aren't "interacting with" the program. By the same logic, they aren't interacting with your program even without a reverse proxy, because they are actually interacting with their own computer, their own operating system, their own keyboard. No court would accept such a pedantic and useless definition of "interacting with" because it's clearly not what the contracting parties intended. Contracts terms are given their reasonable meaning, not unreasonable meanings.

You also complain about e.g. MIDI not having a way of sharing source code. Here, you're again misreading the license. The license requires that "providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software".

Notice what it doesn't say. It doesn't say it has to be offered over the exact same protocol. It just says you to offer it from A network server, through SOME standard or customary means. The license even goes onto say:

"If your software can interact with users remotely through a computer network, you should also make sure that it provides a way for users to get its source. For example, if your program is a web application, its interface could display a "Source" link that leads users to an archive of the code. There are MANY WAYS you could offer source, and DIFFERENT SOLUTIONS will be better for DIFFERENT PROGRAMS; see section 13 for the specific requirements."

It's true that earlier it says you must "prominently offer all users users interacting with it remotely through a computer network" an opportunity to receive the source. But in cases where the protocol literally has no way of embedding that information, then there's no reason to think you can't fulfill this requirement by, e.g., prominently including a link to the source code wherever you advertise or document the network service.


> You setting up a reverse proxy doesn't mean that users suddenly aren't "interacting with" the program.

That doesn't matter, because again, what the clause actually says is:

> your modified version must prominently offer all users interacting with it remotely through a computer network

If the version, as modified, makes the offer, then you have met your obligations at the time of modification. The AGPL is out of the picture after the modifications are complete, as it is a copyright license, not a usage license. The clause triggers when you modify the software - adding the reverse proxy in front does not modify the software, and therefore the clause does not apply at that point.

If your argument is that you are still bound by that requirement after the modifications, then all AGPL software authors are in violation of the license, at all times, since it would imply that the AGPL requires everyone who makes a modification to AGPLed code magically ensure that it always offers its source code to users, in all execution environments, no matter what reverse proxies are in front, operated by anyone, which is, of course, impossible.

> Notice what it doesn't say. It doesn't say it has to be offered over the exact same protocol.

If your users interact with the software via a certain protocol, then the offer obviously has to be made over that protocol, because there is no other way to make the offer. If I run an AGPLed DAW and hand a MIDI keyboard to a friend to play on, they are now a network user of the software, and the only way for them to be offered the source code is over that protocol. Of course the actual source code exchange could happen over a different protocol, but the offer has to reach the user (and prominently, as the clause requires) and that's not going to happen if you make the offer over a protocol the user isn't even using!


It is a violation of copyright law to make a modified work without permission, and the permission here is the license—a contract. Again, using the example of the hypothetical AGPL'd JSON library. Once you link to it and use it in your website's code, the resulting website code is a modified version of that library under terms of the AGPL, a binding contract that you accepted by creating that modified work. What you are suggesting would then violate that contract by using that modified version in a way contrary to the terms of the contract.

>If I run an AGPLed DAW and hand a MIDI keyboard to a friend to play on, they are now a network user of the software, and the only way for them to be offered the source code is over that protocol

This is obviously not true. You can offer them the source code as soon as you hand them the keyboard. (Of course, no one is going to sue you for giving your friend a keyboard, just like no one will sue you for giving him a print out of a copyrighted picture. No one caring + fair use deals with a lot of these stupid little scenarios.) I could quibble with you counting this as a "remote network interaction", but my point stands either way.


> It is a violation of copyright law to make a modified work without permission

Hence why I keep speaking of the time when you make changes to the code.

> and the permission here is a contract: the license.

Which in this case is a pure copyright license, and therefore has no impact on how you use the software, by design, because its requirements only apply to modification and distribution. Look up how the AGPL was created. This was a concern and precisely why they did the bizarre modification-time wording that I keep pointing out.

> What you are suggesting would then violate that contract by using that modified version in a way contrary to the license granted for its modification.

We have a word for licenses that impose usage restrictions. They're called EULAs. They violate Freedom Zero and are not free software licenses.

The AGPL is not an EULA, though it tries its hardest to look like one with that clause.

I honestly don't even care that much about people choosing to interpret the AGPL in this way; I actually used to think like you, until I re-read it enough times to really understand what's going on. You're arguing that the AGPLv3 is a nonfree EULA that actually works as anti-SaaS. I'm arguing that it's a nonfree non-EULA that doesn't work. In both cases, it definitely isn't a free software license that actually works as anti-SaaS.


Based on your post, your whole theory turns on section 9:

You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. HOWEVER, NOTHING OTHER THAN THIS LICENSE GRANTS YOU PERMISSION TO PROPAGATE OR MODIFY ANY COVERED WORK. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.

You're so focused on the first sentence that you missed the one I've put in caps. Once you link to the program, you've created a modified work, which as it says plainly right there in section 9, you cannot do without accepting the license, which is a contract that tells you what you can and can't do with that modified work.

I also suspect you're not really understanding that you don't have to touch the source code to the hypothetical AGPL'd JSON library to create a modified version of it. The whole theory of the (A)GPL is that you create a modified work by MERELY LINKING AND USING the library in your own code. The resulting program, including your own code that consumes the JSON library, is then a modified version of the library. This might seem counter-intuitive, but remember, the starting position legally is that you have NO RIGHT to use, modify, distribute, etc. a copyrighted work. You need a license from the owner. A license is a legal contract that can specify whatever terms and whatever conceptual framework it wants. You might think that linking to a library is merely "using" it, but the (A)GPL disagrees and that's the contract that tells you what you're allowed to do with it, take it or leave it.


> You're so focused on the first sentence that you missed the one I've put in caps. Once you link to the program, you've created a modified work, which as it says plainly right there in section 9, you cannot do without accepting the license, which is a contract that tells you what you can and can't do with that modified work.

First, you're still refusing to read Clause 13 properly, because it clearly sets requirements for what your modified work needs to do, not what you need to do when using it.

Second, this still fails the two-party test, because obviously you could convey the modified version to another party and then they would not be bound by anything, and could evade any source code offer requirements in place.

I feel like we're going in circles here; I already made all of these points in my original analysis.

I also don't know why you're bringing up linking. Linking doesn't factor at all in any of the scenarios I'm talking about. I know how the (A)GPL works in that respect and am extremely familiar with this concept; you don't need to SHOUT IN ALL CAPS about this completely irrelevant point. The licenses are very clear in what constitutes linking, and merely running executable binaries and communicating with them does not, which is the situation we'd have with an offer-stripping reverse proxy. This is extremely well established in the free software ecosystem. You don't need to lecture me on how the GPL works; I am very familiar with it, agree with the consensus interpretations of GPLv2 and GPLv3 (and LGPL), and know all about the linking stuff. It is the AGPL I have a problem with, which does not change any of the requirements related to linking.


That's an interesting point about Clause 13 talking about what the work must do, not the operator. I understand your point about the MIDI software better now. If indeed the protocol has no way of including a link to the source in any field or header or handshake or something, there is indeed a problem. Fwiw, I imagine that a small minority of network protocols have no way whatsoever of including that kind of metadata. And double so for software that a "user" can "interact with."

But generally, the two party problem is solved by them needing to modify the source to remove the link to the source.

As for the reverse proxy, I think the implied covenant of good faith and fair dealing in every contract would work to prohibit that, but it is a fun hypothetical.


> But generally, the two party problem is solved by them needing to modify the source to remove the link to the source.

The idea is the second party does not modify the source, they merely prevent the link from reaching the end user. Since the second party isn't bound by that clause at all, there's no way this could constitute a violation per se.


If I understand this part of the conversation correctly: the theory/loophole is that a second-party could proxy the AGPLv3-licensed content before it reaches the user, and remove links to the source code?


They could proxy access to an AGPLv3-licensed application, where such access does not convey copyrightable content. For example, consider a database server that puts up a banner with a link to the source when you open the connection. You could remove said banner with a proxy.

It actually doesn't have to be a second party in my opinion, I believe it'd be perfectly legitimate if it's the same party. I'm just using that as a more clear-cut example because otherwise things devolve into endless arguments about whether a judge would see it as good faith or not.


Doesn't the process of removing the banner imply that the original software has been modified?

(under that line of thinking, the network is the computer (computation is taking place in a distributed manner))


It does not. The copyrighted work is the code for the software, and making modifications means modifying the copyrighted software. Copyright has no notion of "modification" in the sense of changing the final behavior. It's strictly about making changes to the copyrighted work itself.

This is why things can get interesting with binary hooks and patches, which, depending on how they're done, can be argued not to be modifying the copyrighted work (e.g. a hook done via a hardware debug breakpoint does not require making any alterations to the target software per se, in the copyright sense). Similarly, interpreting (e.g. emulating) software is widely understood to be legal since you aren't modifying the underlying software, even if the emulator causes it to behave differently from the original intent.

Of course, then things get murky again with emulation techniques such as JIT, which could be argued to be creating a transient derivative work. Or not so transient, in the case of AOT. I would dare say there is a legal argument to be made that running older x86 Mac apps on an M1 Mac could constitute unauthorized creation of a derivative work (since it outright caches AOT recompiled versions of the apps you run using Rosetta). Of course, this seems stupid from a technical point of view, but I'd love to see if there is prior case law on this kind of situation, where a newly introduced technological mechanism can conceivably cause re-classification of the copyright effects of merely running software. It's certainly a deep rabbit hole to go into.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: