Live data from Hacker News

The terms of the AGPL are pretty easy to comply with

drewdevault.com

131–140 of 341 posts

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

#131

Earlier quoted context omitted.

> a basic reading of the AGPL text readily and clearly confirms this fact. Not trying to be rude, but are you a lawyer? To interpret such a license with potentially huge legal ramifications, I would rather listen to lawyers than laypeople.

Then listen to Eben Moglen, who wrote it, and is a brilliant law professor at Columbia :)

Or listen to Daniel Berlin, who's both an accomplished GCC hacker and a lawyer:

https://news.ycombinator.com/item?id=9956542 https://news.ycombinator.com/item?id=13979443

This isn't settled law, and DannyBee would be quick to point out that the practice of law has a major component of risk management.

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

#132
post #33

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

Corresponding source has the exact same definition in GPLv3 and almost exactly the same in GPLv2, so all this "its completely untested" thing is completely disingenuous. Google uses Borg to control gplv3 code that they also distribute, so, exactly the same case and its complete BS you are spreading. Lawyers are actually pretty good at spreading FUD about GPL, they always have been.

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

#133
post #69
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.

Google is in the position to just use non-AGPL alternatives or build their own. That an open source library exists doesn't obligate Google to use it.

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

#134
I release my software under AGPL whenever possible—even if it couldn't conceivably be used to provide services over a network—because it means that Googlers aren't allowed to use it on their work machines. If Google ever changes their policy on AGPL, then I'll either switch to the JSON license or a custom one that will arbitrarily exclude companies and people that I don't like.

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

#135
post #67

> Any users of such software are entitled to the source code under the terms of the AGPL, including users accessing it over the network such as with their web browser or via an API or internet protocol That doesn't seem to be quite right. It makes it sound like the source code entitlement applies to all users. The "including users accessing it over the network" is redundant then because they are a subset of all users…

Surely the user source entitlement also applies if I interact with the software without a network in between? Otherwise, that would make AGPL a strangely more-but-also-less permissive license than GPL…

It is almost literally GPLv3 with the interactive remote network source obligation added in.

If you diff GPLv3 and AGPLv3, the differences are (ignoring differences that are just in the name of the license):

1. The preamble has a few differences where they describe why they wrote each license and what ills they are trying to address.

2. In the actual terms and conditions, the first 13 sections and last 4 sections are identical (except for the name of the license). Only section 13 is different.

In AGPLv3, 13 is the section about remote network user source access, and about how AGPLv3 and GPLv3 interact.

In GPLv3, 13 is about how GPLv3 and AGPLv3 interact.

Finally, after the T&Cs is a section on how to apply the license to your programs. That has differences, such as including in the AGPLv3 version a reminder that you have to handle your section 13 obligations for remote network users.

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

#136

Disclaimer - As a CTO of a company I have to take a stance on these issues. As a matter of fact, as you raise money, part of the due diligence is to audit the libraries that you use to make sure that you don't use libraries that can jeopardize the future of the company. Using an AGPL library for a Saas company will be flagged as a risk by lawyers during the due diligence process. At Truework, we love open source and…

It's the same when you go through M&A.

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

#137
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.

The "scripts to control" clause as you say is in all versions of the GPL, exactly the same in GPLv3, and slightly different I presume in GPLv2. It has been tested in court, and its been found to not be expansive like the fud you are spreading.

Can you link to the relevant cases?

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

#138
post #41

Earlier quoted context omitted.

> a basic reading of the AGPL text readily and clearly confirms this fact. But that reading has never been tested in court, so from counsel’s perspective why risk it? No competent lawyer would take the AGPL at prima facie, they’re going to look for case law - and there isn’t any.

Why risk anything? On the grand scale of things, effectively nothing has been tested in court. This is no grounds for making baseless statements about a license which are unsupported by its text.

Case law, also known as judicial decisions made in courtrooms by individual non-technical judges that then become legal precedent followed by all other judges, is a huge thing. If you look back to the founding of the EFF Electronic Frontier Foundation, it's genesis was the realization that an enormous amount of technology-privacy-critical legal precedent was being set in remote courtrooms where poorly equipped attorneys on both sides were arguing in front of uninformed judges who would then set precedent for the entire country.

Most areas of law have enormous amounts of case law precedent. Privacy (originally) and the AGPL (today) are areas where the lack of any prior case law makes the legal risks (as in legal uncertainties) somewhere between much higher and effectively infinite. That isn't the case with most other areas where case law precedent results in far more conventionally bounded risks/uncertainties.

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

#139
post #103

My problem with GPL is that the term "derived" is defined to vague or not in the way I like it, which in turn opens up all kind of legal uncertainty. (I don't know if this also applies for AGPL.) I would love to hear that AGPL legal reliably works like he describes (or there is a different license which does).

None of the V3 licenses say "derived". Derivation is a specific concept in US copyright law, so in fact it doesn't need to be derived in the license. But it also doesn't apply elsewhere. So the V3 licenses use the term "modify", which they define to specifically include the more internationally-understood concept of adaptation. Where things get more complex is in each license's concept of linking. But that's only a p…

GPLv2 does use that wording.

It's still widely used.

AGPL is also originally based on GPLv2.

Through there is the GNU AGPL license which is often abbreviated as AGPLv3 which is based on GPLv3.

GPLv3 makes many things more clear but not necessary better. It also includes some cases I would explicitly not include as "derived work" (or more explicit wok which will need to be GPLv3 compatible as yes the terminology changed).

> But that's only a problem if you want to be a free rider. Like Apple or Google.

No, it's a problem for many other use-cases which have nothing to do with free riding but protection of trade secrets and similar.

If you want to make sure your software is FOSS sure go ahead, but why force all the software directly around it to be FOSS, too?

I mean it makes sense for complete services and similar (like a database or the Linux kernel). But it IMHO is not very good for any kind of library.

In my opinion forceful open source is good for modifications and extensions of a given service (in the very general CS definition of a service which includes most kinds of libraries). But should be avoid to extend to any user of a service independent of the way the service is interacted with (static linkage, dynamic linkage, etc.) with an additional exception wrt. LTO.

Sure you can't sell such software well. But most FOSS software isn't meant to be sold. What is sold are products like support, service and maintenance around it and similar. There are very view companies which had success with a selling software based on a GPL vs. proprietary dual license schema as far as I know. I think, and might as well be wrong about it, that it's better to then have a license like mentioned above but restrict commercial use in some way with the option to pay to lift the restriction.

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

#140

"The Google page about the AGPL details inaccurate (but common1) misconceptions about the obligations of the AGPL that don’t follow from the text." "The reason they spread these misconceptions is straightforward: they want to discourage people from using the AGPL, because they cannot productize such software effectively." "Ask yourself: why is documentation of internal-facing decisions like what software licenses to…

I don't know exactly what the author of this post means, but it doesn't have be a "conscious" decision on the part of Google to spread misleading information for their own benefit. It's very easy (I contend) for humans to believe things that are poorly supported by the evidence but which are beneficial for them.

So even if it's obvious that the AGPL doesn't have the effects that Google's policy suggests it does, it doesn't require active deception on the part of Google for them to believe it does. It just requires that they be deluding themselves for their own benefit - which I think is a very common practice for humans.

Post reply on HN