
The terms of the AGPL are pretty easy to comply with - ssklash
https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html
======
xyzzy_plugh
> 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 linking which creates a derivative
> work, as Google implies, but rather that it makes anyone who uses the the
> software via the Internet entitled to its source code.

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."

Is it FUD? Yes. But I am also not a lawyer, and I can only do so much to fight
upwards as an IC. I've seen this exact mindset at every company I've ever
worked for or with.

The real fear is that once you have an AGPL dependency, it's _possible_ that
it makes it way into something you really don't want to release publicly, and
now you have a huge mess of a problem. The easy solution: don't use software
with that license.

(FWIW I hate this, and fully believe competent developers can not shoot
themselves in the foot so extravagantly, but alas.)

~~~
cic48
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 coherently argue the
Corresponding Source definition implied not only the modified AGPL software,
but also stuff that merely _uses_ it, on the basis that “scripts to control”
among other things implies the infrastructure most shops build around
software, such as Borg configuration and possibly by extension Borg. After
all, a modified version of PostGIS is only useful to run in context, and
Corresponding Source requires the context.

AGPL is unchallenged in court. The risk to being wrong about it as huge. It’s
risk aversion, not ideology, and it’s important to remember that identifying
an argument as part of legal review does not call it the correct one. Anyone
who’s ever worked with legal matters knows there is no such thing as
“correct,” there are rulings. The existence of the argument condemns the
license for FAANG, not its validity. Testing that validity against a claim is
perilous.

Perhaps if random engineers stopped calling legal opinion FUD and falsehoods
and took a moment to listen to the feedback from lawyers who didn’t write the
license, we’d get somewhere with finding a palatable license for all parties.
Instead, we get a holy war.

Strong disagree on developers not shooting themselves in the foot. If it’s on
GitHub, it ships. If you think about licenses in your day to day engineering,
you are the 1%.

~~~
debiandev
> AGPL is unchallenged in court. The risk to being wrong about it as huge.
> It’s risk aversion, not ideology, and it’s important to remember that
> identifying an argument as part of legal review does not call it the correct
> one. Anyone who’s ever worked with legal matters knows there is no such
> thing as “correct,” there are rulings. The existence of the argument
> condemns the license for FAANG, not its validity.

Having worked with lawyers, this largely overstates the risk. Companies are
happy to discuss, modify and sign new contracts every day.

All these contracts are "unchallenged in court", by definition, because they
are entirely custom.

A lot of software licensing contracts for closed source have complex and
restrictive clauses to prevent "renting" such software through SaaS or
weakening limitations using legal loopholes.

Yet companies still sign such contracts.

Another type of custom and complex contract is employment.

Furthermore, companies sue each other every other day over contract violation
around IP, copyright, trademarks, patents but also employment contracts, rent,
building regulations, shipment delays, all of that.

The idea that a FLOSS license is some scary monster is propaganda.

The goal of such propaganda is to drive the FLOSS community to provide
valuable software for free and with zero strings attached - aka free labor.

~~~
tptacek
No, companies are not happy to discuss, modify, and sign new contracts every
day. They are quite hesitant to. At Matasano, it became our practice simply to
tell new clients we'd be happy to sign their paper and not ours, because we'd
lose weeks just to get to the point where their legal would consider looking
at our contracts. At my last company, we non-negotiably used our own
contracts, and budgeted a month to legal review for every signup. New
contracts are a big deal.

And, what's more, the contracts we're talking about are all basically pro-
forma. They're nothing like the AGPL, which has, in reasonable
interpretations, far-reaching impact on IP across the whole company.

~~~
debiandev
> No, companies are not happy to discuss, modify, and sign new contracts every
> day. They are quite hesitant to.

[citation needed]

> And, what's more, the contracts we're talking about are all basically pro-
> forma.

I had very custom employment contracts with 2 well-known large tech companies.
When asking to remove some clauses and add new ones they did not flinch at the
ask and let me have meetings with their lawyers.

I have many other examples but a quick search on the internet can show how
many contract-related discussions happen between large companies, suppliers,
local governments & so on

Matasano is not the size of a FAANG and similar or maybe it has a small legal
team by choice.

~~~
tptacek
The authors of AGPL packages are also not the size of a FAANG! That's the
point! If they were, they wouldn't be negotiating AGPL with Google; they'd be
negotiating an actual contract.

(I have zero problem with AGPL and happily use it myself for things, but I use
it the same way I feel most of my peers use it, as an explicit "no, FAANG, you
can't use this code, pay me instead" marker.)

~~~
cycloptic
>If they were, they wouldn't be negotiating AGPL with Google; they'd be
negotiating an actual contract.

This would stop being true if (and when) FAANG figured out how to effectively
use AGPL internally. In my opinion, this is inevitable as long as software
continues to be published under this license. From their perspective it seems
they don't even have to do anything besides wait for other smaller companies
to get in legal disputes and set a precedent. Or better yet, wait for a
potential acquisition to come along that happens to have won one of these
disputes.

~~~
tptacek
If you're trying to pivot this to a place where I'll concede that AGPL is a
good thing, you're wasting energy, because I already think AGPL is a good
thing. I'm not making this point about contracts because I'm motivated to talk
down AGPL; I'm doing it because, in my experience over the last 15 years, it
has definitely _not_ been the case that companies are comfortable entering
into arbitrary contracts. It's just not true.

~~~
andi999
Precisely. Also the negotiation takes a long time and usually the risk is not
as high as agpl, since these contracts dont have clauses like 'all your ip is
mine'(except one player here known to try to sneak such a clause in every
time).

------
n0n0n4t0r
Hello, While I'm employed to develop an agpl software, and I fond of this
license, it's clear that with the wrong actors it can be a threat to some
businesses.

I'll tell you a little story that happened around 10 years ago:

I got a call from a representative of Oracle, he asked me if we where using
MySQL, and if I could described him how, because he wanted to help us make
Better use of this tool.

We where pretty happy about MySQL at the time, and I went into deep details
about how we used it. At the end, he told me point blank that the PHP's MySQL
driver was licenced under the GPL and that we had to licence our whole
codebase under the GPL since it was contaminating our code as a whole. (Even
if we had encapsulated all the accesses to the driver around a single class)

The alternative was to pay the right to use it under a non GPL contaminating
way.

Oracle then called and threatened us many times.

The argument that made them stop was when we told us that we where hosting the
applications. This argument would not have been sufficient with the agpl.

There claim was unfonded but I can assure you that I didn't sleep well for a
while!

~~~
Andrew_nenakhov
Stories like this are the reason I tell everyone to _never_ touch MySQL and
anything related to Oracle. If you need a relational DB, look no further than
PostgreSQL.

~~~
bob1029
Alternatively, if arbitrary, highly-litigious vendors start probing your
private business activities, politely roll them to voicemail and your spam
folder.

Unless you are already under contract or other legal order to do so, you do
not have to tell anyone anything regarding the nature of your business. Every
piece of information you give to one of those assholes is something that will
be used against you in a lawsuit. Don't make things harder on yourself.

------
victorkab
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 try to contribute when we can, but the
reality is that if a library is AGPL, I'll ask my team to not use it. It's
just not worth it to risk so much for a single library. Yes, it's unlikely
that you will have to go to court because you use that one library, but if you
do... well that's bad news for you.

If you build a business, it's about making sure that there there is a
reasonable ROI for risks that you take. APGL tilts the balance towards "we
shouldn't use this, it's too risky". Make your own decisions, but keep that in
mind.

~~~
marcinzm
And if you rely on large companies as clients they will have a line asking
about GPL/AGPL library use during contracting for similar risk reasons.

------
knorker
> Obligatory: I’m not a lawyer; this is for informational purposes only

That's the main point, though. You aren't, in fact, a lawyer. And this is not,
in fact legal advice. You are presumably expert in a non-legal field, and you
are giving expert opinion on something you are not an expert on.

The GPL is tested. The LGPL less so, but lawyers seem to be more comfortable
with it.

There's the extra complexity that Google compiles its binaries statically.

You're calling Google liars. There's an alternative interpretation of events
where a whole legal department, with great lawyers, and backed by great
engineers to clarify the technical aspects for the lawyers, come to a
different conclusion than yours.

And you just dismiss that as lies. I don't think that's fair at all. You
wouldn't want a lawyer to come and say "bah, you should just make that
inherently NP problem complete fast for all inputs. How hard could it be? If
you say it's hard then you're lying.".

> this is for informational purposes only

This is pretty arrogant. "I'm not a lawyer, but here are the real legal facts
to ACTUALLY educate you".

You should say it's "for speculation purposes only", or "for entertainment
purposes only".

> Don’t be afraid to use the AGPL, and don’t be afraid to use software which
> uses the AGPL.

This is ignoring one big problem though. Agree or not, call them liars or not,
but Google _and it 's employees_ will NOT touch your software. Not only will
you not get Google as users (though if you dual-license yes in fact Google
DOES buy software, if they can buy it as non-AGPL), you will not get Google
employees as _contributors_.

~~~
saagarjha
> You're calling Google liars. There's an alternative interpretation of events
> where a whole legal department, with great lawyers, and backed by great
> engineers to clarify the technical aspects for the lawyers, come to a
> different conclusion than yours.

Google claims that they care about your privacy. Entire teams of engineers and
lawyers will say the same thing. But when you look at it, you can plainly see
that they are probably just saying that because their main business is
collecting data about you. Similarly, Google runs many projects with a closed-
source server-side component, and using the AGPL would not let them do that.
Do you see why it is not surprising they would come to a different conclusion?

~~~
knorker
So your legal interpretation as a lawyer (I assume) is an ad hominem on Google
for unrelated reasons?

~~~
lmm
When you complain about someone calling Google liars, the fact that Google has
a long history of flagrant lying is not an ad hominem but relevant background.

~~~
knorker
Background yes, argument no.

------
woofie11
Awesome article! I was in an organization which had an AGPL ban. After a
couple of months with lawyers, it's now a major AGPL supporter. AGPL lets you
build ecosystems around your software, where everyone contributes, and no one
can parasitically compete with you. It's absolutely the right tool for a lot
of uses.

I'm no longer with the organization, but it had:

* Hundreds of open-source contributors

* Millions of users, mostly paying

* Zero direct competitors using the software. With equal ground for technology, it'd be almost impossible to overcome first-mover and branding advantage unless the organization really messed up

* Hundreds of major open source users doing interesting things with the software and using it in non-competing contexts. That translated into product enhancements.

With GPL or BSD, it almost certainly would have played out as lots of
competitors doing an extend-and-proprietize, and instead of a successful open
company, it would have been a dead organization.

So many misconceptions abound.

The flip side, though, isn't that everyone should use the AGPL. You should
have the right license for the right context.

~~~
oefrha
I find this comment puzzling. You're arguing from an IP owner's perspective.
Whether you support using AGPL for your own software is completely orthogonal
to whether you should use someone else's AGPL code in your proprietary product
(assuming being proprietary is a done decision).

(Btw, one can argue that you have a vested interest in strengthening AGPL so
that other companies would more readily choose your AGPL software and then be
locked in to your ecosystem, so you're knowingly minimizing the associated
risks on this thread.

You see what I did there? Yeah, attack on your integrity based on
speculations, exactly like TFA.)

~~~
cycloptic
The simple solution there is to not make a proprietary product to begin with.
Sorry, not trying to be snarky, but that (among other things) is the price you
pay for that decision. It's baffling to me how some companies are so resistant
to having to conduct legal reviews to use open source, which in a lot of cases
will directly make them money, but at the same time these companies will
gladly wave a giant NDA at someone just to start a negotiation.

~~~
kube-system
It's not always a choice. There are people who cannot open source their
software due to other legal, organizational, or practical factors.

~~~
cycloptic
That is still a choice. It may just be that your boss is ignoring your input
and making the choice for you, which is a different problem.

~~~
kube-system
No, there are plenty of circumstances where there laws and/or contractual
obligations other than software licenses become involved in software
development which can conflict. See healthcare, government, finance, regulated
industries, etc.

~~~
woofie11
I've worked in several of those industries. Oddly enough, open source was
always easier there. I'd challenge you to find a regulation which prevents
open source in any of those industries.

I think the one exception -- and this was an extreme example -- was the
firmware of a medical device which could endanger human lives if modified.
Things were locked down.

But generically? I'm batting maybe 75% with open source in highly-regulated
industries.

~~~
kube-system
ITAR? Any contract work under an NDA? Sensitive government work? Any code that
implements trade secrets? Any custom enterprise software with hard-coded
exceptions for controlled data?

You can certainly _use_ open source in regulated industries -- the question
is, can they risk the legal possibility of being forced to open source _the
rest of their stack_ if the a court determines AGPL requires it.

~~~
woofie11
I'm not saying everything done is open source. I'm saying it's less common in
regulated industries.

NDA / sensitive government work -> FOIA makes restrictions tough. I can
request government source code.

Trade secrets -> The government can't really keep trade secrets. I guess if I
were working with classified code?

Hard-coded exceptions -> Not specific to regulated industries but bad design.

Legal possibility -> This is not a legal possibility. A legal possibility is
paying damages. It's the same if I break a proprietary license too (for
example, accidentally ship out a copy of a library I paid for just one license
with my product).

~~~
kube-system
FOIA has a substantial list of exemptions, and many of them would apply to a
lot of code that the government uses.

Above, I was referring to trade secrets in the private sector, but actually,
that is one of the FOIA exemptions too.

Also, a lot of code running in production is poorly designed. I'd bet the vast
majority of it is poorly designed.

Damages are one part of it, but you also have to return to compliance, which
means you either have to follow the license or stop using the code. Given that
the AGPL doesn't have linking exceptions, the concern is that might be _all_
of an organization's code.

That's not to say that you can't use open source in industries where these
might be concerns -- almost all other common open source licenses _don 't_
have this problem.

------
sokoloff
I have significant responsibility for setting open-source policy at my
company. We require specific review on a facts-and-circumstances basis of any
AGPL usage.

Why? Because for most open-source licenses, it's clear how to avoid any
license controversy entirely by simply never conveying the licensed work. If I
don't ship you ("convey to you") any binaries, I have no obligations to you
under GPL (or MIT or Apache, obviously). For the most part, we don't ship
anyone outside the company binaries, so compliance (both in fact and in
provability of that fact) is relatively easy. Not so with AGPL.

If there was critically useful code only licensed under AGPL, we'd consider
it, of course. But it would get a lot more review than a typical
Apache/MIT/GPL license situation. I have no philosophical objection to AGPL; I
just find it a much less practical license than most of the other, much more
commonly used, licenses.

~~~
woofie11
It's neither more nor less practical in general. It's less practical for your
company.

It depends on what you're trying to accomplish. If your goal is to build a
low-friction library for others to adopt (e.g. JQuery), it's a horrible,
horrible license. If you're trying to build an ecosystem around an end-user
tool (e.g. I'm making a web-based competitor to Adobe Illustrator), it can be
an awesome license. Lots of open source tools aren't intended to be integrated
into other systems, but used stand-alone. That's where licenses like the AGPL
really shine.

------
DannyBee
I haven't commented on HN in a while, but this article actually pretty much
complains about me, since I wrote the text in question and enabled the policy
to be released.

So i'm just going to say:

1\. The author claims the Google states something, then doesn't actually quote
anything google stated, but instead writes their own interpretation of the
words and a made up example. That's not a good start.

2\. Having set up their own example, the author then proceeds to say it's
wrong because of an appeal to authority, asserting no reasonable disagreement
is possible - when not only is it possible, but large numbers of IP lawyers
disagree on what the AGPL requires. It's true that someone wrote it, and there
are FAQ's, but depending when and where, their opinion on what it means is not
as relevant as one might think.

In truth, lots of people disagree over interpretation of the AGPL - many more
than disagree about GPL interpretation or LGPL interpretation (which are
fairly settled at this point). Searches over any legal licensing list in
existence will you this.

When I wrote the interpretation you see here, it was the best available info
at the time, guided not just by own views, but by listening to a lot of smart
lawyers, counterparts at other companies, etc.

Even if you ignore all the lawyers and whatever as useless, the author has the
huge problem that _There are people who make AGPL software that take the view
listed in the google policy_

So it's not just Google or lawyers, it's _software authors_. Not just a few,
either.

While companies are generally happy to ignore one or two people whose
interpretation is outside the norm (and just not use their software), that's
much harder when there is such widespread difference in view of the AGPL.

3\. For no particular reason at all, the author then decides to assert a
tremendous amount of bad faith in interpretation of the AGPL and reasons for
publishing such policies.

We published our policies because over the years I (and others) were
repeatedly asked by counterparts at other companies, various communities, and
others to understand what our policies look like, for a variety of reasons (to
understand for themselves, to use as a template, etc)

Period. That's the whole reason. It even says this:
[https://opensource.google/docs/](https://opensource.google/docs/)

The author here has decided that's clearly all lies or deliberate
misinformation, without even bothering to even ask anybody.

~~~
jkaplowitz
Thanks for having publiished these policies publicly! You gave a pretty clear
summary of Google's motivations for banning AGPL on HN five and three years
ago two of the previous times this came up, and having worked at Google
2011-2015 (including some interactions there with you), your public
explanations of why from back then are extremely credible and rational given
the logistics of what's easy and hard inside Google.

[https://news.ycombinator.com/item?id=9956542](https://news.ycombinator.com/item?id=9956542)

[https://news.ycombinator.com/item?id=13979443](https://news.ycombinator.com/item?id=13979443)

Not that I'm surprised, as you've always been pretty forthright and honest.
Thanks for continuing to be that way.

~~~
DannyBee
Of course. I appreciate the thoughts. I try my best to be transparent and
straightforward.

I actually do think it's reasonable to expect companies to re-evaluate every
few years (at a minimum) because the world changes. At some point, the
reasoning from X years ago will not make sense anymore.

One of the top rules of sane policy making is to write into the policy the
conditions that should cause you to re-evaluate it, whether it's time, or
change in evidence you relied on, or ...

You want people to understand your rationale and what might change your mind,
otherwise you shouldn't expect them to go along with it.

Even though such a rationale exists in various emails, etc, I actually failed
to do that in the resulting police here, unfortunately (the internal version
is not any better in this respect). That one is on me and I think would be a
more legitimate complaint here.

I don't think it would have changed yet (if anything, the AGPL has become more
contentious as the economy has gone south), but that's just an at-a-glance
view.

------
marcinzm
> 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 makes anyone who uses the the
> software via the Internet entitled to its source code.

Is there an existing national court case which supports this assertion?
Otherwise it's a valid concern given that lawsuits and judges may have
different interpretations than engineers. Just look at the Oracle vs. Google
debacle over Java.

~~~
woofie11
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.

~~~
tzs
In the case of ambiguity in a contract, courts look at the intent of the
parties to the contract. In almost all cases Moglen will not be a party, and
at least one of the actual parties will not be aware of those talks or their
content, so Moglen's talks on the matter won't really be of much use.

Courts will also look at the bargaining power of the parties. If the party
offering the contract is a lot more powerful than the party accepting the
contract, they will tend to favor the accepting party when it comes to
ambiguous terms.

~~~
woofie11
It's a little more complex than that. The intent of the parties /drafting/ the
contract do matter. Public writings clarifying the intent do as well.

~~~
Conan_Kudo
This is probably one of the reasons why the Free Software Foundation has such
an extensive FAQ, because it's the easiest way for them to document their
intent.

~~~
woofie11
Indeed. It's hard to go back and argue a different interpretation later in
court, if the intended interpretation is so clearly stated and defined.

------
jgilias
So. From the POW of a total lay person as far as it comes to law.

Someone writes a blog post with an 'IANAL' disclaimer on top saying that what
Google's army of lawyers have gathered from reading a legal document is false,
and I should favor his interpretation instead. I don't know, I'm not exactly
convinced.

~~~
simion314
>Someone writes a blog post with an 'IANAL' disclaimer on top saying that what
Google's army of lawyers have gathered from reading a legal document is false,
and I should favor his interpretation instead. I don't know, I'm not exactly
convinced.

Microsoft with their giant army of lawyers also said GPL is a cancer and they
promoted this idea a lot but today Microsoft "loves" GPL. I think you can
conclude that you should use your own brain to decide and not let a giant
company decide for you, they might have a huge financial interest to promote a
certain narrative. It is clear in this case that Google would prefer their
employees won't work on their free time on AGPL code.

~~~
jgilias
I was not actually talking about the totality of Google's verdict about AGPL.
For some projects in some companies it might just be the right license to use.
Rather, I was talking about the particular example of Google Maps and PostGIS.

Google's army of lawyers say: If PostGIS 'this' => Google Maps must be 'this'.
And the author says, 'no, that's false'. Someone must be wrong here. And if I
had to place a bet on which side is more likely to have gotten it the way a
court of law might interpret it, I'd put my bet on a bunch of people with law
degrees.

~~~
Conan_Kudo
I would be careful about that. People with law degrees _rarely_ provide useful
generic guidance. They're paid _not_ to, and there's a lot of downsides for
them to do so.

Consequently, _always_ treat guidance from folks with law degrees with a
degree of skepticism. Do your own research and ideally get your own person
with a law degree to develop an opinion you can trust.

------
michaelcampbell
Truth or falsehoods aside, the reason one of the places I have worked (large
10's of k's of employees, big legal staff) refused to let us use AGPL is that
it had never been decided in court, and they didn't want to be the ones to
foot that bill.

"No" is pretty cheap, and they were pretty good at it.

~~~
saagarjha
> "No" is pretty cheap

Now, is it really? Paying a team of software engineers to recreate every AGPL
project surely isn't…

~~~
DasIch
Nobody is using every AGPL project and there aren't that many AGPL projects to
begin with.

The problem is not just the risk associated with AGPL, it's also that the
benefit is actually quite small. I think most companies would be a lot more
willing to use AGPL, if there were any compelling projects using it.

------
emptyparadise
Big corporations avoiding AGPL like the plague makes it a much better "don't
be evil" license than any other attempts at making one of those. If anything,
I'd love to see some dual license scheme where a different license is
available only to small developers or non-profits, rather rather than
corporations with bags of cash. I wonder how that can be enforced - perhaps
some sort of a CLA that only gives limited rights to relicense instead of just
handing over the copyright entirely.

And yeah, this goes entirely counter to making profit, but hey, I think we're
privileged enough to afford to try ideas like this.

------
lxe
> 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?

~~~
apetresc
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.

~~~
p0llard
> 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.

~~~
dathinab
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.

------
p0llard
> 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 makes anyone who uses the the
> software via the Internet entitled to its source code.

I don't really follow this.

The fact that the linking exception and the LGPL exist at all is enough to
infer that the FSF/license authors consider linking against or otherwise using
a piece of software as a component of a larger system is enough to make that
larger system a derivative work of the smaller component, thus "tainting" (I
use this work non-disparagingly) it with the copyleft provisions of the
license.

If Google Maps (that is the suite of software running on Google's servers)
uses PostGIS as its data store then it seems that without a judicial ruling on
whether there's a legal difference between interfacing with a software
component by linking against it and interfacing with a software component by
using some other software interface, it's not possible to be so certain that
there isn't an issue here.

------
hyperpape
"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 use being published in a public place?"

To be perfectly clear, your claim is:

\- Google internally knows they can comply with the AGPL without trouble

\- Has consciously chosen to write policies prohibiting it based on misleading
reasons

\- Google adheres to that policy

\- Most importantly: they are doing this because they believe that the
influence this would have in discouraging use of the AGPL is valuable enough
to substantially benefit Google

Have I understood correctly?

~~~
catern
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.

~~~
hyperpape
This is a good point. My two thoughts are:

1\. I don't find it easy to read the original post as implying Google is
honestly convinced of its viewpoint.

2\. It's a huge difference in meaning. Assume for the sake of argument that
Drew is right about the interpretation of AGPL.

How should we interpret Google's actions? If they're paranoid, and afraid that
the AGPL might require them to open-source their entire code base, that's
unfortunate. You might still call them greedy assholes making open source
worse, but it is a real fear that most commercial entities would be concerned
about if it's realistic.

But if they knew better, and were lying, that's a completely different level
of shitty behavior. If there's any ambiguity about that in Drew's post, it
ought to be resolved.

------
alex_young
Companies like MongoDB release a 'free' version using AGPL and a commercial
version under no such provision, and use this in marketing material to
convince commercial users to buy licensing so they can incorporate their DB
into web based products.

If this distinction is without merit for those simply using MongoDB as an
unmodified DB, this seems like it wouldn't actually work so well as a sales
tool.

~~~
mr_toad
Current versions of MongoDB are not available under an AGPL at all. It is
effectively no longer open source.

Older, (unpatched) versions are still AGPL, but there were no commercial
restrictions at that stage.

~~~
xtracto
The current free license has this interesting snippet:

13\. Offering the Program as a Service. If you make the functionality of the
Program or a modified version available to third parties as a service, you
must make the Service Source Code available via network download to everyone
at no charge, under the terms of this License. Making the functionality of the
Program or modified version available to third parties as a service includes,
without limitation, enabling third parties to interact with the functionality
of the Program or modified version remotely through a computer network,
offering a service the value of which entirely or primarily derives from the
value of the Program or modified version, or offering a service that
accomplishes for users the primary purpose of the Program or modified version.

“Service Source Code” means the Corresponding Source for the Program or the
modified version, and the Corresponding Source for all programs that you use
to make the Program or modified version available as a service, including,
without limitation, management software, user interfaces, application program
interfaces, automation software, monitoring software, backup software, storage
software and hosting software, all such that a user could run an instance of
the service using the Service Source Code you make available.

I know a bunch of startups using Mongo... i wonder if i could make them give
me their systems source, given this clause.

------
jsnell
> 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.

I can’t see that statement, or anything like it, in the linked article. Am I
missing something?

~~~
Doctor_Fegg
You're not. The author writes "Google states" and then follows it with his own
example/interpretation of Google's policy. That's really not "Google states"
at all, it's "My example of Google's policy is...".

The nearest statement in TFA is the sentence beginning "Because Google’s core
products are services that users interact with over a remote network interface
(Search, Gmail, Maps, YouTube)...".

------
ThePhysicist
After much consideration we finally released our core software
([https://github.com/kiprotect/kiprotect](https://github.com/kiprotect/kiprotect)
\- a privacy & security engineering toolkit) under the AGPL. In the past we've
released other software under more permissive licenses like the BSD-3 or MIT
licenses, but we've decidedly picked the AGPL for our toolkit, for the
following reasons:

\- We want to encourage people and organizations to use the software as a data
processing & protection tool, just like they use other Linux/Unix tools.

\- Using the software does not require integrating it into a software project
as a library (though you can do that).

\- We want to ensure that any extensions and modifications of the software
(e.g. new anonymization or pseudonymization methods that people would
implement) will make it back into the main software as open-source, so that
everyone can benefit from them.

\- We want to keep potential competitors from being able to just resell our
software as a SaaS offering or integrate it into a commercial, closed-source
product.

For me, the AGPL fits this bill quite nicely, and that it deters organizations
to use the software for free in their closed-source projects is actually a
bonus. We offer dual-licensing by the way, so organizations can just buy a
commercial license if they want to integrate our tool into their closed-source
software. That at least should allow us to refuse such a license to a
potential competitor and the funding we (hopefully) will generate via the
commercial licenses will help us fund the development for everyone. Win win.

~~~
CodesInChaos
> \- We want to ensure that any extensions and modifications of the software
> (will make it back into the main software as open-source, so that everyone
> can benefit from them.

isn't that a contradiction with

> We offer dual-licensing by the way

since dual licensing requires every contributor to agree to a CLA and not
merely contributing the code under the terms of the AGPL?

~~~
ThePhysicist
Maybe, but I don't think so. In general we plan to have every contributor sign
a CLA as we want to make sure we can keep control over the development of the
project, in case we will have to change its license later.

Some companies don't want to contribute back to open-source software and
that's fine, if they pay a license fee instead we can use that money to pay
ourselves and build new features for the open-source version, so everyone
benefits. I'd even say that maybe open-source software is licensed too
liberally these days. Right now for-profit companies make boatloads of money
on the back of open-source software, without giving back much. I think if more
projects were to use contagious licenses like the (A)GPL it might actually
benefit the whole open-source ecosystem. Imagine what we could build if just
1-5 % of the largest companies would pay a small license fees for the open-
source libraries they use.

------
aazaa
The author makes the following claims:

> In truth, the terms of the AGPL are pretty easy to comply with. The basic
> obligations of the AGPL which set it apart from other licenses are as
> follows:

> \- Any derivative works of AGPL-licensed software must also use the AGPL.

> \- 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 first claim is debatable at best. Nowhere in the entire document will you
find the term "derivative work." Instead, the AGPL forces on the reader a
bunch of other terms that may or may not add up to "derivative works."

Other licenses have no problem coming out and using the term. Doing so
connects _those_ licenses to a well-understood body of intellectual property
law. Not so with AGPL. See the discussion in the book by Rosen (an actual
lawyer) for more [1].

So right out of the gate, the AGPL is not easy to comply with.

[1]
[https://www.rosenlaw.com/oslbook.htm](https://www.rosenlaw.com/oslbook.htm)

------
wwarner
Sorry, this isn't really the case. The AGPL can be used in a predatory
fashion. Projects that are AGPL'd are often dual licensed, with a commercial
license for commercial applications and AGPL for experiments. I once
negotiated for a couple of weeks to pay for an open source package that was
dual licensed under the AGPL. I wanted to make small modifications to the
source. The commercial terms were available on request, and I requested and
got sort of tangential answers until finally the company's lawyer told me that
I'd be liable for 15% of all revenue connected to the library in any way. If I
had used the library first and asked for the terms later, I could have been in
a very serious situation.

------
mark_l_watson
I think that the AGPL is a fine language in cases where the code being
released is a complete system, that you want many people/organizations to use
and improve it, but you don't want anyone cloning it as their own standalone
product.

I understand why Google would not want to use it, and also other large
companies.

For individuals and smaller companies I think the AGPL can make good sense,
especially for complete web applications.

~~~
knorker
> I think that the AGPL is a fine language in cases where the code being
> released is a complete system, that you want many people/organizations to
> use and improve it, but you don't want anyone cloning it as their own
> standalone product.

Yup. In the same way that you could have a license that requires people to
publicly criticize <Politician> to use your software.

You'll get some. But most will just not agree to your terms.

------
labster
It reminds me of the story I heard around a campfire once, about a programmer
who decided to fix a bug in a single AGPL module, and they were forced to make
their entire code open source. Even today, long after the bankruptcy, they say
you can still hear the screams in the shuttered, decaying boardroom. And the
bug somehow got unfixed. It’s out there now, waiting ... for its next victim.

~~~
exhilaration
Is this a story lawyers tell around the campfire to scare new law school
grads?

~~~
labster
Not quite. That version ends with the line: “and their lawyers ... never got
paid.”

------
q3k
Yeah, making some of my recent projects AGPL truly scares away contributions
from Googlers (as their internal, low friction patching process doesn't apply
to AGPL software, and they have to go through explicit approval). Fun.

------
amadeuspagel
> Ask yourself: why is documentation of internal-facing decisions like what
> software licenses to use being published in a public place? The answer is
> straightforward: to influence the public. This is propaganda.

Or maybe it's just something that many people have asked about? And why
wouldn't they publish it?

~~~
jeffbee
The blogger is reading _way_ too much into the existence of this page. The
site is clearly just a wholesale export of internal Google documentation. It
is not generally intended for the public audience and I don't think you can
read intent into specific pages being here. Look at this page for example.
Nothing on it is relevant to you outside Google. You can't reach "go/" pages,
you can't check out //third_party from their repo, etc.

[https://opensource.google/docs/thirdparty/r/](https://opensource.google/docs/thirdparty/r/)

------
Andrew_nenakhov
Yeah. People often resort to some fear-mongering when it comes to AGPL. When
we released our software under AGPL, one developer of a somewhat competing app
didn't find anything better but to claim that 'AGPL license makes it a useless
toy'. Well, we don't agree.

------
kelnos
Agree that some of the examples cited are misrepresentations of what the AGPL
requires, but I think, for many companies, just the requirement to publish
changes (if any) would be a showstopper. Which is unfortunate, but I think is
the reality of the situation.

------
SpicyLemonZest
I think the author is misreading Google's policy
([https://opensource.google/docs/using/agpl-
policy/](https://opensource.google/docs/using/agpl-policy/)). They're not
saying that communications over the internet constitute a linkage, they're
saying that:

* Because of free and open development practices within Google, it's impractical for developers to be constantly aware of what libraries get linked into their binaries. (This is exacerbated because of their monorepo, but even in a multi-repo setup it's very easy to end up with random libraries in your dependency chain.)

* If an AGPL library did end up linked, because all Google's services are accessible through a remote network, the virality provisions kick in and they might have a legal duty to distribute the entire binary.

* Therefore, they have to ban AGPL libraries so that no core service developer accidentally depends on one.

------
dekhn
Back when I was a postdoc I talked to my advisor about GPL and BSD. The
advisor (who was a supremely intelligent person) said the simplest, clearest
possible thing I could imagine: "I wouldn't license software under GPL because
I read the GPL license and couldn't understand what it was saying. I read the
BSD license and it was totally clear. I want to license something using a
license that makes technical sense to me."

The fact that we see pages and pages of hackers arguing over what the
implications of a license family (GPL and AGPL) are based on the legal text
suggests that many people don't understand the GPL.

~~~
GordonS
Yep, this is precisely why I refuse to use GPL or AGPL, but am completely
comfortable with BSD.

If I'm going to be bound by T's and C's, I need to be able to understand the
implications - there is just too much ambiguity and room for bad actors (e.g.
Oracle) with GPL and AGPL.

------
tzs
> 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.

What's actually in the text of the license is:

> Notwithstanding any other provision of this License, if you modify the
> Program, your modified version must prominently offer all users interacting
> with it remotely through a computer network (if your version supports such
> interaction) an opportunity to receive the Corresponding Source of your
> version by providing access to the Corresponding Source from a network
> server at no charge, through some standard or customary means of
> facilitating copying of software.

The user source entitlement only applies to users remotely interacting with
the software through a computer network.

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

~~~
tzs
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.

~~~
saagarjha
Then I guess I am confused by this statement:

> The user source entitlement only applies to users remotely interacting with
> the software through a computer network.

It applies to all users under the GPLv3 as well, is certainly more than just
those interacting with it over a computer network, right?

~~~
tzs
GPLv3 does not have a source entitlement for _users_ of the software. Its
source entitlement is for people the work has been conveyed to. It defines
"convey" thusly:

> To "convey" a work means any kind of propagation that enables other parties
> to make or receive copies. Mere interaction with a user through a computer
> network, with no transfer of a copy, is not conveying

and propagate is:

> To "propagate" a work means to do anything with it that, without permission,
> would make you directly or secondarily liable for infringement under
> applicable copyright law, except executing it on a computer or modifying a
> private copy. Propagation includes copying, distribution (with or without
> modification), making available to the public, and in some countries other
> activities as well

Using software does not necessarily involve conveying the software to the
user.

A good example is given in the GPL FAQ [1]:

> Does GPLv3 require that voters be able to modify the software running in a
> voting machine?

> No. Companies distributing devices that include software under GPLv3 are at
> most required to provide the source and Installation Information for the
> software to people who possess a copy of the object code. The voter who uses
> a voting machine (like any other kiosk) doesn't get possession of it, not
> even temporarily, so the voter also does not get possession of the binary
> software in it.

This is what makes AGPL so different from previous licenses. As far as I know
it is the only free software license that has a source entitlement that
triggers on mere use. The others trigger on distribution or possession of
copies.

[1] [https://www.gnu.org/licenses/gpl-
faq.en.html#v3VotingMachine](https://www.gnu.org/licenses/gpl-
faq.en.html#v3VotingMachine)

------
minieggs
For fans of AGPL I suggest checking out EUPL. Half the length of AGPL.
Changing/removing portions of the license is allowed.

More info: you may have seen this on Hacker News recently:
[https://www.arp242.net/license.html](https://www.arp242.net/license.html).

~~~
saagarjha
> Changing/removing portions of the license is allowed.

Note that licenses that can have random bits changed or removed have the issue
that you need to read them in their entirety each time you encounter them.

------
dathinab
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).

~~~
yarrel
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 problem if you want to be a free rider. Like Apple or Google.

~~~
dathinab
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.

------
e12e
Rather heavily editorialized title? Original says: "The falsehoods of anti-
AGPL propaganda"

------
zzo38computer
I use software with GPL and AGPL, and may even contribute, but when I write my
own software, I make it to be the public domain instead, because I don't like
copyright, and because public domain will make it we don't have to worry about
the license conditions, in case it may be confusing.

I have a program which links with AGPL software. My program is itself public
domain, and is released only as source code, but I would think if anyone
distributes it, or makes it available to access over the network, that they
would have to do so in a way which is not contrary to AGPL. If you know how it
is work, then hopefully you can comment too, to say what parts I did wrong, I
suppose.

------
evmar
I can't comment on the "true" motivation for releasing these documents, but I
noticed the same site includes
[https://opensource.google/docs/thirdparty/oneversion/](https://opensource.google/docs/thirdparty/oneversion/)
which is a very Google-internal-only kind of problem, complete with broken
links to Google-internal-only tools and processes (rosie and lsc). That page
at least is definitely just a dump of the internal documentation.

------
svnpenn
> Network use is distribution

I use the Open Software License for this same reason, I dont think companies
should be able to get the benefit of open source libraries with the cost of
publishing any modifications, regardless if its a webapp or desktop app. I am
curious the difference though:

[https://choosealicense.com/appendix](https://choosealicense.com/appendix)

seems to only be different with regard to trademarks?

------
young_unixer
Even as an individual user, I try to avoid using software licensed under GPL
or its derivatives.

I'm against copyright laws, and any second that I have to spend thinking about
how to comply with them is a second wasted to me.

BSD and MIT make me waste the minimum practically possible amount of time.

I like knowing that I have the freedom to not care about infringing on
anyone's copyright as long as I only develop software using permissive
licenses.

~~~
jkaplowitz
BSD and MIT maximize freedom for developers, which seems to be your primary
concern so that's totally understandable. You're right that they're much
easier for developers to comply with than the GPL family.

GPL and AGPL maximize freedom for both direct and indirect downstream users,
such that users of any software derived from that GPL/AGPL software are
guaranteed strong rights to be able to understand / modify / pay others to
modify their software. BSD/MIT allow proprietary derivatives which withhold
this freedom from users.

Both are pretty valid concerns, even if they're opposed to each other. But for
cases where you're a pure user and not a developer, there's no compliance
hassle involved with either the BSD/MIT family of licenses or the GPL family.

------
enriquto
I love the AGPL, and I love that it is more and more used by larger and larger
projects. For example, the widely used Overleaf. This is a good world.

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

------
dvt
> 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 license that a dependency of
a dependency of a dependency is using.

> By discouraging the use of AGPL in the broader community, Google hopes to
> create a larger set of free- and open-source software that they can take for
> their own needs without any obligations to upstream...

This is true, and I don't see much wrong with it. I don't like the idea of
other code _mandating_ how I should release my code. What if I just don't feel
like _up-streaming_? Free is meant to be _free_ , and (A)GPL _does_ incur a
cost -- at the bare minimum an ideological one.

A lot of reactionary down-voting going on; I'm quite open to debate. Why are
_you_ so passionate about AGPL?

~~~
saagarjha
> 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, of course.

> I don't like the idea of other code mandating how I should release my code.
> What if I just don't feel like up-streaming?

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.

~~~
dvt
> 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 sounds like propaganda to me.

~~~
saagarjha
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.)

------
purpleidea
Great explanation, and I hope people get the message. I've tried to explain
this to people and companies before, but Drew does it better.

Thanks!

------
gridlockd
Why should I listen to the cigarette salesman talking about the harmlessness
of smoking?

------
telamohn
I see a lot of reflections from a business point of view.

I guess if your sole purpose is to conjure money out of thinware then yes,
AGPL is going to be poison to your wallet. Capitalism and AGPL simply does not
mix well.

But we tend to forget, that the end of the day we're all users and have to
consume what we've cooked.

As a user I tend to lean towards AGPL alternatives, It's comfty and let's me
relax my legal muscle after the hard workout of summarizing this thread.

------
pgcj_poster
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.

