Graber: LXD now re-licensed and under a CLA
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.
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.
Posted Dec 13, 2023 4:33 UTC (Wed)
by stgraber (subscriber, #57367)
[Link] (1 responses)
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.
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.
Posted Dec 18, 2023 16:24 UTC (Mon)
by nim-nim (subscriber, #34454)
[Link]
Posted Dec 13, 2023 5:22 UTC (Wed)
by arraybolt3 (guest, #168272)
[Link]
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.
Posted Dec 13, 2023 6:31 UTC (Wed)
by pbonzini (subscriber, #60935)
[Link] (3 responses)
* 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.
Posted Dec 13, 2023 14:14 UTC (Wed)
by stgraber (subscriber, #57367)
[Link] (2 responses)
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.
Posted Dec 13, 2023 16:18 UTC (Wed)
by pbonzini (subscriber, #60935)
[Link] (1 responses)
Posted Dec 13, 2023 16:52 UTC (Wed)
by pizza (subscriber, #46)
[Link]
...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.
Posted Dec 13, 2023 10:00 UTC (Wed)
by joib (subscriber, #8541)
[Link] (2 responses)
Posted Dec 13, 2023 14:24 UTC (Wed)
by stgraber (subscriber, #57367)
[Link]
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.
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.
Posted Dec 13, 2023 19:08 UTC (Wed)
by edeloget (subscriber, #88392)
[Link]
BTW, Mr. Graber, thanks for your work!
Posted Dec 13, 2023 20:30 UTC (Wed)
by carlosrodfern (subscriber, #166486)
[Link] (29 responses)
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:
```
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.
Posted Dec 13, 2023 22:55 UTC (Wed)
by pizza (subscriber, #46)
[Link] (28 responses)
"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.
Posted Dec 13, 2023 23:32 UTC (Wed)
by carlosrodfern (subscriber, #166486)
[Link] (27 responses)
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:
Posted Dec 13, 2023 23:49 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (26 responses)
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.
Posted Dec 14, 2023 0:34 UTC (Thu)
by carlosrodfern (subscriber, #166486)
[Link] (25 responses)
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.
Posted Dec 14, 2023 0:53 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (24 responses)
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.
Posted Dec 14, 2023 2:01 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link] (23 responses)
Hmm. I don’t know that nextCloud has mass adoption but certainly there are other popular ones including Grafana, Bitwarden, Mastadon and Signal
Posted Dec 14, 2023 2:20 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (22 responses)
Dual licensed.
> Bitwarden
Dual licensed.
> Mastadon
Yeah, I didn't know about these ones (probably because I'm pretty anti-social-networks).
Posted Dec 14, 2023 7:44 UTC (Thu)
by ras (subscriber, #33059)
[Link] (21 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.
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.
Posted Dec 14, 2023 8:25 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (20 responses)
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.
Posted Dec 14, 2023 18:06 UTC (Thu)
by carlosrodfern (subscriber, #166486)
[Link]
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.
Posted Dec 14, 2023 22:05 UTC (Thu)
by atai (subscriber, #10977)
[Link] (18 responses)
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.
Posted Dec 14, 2023 22:14 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (17 responses)
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.
Posted Dec 15, 2023 7:06 UTC (Fri)
by ras (subscriber, #33059)
[Link] (14 responses)
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
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
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.
Posted Dec 15, 2023 7:15 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (12 responses)
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.
Posted Dec 15, 2023 7:39 UTC (Fri)
by ras (subscriber, #33059)
[Link] (11 responses)
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.
Posted Dec 15, 2023 7:46 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (10 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".
Posted Dec 15, 2023 9:32 UTC (Fri)
by ras (subscriber, #33059)
[Link] (9 responses)
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.
Posted Dec 15, 2023 10:41 UTC (Fri)
by kleptog (subscriber, #1183)
[Link] (8 responses)
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.
Posted Dec 15, 2023 14:11 UTC (Fri)
by pizza (subscriber, #46)
[Link] (1 responses)
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.
Posted Dec 15, 2023 14:29 UTC (Fri)
by pizza (subscriber, #46)
[Link]
(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.
Posted Dec 15, 2023 14:33 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
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,
Posted Dec 15, 2023 14:46 UTC (Fri)
by pizza (subscriber, #46)
[Link]
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!)
Posted Dec 15, 2023 23:22 UTC (Fri)
by ras (subscriber, #33059)
[Link] (3 responses)
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.
Posted Dec 16, 2023 2:01 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
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.
Posted Dec 16, 2023 11:45 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (1 responses)
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,
Posted Dec 17, 2023 6:53 UTC (Sun)
by ras (subscriber, #33059)
[Link]
I posted the diff above. Can you point to where the difference you are describing appears in that diff? I can't see it.
Posted Dec 16, 2023 23:12 UTC (Sat)
by ballombe (subscriber, #9523)
[Link]
Posted Dec 15, 2023 7:14 UTC (Fri)
by ras (subscriber, #33059)
[Link] (1 responses)
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.
Posted Dec 15, 2023 7:21 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
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.
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
We also don't want to end up in the same licensing grey area that they manage to put themselves into...
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
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.
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
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.
```
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
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
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
> Signal
Graber: LXD now re-licensed and under a CLA
>
> Dual licensed.
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
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.
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
> 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.
> remotely through a computer network (if your version supports such
> interaction) an opportunity to receive the Corresponding
> Source of your version.
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
>
> 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
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
Wol
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
Wol
Graber: LXD now re-licensed and under a CLA
>
> The AGPL appears to INclude anything, without which the AGPL'd program can't run, which also fairly includes things like REST services.
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA
Graber: LXD now re-licensed and under a CLA