[License-discuss] What's wrong with the AGPL?

[Dirk Riehle]

Thanks, Richard.

On 16.06.24 16:08, Richard Fontana wrote:
> ...
> This alarmist theory of AGPL interpretation never really caught on
> after this brief period, possibly in part because no one wanted to
> contend what I think was implied, that either (1) the scope of
> copyleft under AGPLv3 section 13 was broader than the scope of
> conveying copyleft under *GPLv3, or (2) the scope of copyleft under
> *GPLv3 was generally broader than under GPLv2 (in contrast to what I
> think the FSF itself had said), or (3) the scope of copyleft under
> GPLv2 itself was broader than the commercial world (and community,
> including the FSF itself) had assumed by that time. I wonder if you
> are rediscovering the argument that was being made then.

I'm using the same interpretation as the Linux kernel community uses for 
GPLv2. If your client code use interfaces, your client code gets pulled 
in and becomes covered work. This travels until it hits a natural 
("standard tools" like the filesystem) boundary, when the difference 
between derivative work and collection kicks in. I'm not aware of any 
changes to this fundamental interpretation.

> It helped that AGPL was pretty marginalized from the start, at least
> in comparison to its sibling license GPLv3. In the time frame I'm
> thinking of, I am not sure there was much commercially interesting
> (and technically interesting) AGPL software other than MongoDB. Some

My impression is different: Commercial open source cloud application 
providers jumped on it.

Commercial open source infrastructure component vendors either set-up a 
complex core = AGPL, shims = MIT/Apache structure, or went straight to 
Apache-2.0 only to regret it badly later on.

> Some years later, MongoDB apparently realized that no one was really
> afraid of the AGPL -- actually predictable given the earlier
> trajectory of GPLv2, but for the relatively limited adoption of AGPL
> by communities and corporate projects. So, as I remember it, MongoDB
> published a statement of interpretation of AGPLv3 that suggested that,

I'll go search for it but at least logically that is not the explanation 
I'd have. The complex core = AGPL, client libraries = MIT licensing was 
cumbersome and invited the hyperscalers. Just AGPL, like application 
vendors could do it, would have kept the potential customers away. So 
Mongo was between a rock and hard place and did not have an open source 
based licensing solution to their anti-competition strategy.

Personally, I think there is a solution for the component vendors, but 
it involves triple licensing and maybe that felt even worse

https://dirkriehle.com/2019/07/16/triple-licensing-single-vendor-open-source-components-illustrated/

> I guess the question is, intended by whom? I myself don't believe the
> FSF Intended for AGPL to be interpreted as though it were the
> later-created SSPL. AGPL ought to achieve a network copyleft effect,
> but it's not the copyleft effect implemented in SSPL section 13, which
> violates OSD 9 and the important "mere aggregation" principle in the
> *GPL licenses (which OSD/DFSG 9 is clearly based on). Indeed, I think
> AGPLv3 section 13 has to be read in conjunction with, and is strictly
> limited by, the "aggregate" clause in *GPLv3 section 5.

The SSPL wording goes beyond copyright's derivative and collection 
separation and hence copyleft so I think the rejection was fine. The 
AGPL does not.

So I guess someone who really wants to know needs to risk a lawsuit.

Cheers, Dirk

-- 
Confused about open source?
Get clarity through https://bayave.com/training
--
Website: https://dirkriehle.com - Twitter: @dirkriehle
Ph (DE): +49-157-8153-4150 - Ph (US): +1-650-450-8550