Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The terms of the AGPL are pretty easy to comply with

drewdevault.com

Post reply on HN
Print view View original

91–100 of 341 posts

Re: The terms of the AGPL are pretty easy to comply with

#91

Post by api »

xyzzy_plugh wrote: post #12

> Obligatory: I’m not a lawyer; this is for informational purposes only. and > Google states that if, for example, Google Maps used PostGIS as its data store, and PostGIS used the AGPL, Google would be required to release the Google Maps code. This is not true. They would be required to release their PostGIS patches in this situation. AGPL does not extend the GPL in that it makes the Internet count as a form of linki…

I've seen the same phobia to a lesser degree around the plain old GPL. Lawyers think, and not unreasonably, in terms of risk. Is there a risk you might be dragged into court? If so, that's a very expensive risk. Is the library or application worth this risk? If not, then ditch it.

It's not an unreasonable fear either given past events like the SCO/Linux lawsuit. IBM had deep enough pockets to fight it and win. Anyone else would have folded or been ruined.

It makes it hard to be anything but 100% "libre" (almost public domain) or commercial and closed source.

Being 100% libre means someone big can (and sometimes does) just take your work and put their name on it and monetize it. This wasn't much of a problem years ago, but it's a growing issue now. Being 100% commercial is of course the opposite. We're excluding the middle, to great detriment, and we really need a workable legal solution that won't scare lawyers.

Re: The terms of the AGPL are pretty easy to comply with

#92

Post by SpicyLemonZest »

woofie11 wrote: post #43
marcinzm wrote: post #17

> Google states that if, for example, Google Maps used PostGIS as its data store, and PostGIS used the AGPL, Google would be required to release the Google Maps code. This is not true. They would be required to release their PostGIS patches in this situation. AGPL does not extend the GPL in that it makes the Internet count as a form of linking which creates a derivative work, as Google implies, but rather that it mak…

Eben Moglen wrote the AGPL. There's a standard process courts use to figure this stuff out. Intent fits into it. Eben Moglen clearly states what he meant in many talks. Courts favor intended interpretation of a contract. That makes the risk pretty small.

I don't think this really supports your point? Eben Moglen has indeed clearly stated what he meant; he thinks free software ideals are very important and tried to write GPL-family licenses so that developers would be compelled to respect them.

Re: The terms of the AGPL are pretty easy to comply with

#93

Post by saagarjha »

brutt wrote: post #50
rydre wrote: post #44

Earlier quoted context omitted.

> Linux It's called OpenBSD.

MacOS uses BSD code for free. Apple, most profitable company in the world, contributes nothing back. Sad story.

Nit: Apple open sources the majority of their BSD modifications, it's just that nobody upstream wants them apart from the few ex-Apple employees who try macOS bits out in those OSes for fun.

Re: The terms of the AGPL are pretty easy to comply with

#94

Post by sstangl »

SpicyLemonZest wrote: post #65
woofie11 wrote: post #56

Earlier quoted context omitted.

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 f…

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.

Re: The terms of the AGPL are pretty easy to comply with

#95

Post by jeffbee »

saagarjha wrote: post #89
jeffbee wrote: post #83

Earlier quoted context omitted.

The AGPL virality is considered such a big risk, and the "scripts to control" clause is considered so sweeping and vague, that Google has its own internal version of R that won't download AGPL libraries from CRAN, because just looking looking at the performance stats from production services in R using an AGPL library could taint the source code of the service itself. Nobody knows.

> because just looking looking at the performance stats from production services in R using an AGPL library could taint the source code of the service itself I think this is what is being referred to as "FUD". Anyone can go after you for some sort of supposed license issue, but at some point you need to consider that many of these are extremely far-fetched and serve only to quite literally add FUD around AGPL.

It meets the literal definition for each of fear, uncertainty, and doubt. That is true. But the uncertainty is the point. Why risk something as valuable as Google's proprietary source code over something with as little utility as some random CRAN package?

Re: The terms of the AGPL are pretty easy to comply with

#96

Post by cic48 »

saagarjha wrote: post #89
jeffbee wrote: post #83

Earlier quoted context omitted.

The AGPL virality is considered such a big risk, and the "scripts to control" clause is considered so sweeping and vague, that Google has its own internal version of R that won't download AGPL libraries from CRAN, because just looking looking at the performance stats from production services in R using an AGPL library could taint the source code of the service itself. Nobody knows.

> because just looking looking at the performance stats from production services in R using an AGPL library could taint the source code of the service itself I think this is what is being referred to as "FUD". Anyone can go after you for some sort of supposed license issue, but at some point you need to consider that many of these are extremely far-fetched and serve only to quite literally add FUD around AGPL.

The error is using a pejorative term of FUD to identify uncertainties that are routine in every legal review ever performed. What you’re saying is you have a different risk assessment for your business and you’d take the advice and proceed anyway. That’s your prerogative. That does not extend to “different assessments from my own are objectively wrong,” which is what calling them FUD implies.

Engineers seek hard truth, which is why the malleable truth of contract and license law is ever elusive. They’re different takes on truth.

Re: The terms of the AGPL are pretty easy to comply with

#97

Post by saagarjha »

rydre wrote: post #64
brutt wrote: post #50

Earlier quoted context omitted.

MacOS uses BSD code for free. Apple, most profitable company in the world, contributes nothing back. Sad story.

Yeah so? Apple should be punished for many other things like abusing dominance to get advantage in other industries, not this entitled "contributes nothing back". It's not Apple's problem that the software was really free. If it were not free, Apple could have gone the windows route and make their own everything. Would not be hard since they control hardware. Nothing sad here. Just the entitlement of people who do no…

Yes, Linux, the OS that powers the majority of the web, the OS that runs the backend for even the most GPL-allergic companies like Apple, the OS that is present in over a billion shipping Android devices today? That Linux?

The reason people don't know about Linux is because it's lacking in consumer-facing design and because much of its use is largely invisible, not because it's GPL.

Re: The terms of the AGPL are pretty easy to comply with

#98

Post by pedrocr »

jeffbee wrote: post #95
saagarjha wrote: post #89

Earlier quoted context omitted.

> because just looking looking at the performance stats from production services in R using an AGPL library could taint the source code of the service itself I think this is what is being referred to as "FUD". Anyone can go after you for some sort of supposed license issue, but at some point you need to consider that many of these are extremely far-fetched and serve only to quite literally add FUD around AGPL.

It meets the literal definition for each of fear, uncertainty, and doubt. That is true. But the uncertainty is the point. Why risk something as valuable as Google's proprietary source code over something with as little utility as some random CRAN package?

The definition of FUD is that you are spreading fear, uncertainty and doubt as a tactic not that you yourself are afraid, uncertain or have any doubts.

Re: The terms of the AGPL are pretty easy to comply with

#99

Post by JoshTriplett »

apetresc wrote: post #14
lxe wrote: post #5

> Any derivative works of AGPL-licensed software must also use the AGPL. TBH, I'm interpreting this statement just like Google is: > Google states that if, for example, Google Maps used PostGIS as its data store, and PostGIS used the AGPL, Google would be required to release the Google Maps code. What's the definition of 'derivative work' here?

A derivative work of PostGIS would be a fork or patches to PostGIS (i.e, a set database extensions for geographic/spatial queries). A mapping application that used PostGIS is not a derivative work of PostGIS, in the same way that a C program linked against glibc is not a derivative work of glibc. At least, that's my layperson's understanding of it.

You're conflating "talking to a server over a socket" with "linking to a library".

The former, as a general rule, does not create a derivative work. It's specifically called out in the GPL FAQ as something that does not create a derivative work. (Another case that doesn't is fork/exec of a separate program.)

The latter, linking a library, is why the distinction between the GPL and LGPL exists. As a general rule, if you link to a GPLed library, you do need to provide your source under a GPL-compatible license. (glibc is LGPLed.)

But people wouldn't use PostGIS by linking to a library, they'd use it by talking to a server.

Re: The terms of the AGPL are pretty easy to comply with

#100

Post by SpicyLemonZest »

sstangl wrote: post #94
SpicyLemonZest wrote: post #65

Earlier quoted context omitted.

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…

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.
Post reply on HN