AGPL software isn't designed to be used as a dependency to a proprietary system. It's designed to be used in an open ecosystem. That's kind of the point.
* If you expect your code to be used as a dependency to a proprietary system, don't use the AGPL.
* If you are building a stand-alone system, or tools for an open ecosystem, use the AGPL.
That's a question of suitability-to-purpose. Although this use is permitted, AGPL simply isn't a good license for PostGIS (which is correctly licensed under the GPL). It is a great license for end-user applications. It's also nice for dual-licensing.
Licenses aren't something to get ideological about; it's more of a right-tool-for-the-right-job kind of thing. If you use a hammer with screws, you'll get hurt. Same thing with using BSD where AGPL fits, or AGPL where BSD fits.
I agree with what you're saying, but it contradicts the source article, which insists that Google is spreading FUD by saying it can't use AGPL dependencies in its proprietary systems.
* 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.
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.
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.)
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.
> 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.
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.
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).
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.
* If you expect your code to be used as a dependency to a proprietary system, don't use the AGPL.
* If you are building a stand-alone system, or tools for an open ecosystem, use the AGPL.
That's a question of suitability-to-purpose. Although this use is permitted, AGPL simply isn't a good license for PostGIS (which is correctly licensed under the GPL). It is a great license for end-user applications. It's also nice for dual-licensing.
Licenses aren't something to get ideological about; it's more of a right-tool-for-the-right-job kind of thing. If you use a hammer with screws, you'll get hurt. Same thing with using BSD where AGPL fits, or AGPL where BSD fits.