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 _______________________________________________ The opinions expressed in this email are those of the sender and not necessarily those of the Open Source Initiative. Official statements by the Open Source Initiative will be sent from an opensource.org email address. License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
