Graber: LXD now re-licensed and under a CLA [LWN.net]

The story of Canonical's takeover of the LXD container manager, and the subsequent creation of the Incus fork, has been simmering for a while. Now Incus developer Stéphane Graber reports that Canonical has changed the license and contribution terms for LXD:

Per the commit message performing the re-licensing, all further contributions will be under the AGPLv3 license and all contributions from Canonical employees have been re-licensed to AGPLv3.
However, Canonical does not own the copyright on any contribution from non-employees, such as the many changes they have imported from Incus over the past few months. Those therefore remain under the Apache2 license that they were contributed under.
As a result, Canonical cannot release LXD under the AGPLv3 license and likely never will be able to. LXD is now under a weird mix of Apache2 and AGPLv3 with no clear metadata indicating what file or what part of each file is under one license or the other.

He also notes that this change will put an end to the flow of patches — in either direction — between the two projects.

to post comments

Graber: LXD now re-licensed and under a CLA

Posted Dec 13, 2023 3:11 UTC (Wed) by dskoll (subscriber, #1630) [Link] (2 responses)

This seems like a middle-finger from Canonical against Incus. But given Canonical's head honcho, it doesn't surprise me that the company would do something like this.

Graber: LXD now re-licensed and under a CLA

Posted Dec 13, 2023 4:33 UTC (Wed) by stgraber (guest, #57367) [Link] (1 responses)

That does seem like the main benefit of this change indeed....

The changes they made doesn't magically turn Canonical into a full copyright owner for LXD which could have been an argument for this AGPLv3 + CLA combination if it had been done at the beginning of the project rather than 9 years down the line.

Other than making it impossible for any kind of collaboration between the two projects moving forward, the only other benefit they gain from this is the ability to charge people to get an Apache2 version of the code, something they can absolutely do given that they hold the right to relicense any of the AGPLv3 code in there.

Now, we could technically follow their licensing change with Incus which would actually make things quite hilariously bad for Canonical as we'd then be able to import any change we want from LXD but they wouldn't able to do the same due to their CLA getting in the way :)

Unfortunately, we have no intentions to change license, AGPLv3 in the Go ecosystem is an extremely odd choice with problematic repercussions for downstreams (or downstreams of downstreams) which we don't want to cause to our users.
We also don't want to end up in the same licensing grey area that they manage to put themselves into...

So Incus will remain under the Apache2 license, not to mention has absolutely no intention to ever add a CLA, we're quite happy with the DCO as far as basic code ownership tracking goes.

Graber: LXD now re-licensed and under a CLA

Posted Dec 18, 2023 16:24 UTC (Mon) by nim-nim (subscriber, #34454) [Link]

Grafana went the AGPLv3 route for its own (Go) software, MIT & ASL2 may work for the MAGMA but not for smaller actors.

Graber: LXD now re-licensed and under a CLA

Posted Dec 13, 2023 5:22 UTC (Wed) by arraybolt3 (guest, #168272) [Link]

If they have a mixed AGPL + Apache licensing scheme already, perhaps the CLA requires that new contributions only be AGPL, but that doesn't keep Canonical from integrating changes from Incus if they want to (assuming the licenses are compatible, which I have no idea if that is the case but assume it would be). Perhaps it is an attempt to push out Incus, like the recent Red Hat source changes were an attempt to push out RHEL clones.

I'm not exactly thrilled to see this, that's for sure. And I pity the poor person in Debian who has to rebuild the debian/copyright file for LXD now.

Graber: LXD now re-licensed and under a CLA

Posted Dec 13, 2023 6:31 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (3 responses)

"Canonical cannot release LXD under the AGPLv3 license and likely never will be able to" is not really true, as it's only half of the story:

* Because Apache license is compatible with the AGPLv3, anyone other than Canonical *has to* diistribute LXD under the AGPLv3. There could be parts of it that are exclusively created before today by community members, and thus under Apache 2 license, but those will be fewer and fewer and one might as well pick any such packages from the last Apache-licensed snapshot.

* On the other hand, thanks to the CLA on copyleft contributions, and the permissive license on contributions without CLA, Canonical can also license LXD to its customers under a proprietary license that doesn't have network usage requirements (and use it themselves that way!). This is allowed by the Apache license

* Also because Apache license and AGPLv3 are compatible, and the Apache license is not copyleft, Canonical *can* pick patches from Incus even though they're not under the CLA. It's their choice how much to do so. All that Incus could do instead is clean room reverse engineering.

Graber: LXD now re-licensed and under a CLA

Posted Dec 13, 2023 14:14 UTC (Wed) by stgraber (guest, #57367) [Link] (2 responses)

You're correct that they can include Apache2 licensed code in an AGPLv3 project, that however does not change the license on any of that Apache2 code that exists and proper headers and tracking on that code should remain present to clearly indicate to anyone reading the LXD code, what they can freely include in their projects regardless of license (the Apache2 code) and what requires them to re-license (the AGPLv3) bits.

Now as for Canonical's ability to take in new Incus code. From a licensing standpoint, it can be done, but not following their current contribution guidelines for all new code as those stipulate that new code must be AGPLv3 and that new code must be from someone or some organization that has signed the Canonical CLA. So they'd need to carve a pretty serious exception for that and then keep track of all that code as it won't be AGPLv3 and Canonical won't have a license to do whatever they want with it, so that code will forever belong to its author and will forever be Apache2.

Graber: LXD now re-licensed and under a CLA

Posted Dec 13, 2023 16:18 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (1 responses)

I don't think much of a carve out is needed. The pull request says "default" contributions are AGPLv3. They can include permissively-licensed code into this AGPLv3 codebase, for example by vendoring a MIT dependency, and they can do the same for Apache v2 code from Incus.

Graber: LXD now re-licensed and under a CLA

Posted Dec 13, 2023 16:52 UTC (Wed) by pizza (subscriber, #46) [Link]

> they can do the same for Apache v2 code from Incus.

...That code still won't have originated from someone signing Canonical's CLA.

Of course, Canonical can (and probably will) waive that policy when it suits them.

Graber: LXD now re-licensed and under a CLA

Posted Dec 13, 2023 10:00 UTC (Wed) by joib (subscriber, #8541) [Link] (2 responses)

For someone who has followed this sage only at arms length, is Incus seeing some external interest yet, and how active is the development? Unfortunately it seems that this decision by Canonical will lead to a hard fork between the two projects, so eventually it'll become significant which path one chooses. How many FTE (full-time equivalent) engineers are working on LXD vs Incus?

Graber: LXD now re-licensed and under a CLA

Posted Dec 13, 2023 14:24 UTC (Wed) by stgraber (guest, #57367) [Link]

Hey there,

We don't do any kind of reliable user tracking for Incus (obviously), but looking at just traffic on our image servers we're seeing right around a 15% month to month user base growth with the total sitting at around 5000 active daily users pulling images from us.

That's not a lot, yet, but it's also worth noting that not all users interact with the image server on a daily or even weekly/monthly basis. Because of how Incus works, a lot of it tends to be set up and forget where users create all the instances they need to run their infrastructure and then just interact with those instances as they would any other Linux systems.

On the contribution side of things, I'm working full time on it, self-employed with my time paid for by a mix of community sponsors (Github Sponsors, Patreon, Ko-fi), by the hour consultation for folks wanting their setup review or wanting help migrating from LXD as well as doing sponsored feature development for a few different companies.

The other maintainers are working for a variety of employers and primarily do code reviews and help out here and there.
We have however seen a recent uptake (even before this announcement) from both drive by and more active former LXD community members now moving to Incus, I expect that the Canonical CLA will be pushing a bunch more of those folks our way.

The thing worth pointing out is that this is a very mature project, it's been around for more than 9 years and I've been involved with it from its start, the other Incus maintainers are also the folks who helped create it while we were all at Canonical, so we have all the historical knowledge around everything that's in there and between all of us have probably designed more than 90% of what's in LXD/Incus today. So while not being able to benefit from the work of the 2-3 full time engineers that Canonical has working on LXD itself is certainly unfortunate, it's also similarly unfortunate for Canonical to no longer be able to reach out to us when they need background information on why something was done a particular way or have us collaborate on fixing some bugs deep in the codebase.

Graber: LXD now re-licensed and under a CLA

Posted Dec 13, 2023 19:08 UTC (Wed) by edeloget (subscriber, #88392) [Link]

We are currently working to phase out lxd here, and we are of course replacing it with incus. This is a work in progress and our infrastructure seems to push incus to some of its limits but so far, so good (I'm not working on this team so I don't have a full view of their successes/issues).

BTW, Mr. Graber, thanks for your work!

Graber: LXD now re-licensed and under a CLA

Posted Dec 13, 2023 20:30 UTC (Wed) by carlosrodfern (subscriber, #166486) [Link] (29 responses)

Actually, AGPLv3 is awesome for projects that are not libraries. It prevents Cloud Providers opportunistically using it, and only releasing _some_ of the changes to keep the good public image. It hinders their monopoly, and benefits the users since the product they see on the cloud is exactly what they see in GitHub.

The majority of those spreading fear mongering about AGPLv3 are the big Cloud Providers (of course), and many companies and individuals had followed without critical thinking.

Graber's comment:

```
For LXD users, other than potentially triggering corporate policies that ban the use of AGPLv3 software (**more common than one may think**), the impact should be minimal. It’s still the same LXD and it’s still open source software.
```

Except Google and others that follow it, companies can see that it is totally OK to use AGPLv3 software as long as you are not linking to it as a library. That's how mine goes. A blanket ban against it regardless how it is used is likely not as common as you think.

Good move for Canonical. The Canonical CLA looks reasonable to me.

Graber: LXD now re-licensed and under a CLA

Posted Dec 13, 2023 22:55 UTC (Wed) by pizza (subscriber, #46) [Link] (28 responses)

> Except Google and others that follow it, companies can see that it is totally OK to use AGPLv3 software as long as you are not linking to it as a library

"linking to it" includes minor bits like integration with your authentication/account infrastructure, logging/reporting systems, and so forth.

In other words, try to operate it as anything but a completely standalone, unintegrated, non-scalable service, and you effectively have to give away the literal keys to your kingdom. That's such an incredibly toxic proposition that it's nearly always [1] used as a deliberate poison pill to steer folks into commercial licensing agreements, which (combined with the CLA requirement) I'd wager the $15 in my wallet is Canonical's intent.

> A blanket ban against it regardless how it is used is likely not as common as you think.

My last _four_ employers have had a hard "no AGPL software, period" policy in place, while allowing GPL (even v3) stuff after varying degrees of review.

[1] The only general exception I'm aware of is a significant portion of the ActivtityPub universe.

Graber: LXD now re-licensed and under a CLA

Posted Dec 13, 2023 23:32 UTC (Wed) by carlosrodfern (subscriber, #166486) [Link] (27 responses)

> "linking to it" includes minor bits like integration with your authentication/account infrastructure, logging/reporting systems, and so forth.

If the integration is over network protocols, pipelines, files, stdin/out, sockets, system queues, there is no requirement to release nothing. What is more, if you are not offering it directly or indirectly thru proxies to external users, but it remains within company boundaries, you don't have to release even your internal modifications of it.

It is only when you use it as a library, or you write a plugin that is dynamically linked, or your program shares memory with a GPL/AGPL program, that it affects your code. It becomes a requirement to release the code once you make your program available to external users.

More info:
https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic
https://www.gnu.org/licenses/gpl-faq.html#GPLPlugins

Graber: LXD now re-licensed and under a CLA

Posted Dec 13, 2023 23:49 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (26 responses)

> If the integration is over network protocols, pipelines, files, stdin/out, sockets, system queues, there is no requirement to release nothing.

That's not what AGPL says:

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

So if your installation depends on your internal logging service, you have to provide its source code.

Graber: LXD now re-licensed and under a CLA

Posted Dec 14, 2023 0:34 UTC (Thu) by carlosrodfern (subscriber, #166486) [Link] (25 responses)

That's a good one. Yeah, if you modify the generation, install, or run, and provide the services over the network, that's the case. It is beneficial to the user, though, that such modification is released.

The scope of "generate", "install", and "run" needs its definition because for instance, the Linux kernel doesn't become "AGPLv3" for "run"ing a AGPLv3 program, nor is the case of rpm/deb for packing it, configuring it, just using the `make install` and macros.

Your example of logging seems like a non-typical scenario, though. Logging is usually just a configuration change to log to stdout (or to a file), and capture that with your logging solution . That kind of interaction, that doesn't require `make install` changes, wouldn't require you to release your logging solution program.

That's from what I can understand.

Graber: LXD now re-licensed and under a CLA

Posted Dec 14, 2023 0:53 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (24 responses)

> Your example of logging seems like a non-typical scenario, though. Logging is usually just a configuration change to log to stdout (or to a file), and capture that with your logging solution

In many corporate applications, logging can be quite complicated. E.g. you might have separate high-security logs for items with personal data, there are also tracing and metrics integration. Same for authorization and authentication, often you need to integrate with your local system for user directories.

Ultimately, nobody dares to test this part of the AGPL. So AGPL remains a "trial" license for dual-licensed corporate shareware.

I'm aware of really only one pure AGPL product that has mass adoption: nextCloud.

Graber: LXD now re-licensed and under a CLA

Posted Dec 14, 2023 2:01 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (23 responses)

> I'm aware of really only one pure AGPL product that has mass adoption: nextCloud.

Hmm. I don’t know that nextCloud has mass adoption but certainly there are other popular ones including Grafana, Bitwarden, Mastadon and Signal

Graber: LXD now re-licensed and under a CLA

Posted Dec 14, 2023 2:20 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (22 responses)

> Grafana

Dual licensed.

> Bitwarden

Dual licensed.

> Mastadon
> Signal

Yeah, I didn't know about these ones (probably because I'm pretty anti-social-networks).

Graber: LXD now re-licensed and under a CLA

Posted Dec 14, 2023 7:44 UTC (Thu) by ras (subscriber, #33059) [Link] (21 responses)

> > Bitwarden
>
> Dual licensed.

I don't know about the others, but it looks to me like any given line of code in Bitwarden is covered by one licence.

Not that it matters. They are the author. They are free to put it under as many licences as they like. All it takes is the stroke of a pen. So you want to hack it and not release the source? Sure give us a lump of cash, and we will give you a licence.

From where I sit AGPL is the idea licence to use if you want the source to be open and freely modifiable, but make it commercially unattractive to do so. I bet Elasticsearch is regretting not doing just that and Amazon is rubbing their hands with glee because they didn't.

Graber: LXD now re-licensed and under a CLA

Posted Dec 14, 2023 8:25 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (20 responses)

> I don't know about the others, but it looks to me like any given line of code in Bitwarden is covered by one licence.

They have AGPL + Bitwarden License (which is "shared source").

> From where I sit AGPL is the idea licence to use if you want the source to be open and freely modifiable, but make it commercially unattractive to do so.

No. AGPL is almost exclusively used _along_ with an option to buy a commercial license under different terms (and all the contributors typically have to sign a CLA to allow that). AGPL is so toxic, that not many large companies are going to allow it in production use in this case. But AGPL still allows users to download and experiment with it. It's basically a "shareware" model.

I have nothing against that, private companies need to earn money after all. It's just not at all what OpenSource is typically about. It doesn't build communities and it doesn't foster outside contributions.

Graber: LXD now re-licensed and under a CLA

Posted Dec 14, 2023 18:06 UTC (Thu) by carlosrodfern (subscriber, #166486) [Link]

Cyberax,
Lots of companies that are not big tech, use the OSS AGPL version of Grafana, and Grafana Loki, and Grafana Tempo, Minio, and some Scylladb. No issues.

Big Tech / Cloud Vendors are the ones so afraid of it. Their view comes with the conflict of interest smell. Smaller companies that don't have the luxury of paying for re-licensing, or proprietary stuff, and need to leverage as much as possible OSS, look at AGPL with a unbias point of view (or biased towards cost reduction), and just realize it is OK. AGPL is toxic to those that "feel the need" to modify the program.

Graber: LXD now re-licensed and under a CLA

Posted Dec 14, 2023 22:05 UTC (Thu) by atai (subscriber, #10977) [Link] (18 responses)

> I have nothing against that, private companies need to earn money after all. It's just not at all what OpenSource is typically about. It doesn't build communities and it doesn't foster outside contributions.

Not sure what you talk about. AGPL is just GPL for the cloud era. Of course AGPL builds community and foster outside contributions--just how the GPL worked pre-cloud era.

Graber: LXD now re-licensed and under a CLA

Posted Dec 14, 2023 22:14 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (17 responses)

> Of course AGPL builds community and foster outside contributions

LOL, no. I like to give an example of Mailpile, a project to build a web mail client. It started as Apache 2, and experienced rapid development. Then they voted to move it to true AGPL without any double licensing. Overnight, the contributions disappeared, and the project basically stagnated (it's kinda undead right now): https://github.com/mailpile/Mailpile

> --just how the GPL worked pre-cloud era.

Pre-cloud GPL worked because it was clearly limited. AGPL lacks these kinds of limitations.

Graber: LXD now re-licensed and under a CLA

Posted Dec 15, 2023 7:06 UTC (Fri) by ras (subscriber, #33059) [Link] (14 responses)

> Pre-cloud GPL worked because it was clearly limited. AGPL lacks these kinds of limitations.

Have you diff'ed the two? The diff is about 60 lines long, but most of that is noise. Noise like the word "Affero" appears in the AGL but not the GPL and both licences making it clear it can co-exist with the other.

If you strip all that away you are left with one additional paragraph in the AGPL in section 13 (the section numbering is identical in both):

> 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. This Corresponding Source
> shall include the Corresponding Source for any work covered by version 3
> of the GNU General Public License that is incorporated pursuant to the
> following paragraph.

Most of that paragraph is also redundant, and when you strip that redundancy away you are left with this:

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

That's the sum total of the change. No limitations are "stripped away". There is no land grab on what derived program might be - it's the same for the GPL and the AGPL.

This is well known to everybody whose taken the 5 minutes to compare the text. Many have. For example: https://opensource.stackexchange.com/questions/5041/of-th... Read that if you need a more authoritative source of the same facts.

Graber: LXD now re-licensed and under a CLA

Posted Dec 15, 2023 7:15 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (12 responses)

> Have you diff'ed the two?

I spent hours with legal council talking through AGPL's ramifications. The main problem is that AGPL doesn't clearly define where it ends.

GPL technically also doesn't define that, but there is clear guidance from the FSF that GPL likely stops at the process border: https://www.gnu.org/licenses/gpl-faq.html#MereAggregation

> That's the sum total of the change. No limitations are "stripped away".

It's not quite that simple.

Graber: LXD now re-licensed and under a CLA

Posted Dec 15, 2023 7:39 UTC (Fri) by ras (subscriber, #33059) [Link] (11 responses)

> It's not quite that simple.

It never is if you involve a lawyer. If they made it simple they would be putting themselves out of a job.

The FSF has this to say about the differences between the GPL and AGL https://www.gnu.org/licenses/gpl-faq.en.html#AllCompatibi... :

> Each place that the matrix states GPLv3, the same statement about compatibility is true for AGPLv3 as well.

It looks simple to me. The obvious interpretation of the GPL and AGPL being identical in all respects except that one paragraph is the FSF intends them to be interpreted identically. But then I'm not a lawyer.

Graber: LXD now re-licensed and under a CLA

Posted Dec 15, 2023 7:46 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

> The FSF has this to say about the differences between the GPL and AGPL

It doesn't actually say anything if you read it. What is needed is a clear guidance on what "Corresponding Source" is.

For example, if your modified version calls a proprietary service over a REST interface, is this a derived work? With GPL it's easy, it's a clear "no".

Graber: LXD now re-licensed and under a CLA

Posted Dec 15, 2023 9:32 UTC (Fri) by ras (subscriber, #33059) [Link] (9 responses)

> It doesn't actually say anything if you read it. What is needed is a clear guidance on what "Corresponding Source" is.
>
> For example, if your modified version calls a proprietary service over a REST interface, is this a derived work? With GPL it's easy, it's a clear "no".

I don't understand why that's clear. The lack of a clear definition of what "Corresponding Source" or "derivative work" in GPLv2 terms has always been a bugbear of mine. Still, if a lawyer says it's clear, then it guess it must be clear in the eyes of the law.

I can now add to my list of bugbear's why the term "Corresponding Source" defined using exactly the same words in two licences written by the same organisation, that the organisation says are identical in every way bar one [0], could be construed to have two different meanings by a lawyer.

[0] https://www.gnu.org/licenses/why-affero-gpl.en.html :

> The GNU Affero General Public License is a modified version of the ordinary GNU GPL version 3. It has one added requirement: if you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there.

Graber: LXD now re-licensed and under a CLA

Posted Dec 15, 2023 10:41 UTC (Fri) by kleptog (subscriber, #1183) [Link] (8 responses)

> I can now add to my list of bugbear's why the term "Corresponding Source" defined using exactly the same words in two licences written by the same organisation, that the organisation says are identical in every way bar one [0], could be construed to have two different meanings by a lawyer.

ISTM the issue is not so much the licence text, but the fact that with the program being distributed under the GPL you have a clear boundary between what is in the package and what is not. However, once it is deployed in production it becomes trickier: the "make install" step is going to generate a bunch of files, for example, in /etc for configuration. If you modify this configuration, are you modifying the program in a way that you need to share the changes? This doesn't arise with the GPL because you never distribute a deployed program, just the original source.

A possible solution here is if the AGPL application is distributed as a container, then you can draw a clear boundary between: changes to the container should be shared, any configuration done simply by mapping volumes and passing variables is no problem.

I don't think the lawyers are saying it's clear in law, I think they're clearly saying it's clear that it's unclear.

Graber: LXD now re-licensed and under a CLA

Posted Dec 15, 2023 14:11 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> However, once it is deployed in production it becomes trickier: the "make install" step is going to generate a bunch of files, for example, in /etc for configuration. If you modify this configuration, are you modifying the program in a way that you need to share the changes?

This particular problem is why I chose to _not_ use the AGPL (versus the GPL) for a PHP-based application I took over some time ago. My conclusion was that, yes, any file the PHP interpreter parsed would need to be included. While I don't consider "configuration" files to be part of the application per se, in practical terms even my example configurations contained code snippets and pulled in out-of-tree authentication libraries.

Graber: LXD now re-licensed and under a CLA

Posted Dec 15, 2023 14:29 UTC (Fri) by pizza (subscriber, #46) [Link]

> While I don't consider "configuration" files to be part of the application per se, in practical terms even my example configurations contained code snippets and pulled in out-of-tree authentication libraries.

(oops, submitted this before I was done)

There was also a non-trivial amount of "business logic" implemented as stored procedures in the database, so compliance with the AGPL would have required generating a partial database dump. Which arguably would have required including all of postgresql too, given the PostGIS integration I had been experimenting with at the time...

In the end, I decided against it, because even making the demo sites (including the one I was running for myself) compliant with its own license would have required a ton of work, and it just wasn't worth it.

Graber: LXD now re-licensed and under a CLA

Posted Dec 15, 2023 14:33 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

> I don't think the lawyers are saying it's clear in law, I think they're clearly saying it's clear that it's unclear.

The wording of the (A)GPL itself is clear, the problem is that the licence cannot define what the law means. Which means we are at the mercy of the Judges as to the meaning of "derivative".

The other thing with the GPL is you can distribute the program on CD. Anything already on the recipient computer is in the clear, because that linking (if any) is covered by the "you can use the program".

The problem with the AGPL is you have to distribute "everything somebody coming in over the web needs to replicate your setup on their system". HOW MUCH of "what is nothing to do with the AGPL but everything to do with enabling the AGPL program to run" is caught in that net?

THAT is what is unclear, and if it includes proprietary software, the result is your AGPL program is legally unusable outside your organisation!

Cheers,
Wol

Graber: LXD now re-licensed and under a CLA

Posted Dec 15, 2023 14:46 UTC (Fri) by pizza (subscriber, #46) [Link]

> The problem with the AGPL is you have to distribute "everything somebody coming in over the web needs to replicate your setup on their system". HOW MUCH of "what is nothing to do with the AGPL but everything to do with enabling the AGPL program to run" is caught in that net?

Then there's stuff like like custom themes, artwork/logos, and so forth. After all, they're part of the "complete corresponding source of your version"

(Simply _modifying the theme_ of an AGPL webapp creates a derivative work, which triggers the AGPL's redistribution requirements!)

Graber: LXD now re-licensed and under a CLA

Posted Dec 15, 2023 23:22 UTC (Fri) by ras (subscriber, #33059) [Link] (3 responses)

> This doesn't arise with the GPL because you never distribute a deployed program, just the original source.

Actually, most distros do distribute a compiled program, together with configuration files. Debian will typically distribute it so it is working right after "apt install" exits.

Even if they weren't true, if you are just distributing source the definition of "derivative work" (I prefer that term) doesn't stop at the distributed files. In must include the libraries the package uses even if those libraries aren't included in the shipped binary (let alone the source). We know that because libc is shipped with a different licence, the LPGL, so it's .so can be used by non copy-left programs.

If I was were trying to bypass the GPL then even that would not stop me. If your library doesn't allow it to be called directly from my program then I'll write a 2nd program covered by a compatible licence that implements a RPC mechanism. If your response is you change your definition of "derivative work" say, to "running on the same CPU", then I'll run my RPC program on a different CPU. That's what NVIDIA has done get around kernel GPL. We are dealing with Turing machines here, and the things are so damned powerful I suspect any formal definition of "derivative work" that doesn't involve the term "light cone" is going to fail. The response to this conundrum seems to be "leave it to the lawyers" and the definition of copyright. They seem to delight in the ambiguity. It's almost as it their pay packets depend on it.

So I understand your concern about where the boundaries between your source and GPL source lie. I don't know either. But what does seem clear is those boundaries are the same for the GPL and AGPL. There is only one extra paragraph in the AGPL. It talks about how a "user" interacts with a program. It does not mention "Corresponding Source", and I don't see how a straight forward reading of it could be said to change the definition of that term.

So when Cyberax said above:

> For example, if your modified version calls a proprietary service over a REST interface, is this a derived work? With GPL it's easy, it's a clear "no".

I have to agree I have no idea how it's a clear "no" for the AGPL. But that's also true for the GPL. And given the FSF have stated in writing the AGPL and GPL differ only by that one clause and that clause doesn't deal with "Corrosponding Source", if you think it's a clear "no" for the GPL then it's a clear "no" for the AGPL too. To put it another way, all these "extra limitations" Cyberax mentions literally don't exist, and that's easily demonstrated using a tool we are all familiar with - diff.

Graber: LXD now re-licensed and under a CLA

Posted Dec 16, 2023 2:01 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

> But that's also true for the GPL

There is a huge history of companies "working around" the GPL by splitting it into a separate process. Along with the official FAQ from the FSF this provides enough assurance that it's, in fact, expected.

Graber: LXD now re-licensed and under a CLA

Posted Dec 16, 2023 11:45 UTC (Sat) by Wol (subscriber, #4433) [Link] (1 responses)

And this is the problem with the AGPL.

The GPL explicitly excludes "other stuff already running on the host computer", which fairly clearly includes things like REST services.

The AGPL appears to INclude anything, without which the AGPL'd program can't run, which also fairly includes things like REST services.

So if a GPL program touches an "already installed" proprietary program, no problem, as I said it's covered by the GPL's "right to run the program" exclusion. But if an AGPL program touches an "already installed" program, that appears to be part of the AGPL program's "corresponding source" (because it's required to replicate the setup), and it instantly renders the AGPL program unusable for general access, because you can't comply with the terms!

Cheers,
Wol

Graber: LXD now re-licensed and under a CLA

Posted Dec 17, 2023 6:53 UTC (Sun) by ras (subscriber, #33059) [Link]

> The GPL explicitly excludes "other stuff already running on the host computer", which fairly clearly includes things like REST services.
>
> The AGPL appears to INclude anything, without which the AGPL'd program can't run, which also fairly includes things like REST services.

I posted the diff above. Can you point to where the difference you are describing appears in that diff? I can't see it.

Graber: LXD now re-licensed and under a CLA

Posted Dec 16, 2023 23:12 UTC (Sat) by ballombe (subscriber, #9523) [Link]

The whole problem is that "your modified version must prominently offer all users interacting" is meaningless since 'your modified version' is not a legal entity that can be held to an offer.

Graber: LXD now re-licensed and under a CLA

Posted Dec 15, 2023 7:14 UTC (Fri) by ras (subscriber, #33059) [Link] (1 responses)

> I like to give an example of Mailpile, a project to build a web mail client. It started as Apache 2, and experienced rapid development. Then they voted to move it to true AGPL without any double licensing. Overnight, the contributions disappeared

If Mailpile was indeed a useful to someone there was an easy way forward: pick up the Apache 2 version and run with it. I gather that didn't happen.

Projects fall apart for all sorts of reasons. It may even have been the licence change that did it. People can get passionate about those sorts of things to the point it breaks working relationships ("if that's how you feel I don't want to work with you on Mailpile any more"). But if it truly was the text of AGPL they objected to and not just ramming through a change, then like I said the solution is simple enough. There was no need for the project to die.

Graber: LXD now re-licensed and under a CLA

Posted Dec 15, 2023 7:21 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

> If Mailpile was indeed a useful to someone there was an easy way forward: pick up the Apache 2 version and run with it. I gather that didn't happen.

If Mailpile were a bit bigger during the switch, this would have happened (see: Terraform). But it still was mostly a one-man show, with a bunch of smaller contributors as extras. These contributors then just disappeared.

What hasn't happened, was the growth of the community, the purported reason for the AGPL switch.