Hacker News Reader

Comment by woofie11 | Hacker News Reader

Yeah, it's complex:

* The article is right that Google IS spreading FUD. They're making legal statements which are probably false to minimize usage of the AGPL outside of Google.

* Google came to a sensible conclusion, that THEY shouldn't use the AGPL

* Google's articulated reasons don't hold legal water, and following Google's lead and interpretation causes many companies to mislicense their code

It's a right tool for the right job kind of thing, and AGPL is not the right tool for Google's job.

I've used all sorts of license in projects I've worked on. It's always a pragmatic evaluation. Right now, I'm working on a project which, pending legal review, should be AGPL. Any other license would be business suicide. AGPL gets us the ecosystem we'll need, without having to unfairly compete with our own code.

View on HN

You write this as if it summarizes the discussion, but of course the discussion we can all read here says the opposite: Google's legal concerns are probably not false, and are concerns for multiple other organizations; not only that, but Google has ample reason to be particularly concerned about these kinds of IP issues.

I think it's possible have "Google has concerns about the AGPL for itself" and "Google would like you to not use the AGPL by making you afraid of it".

The first statement is almost certainly true. The second is supposition.

Possibly, but I think it is fairly clear how it would help Google to do the second. (To be explicit: I'm not saying they are doing this. But there are others here arguing that this is just not something they could be doing, which is absurd.)

You're describing supposition. That's fine! It's fine if we just agree.

Maybe I'm misunderstanding. It sounds like you agree that companies with proprietary code can't link GPL libraries, and Google's statements don't suggest any problem for companies which don't care about keeping their code proprietary.

Google's interpretation implies their belief that if their PostgreSQL server uses AGPL code, then every service using that PostgreSQL server must also be AGPL.

The article points out that that is not the case.

If you are using AGPL code as a library, however, then your application as a whole must be under an AGPL-compatible license. It's just that connecting to a server does not constitute linking in the GPL, and the AGPL doesn't change that.

I don't think that's a fair interpretation of what Google said. Their reference to "accessed over a remote network" is about triggering the virality provisions in the first place, since the AGPL doesn't require you to distribute anything if you're just running a program by yourself without sharing it.

The article points out that Drew believes it isn't the case. Until this stuff is tested in court, there isn't a lawyer worth the name who would guarantee that. The language isn't precise enough to be 100% sure how courts will interpret it, and the downside risk is monumentally huge for a company like Google if the ruling goes against them.

> downside risk is monumentally huge for a company like Google if the ruling goes against them

The downside risk is damages. Those usually aren't monumentally huge. There's a calculation, but they're based on how much damage was done:

1) How much did Google profit from the code?

2) How much did the other party lose?

3) Are statutory damages greater?

Pick the highest of the three. If it's intentional -- and in this case it isn't -- you triple it. You might toss in legal fees.

#1 is the relative cost to going with an alternative solution (build in-house, license, etc.). #2 is usually zero for AGPL code. #3 is pocket change for Google. So you're likely to go with the cost of not having gone with AGPL in the first place, twice (once in damages, and once for the migration).

Plus the cost of rewriting the project with a different dependency.

> It sounds like you agree that companies with proprietary code can't link GPL libraries

No. This is incorrect. One cannot create derivative works with AGPL code. Linking does not necessarily create a derivative work. Whether or not it does depends on the specific case, and the degree to which the code intertwines. If I have an AGPL back-end and a proprietary front-end for an online photoeditor, that's probably a problem. If I have an AGPL database and a proprietary web app using it, that's generally not a problem.

Even in the photoeditor case, it only becomes a problem at distribution. For an internal tool, AGPL+proprietary is often okay (depending on who the internal team is). AGPL means a consumer-facing web app becomes a problem.

There is a sensible decision path for avoiding linking, but it has nothing to do with this. The arguments are:

1) Engineers aren't lawyers. For a big company, it's easier to have a hard rule (no AGPL) than to train engineers to be lawyers. For small companies, more nuance is okay.

2) AGPL is as much a legal mechanism as a social signaling mechanism. If I'm using a tool not the way the authors intended for me to use -- in an open ecosystem -- that creates its own problems.

Reply on news.ycombinator.com