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

81–90 of 341 posts

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

#81

Post by dathinab »

p0llard wrote: post #66
woofie11 wrote: post #13

Earlier quoted context omitted.

Eben Moglen talks about this at length (author of the license). The rough lines are drawn as per how closely the works couple and interdepend on each other. For example, if I build an extension which works with Chrome and Firefox, over a well-defined API, that's an independent work. AGPL/GPL/LGPL does not apply. If I have two pieces of code which mutually rely on each other and form a common system, and for example c…

> For example, if I build an extension which works with Chrome and Firefox, over a well-defined API, that's an independent work. AGPL/GPL/LGPL does not apply. > If I have two pieces of code which mutually rely on each other and form a common system, and for example call back-and-forth, or have APIs specific to each other, that generally does form a derivative work. So why does the LGPL/Linking Exception exist at all?…

Wrt. GPLv2 what counts as derived work is a mess.

LGPL mainly exists because statically linking a library into a binary (especially with link time optimizations enabled) will somewhat modify the binary code of the linked library in the way it is placed in which some lawyers use to argue that static linking is always a derived work.

So LGPL let's you rest in peace if you need static linking.

(I also have read arguments that even dynamic linking is derived work or that it's totally independent of the linking method but on how the linked code is used. All from lawyers, through not all from US lawyers. Also that was quite a while ago, some curt might have clarified such aspects.)

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

#82

Post by asdgasdg »

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…

>This is the problem: I've fought with IP lawyers we've had on retainer who always boil it down to: "It doesn't matter. We're not going to court to find out."

That's not really an argument, the lawyers are just pulling rank on you.

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

#83

Post by jeffbee »

jcheng wrote: post #58
cic48 wrote: post #33

Earlier quoted context omitted.

I’ve taken AGPL through two FAANG reviews. Both arrived at the same very-much-not-FUD legal conclusion. Paragraph 1 of section 13 requires modifications to be disclosed and source code for them to be offered to remote users. The license uses the term of art Corresponding Source for this. Corresponding Source is defined in section 1 in a crystal clear way. Two separate teams of lawyers concluded that they could cohere…

I agree that random engineers should have the humility to listen to feedback from lawyers. And IANAL. Here's the sentence with "scripts to control": > The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. That being said, it feels like a str…

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.

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

#84

Post by dathinab »

opus132 wrote: post #18
apetresc wrote: post #14

Earlier quoted context omitted.

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.

> in the same way that a C program linked against glibc is not a derivative work of glibc I believe this is only as a result of the linking exception; I don't know if this has ever been tested, but my understanding was that linking (either statically or dynamically) against a library was generally considered enough to be a derivative work.

My last heads up a fiew years ago was:

Legally people can't decide which form of linkage count as deriving and if the linkage form even matter, but static linking with LTO is most times seen as causing a derivative to be produced.

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

#85

Post by saagarjha »

dvt wrote: post #78
saagarjha wrote: post #15

Earlier quoted context omitted.

> Legally, you don't want to deal with the burden of constantly checking if you're complying with some license that a dependency of a dependency of a dependency is using. If you're not modifying that dependency, you don't need to do anything since your dependencies are handling it. Especially with GPL, since it's likely that your dependency's dependency will make it GPL as well–but you should be doing this anyways, o…

> Then you're just not in agreement with how GPL works. It's meant to be an explicit guard against people taking projects, forking them, and never contributing back. I'm definitely not in agreement with it, I just don't like that it tries to present itself as some kind of purist "free software" license, but in reality it mandates how code can be released. How is that free? To take a page out of the blog post, it sure…

GPL is about freedom for software users, not for software authors. It places restrictions on what software authors can do in order to give users more privileges. (Which I personally believe is the right trade-off, as users are usually in lesser-privileged positions to begin with.)

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

#86

Post by cic48 »

pydry wrote: post #69
cic48 wrote: post #33

Earlier quoted context omitted.

I’ve taken AGPL through two FAANG reviews. Both arrived at the same very-much-not-FUD legal conclusion. Paragraph 1 of section 13 requires modifications to be disclosed and source code for them to be offered to remote users. The license uses the term of art Corresponding Source for this. Corresponding Source is defined in section 1 in a crystal clear way. Two separate teams of lawyers concluded that they could cohere…

The holy war could be avoided if Google simply paid authors of AGPL code they wanted to use instead of going on a tirade against the license. I think half the reason it exists is to make it deliberately risky for FAANGs etc. because they're exactly the ones who SHOULD be ponying up to support the open source ecosystem they rely upon.

Free as in beer with the expectation of Venmo, is it?

Joke aside, given Stallman’s writings about large businesses and their practices, characterizing a policy document as a “tirade” is a strange position. They’re not exactly buying airtime to advocate against the license. They’ve chosen to make a policy open access, something we’d normally applaud.

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

#87

Post by dathinab »

p0llard wrote: post #73
rbanffy wrote: post #55

Earlier quoted context omitted.

A program using PostGIS via TCP is no more a derivative work of PostGIS than a program storing data in its underlying database is derived from PostgreSQL. I can't imagine the tortuous logic one would need to arrive at a different conclusion.

> PostGIS via TCP From a legal perspective I'm unaware of any ruling which establishes a difference between components communicating via TCP and components communicating through function calls at the ABI level (e.g. linked libraries); the latter is apparently enough to constitute a derivative work (see the LGPL/Linking Exception). There are obvious technical differences, but it's not clear that they should be treated…

The LGPL linking exception mainly exist because static linking does modify the included binary in the way it links. At least with LTO enabled.

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

#88

Post by hitekker »

The new title is misleading. It is a charitable interpretation of a half-screed/half conspiracy theory.

> The reason they spread these misconceptions is straightforward: they want to discourage people from using the AGPL, because they cannot productize such software effectively.

Statements like this can be encompassed by its original title, as the author intended.

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

#89

Post by saagarjha »

jeffbee wrote: post #83
jcheng wrote: post #58

Earlier quoted context omitted.

I agree that random engineers should have the humility to listen to feedback from lawyers. And IANAL. Here's the sentence with "scripts to control": > The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. That being said, it feels like a str…

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.

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

#90

Post by dvt »

plus wrote: post #32
dvt wrote: post #6

> Any derivative works of AGPL-licensed software must also use the AGPL. That's why people don't use AGPL, and why I personally don't release any code under (A)GPL. If you want to make free software, make free software and release your code under Apache or MIT. And if you really care about attribution, use CC BY 3.0. Legally, you don't want to deal with the burden of constantly checking if you're complying with some…

It sounds like you are arguing against a different point than Drew is making here. He is saying that the AGPL is no more viral than the GPL, and that its added restrictions aren't particularly onerous. You seem to be arguing against the whole GPL family of licenses, which is a perfectly valid opinion to have, but doesn't really speak to what Drew is talking about. > This is true, and I don't see much wrong with it. I…

> It sounds like you are arguing against a different point than Drew is making here. He is saying that the AGPL is no more viral than the GPL, and that its added restrictions aren't particularly onerous. You seem to be arguing against the whole GPL family of licenses, which is a perfectly valid opinion to have, but doesn't really speak to what Drew is talking about.

Maybe I misunderstood his post, but he specifically compares AGPL to MIT in the last paragraph, which actually motivated me to write my reply, as the difference between the two licences is night and day.

Post reply on HN