https://stgraber.org/2023/12/12/lxd-now-re-licensed-and-under-a-cla/ Stephane Graber's website Skip to content [svg] Skip to content * Home * About me * Projects - Announcing Incus 0.3 LXD now re-licensed and under a CLA Posted on 2023/12/12 by Stephane Graber [svg] The facts As of earlier today, right before the release of LXD 5.20, Canonical made a couple of changes to LXD which are sure to have a serious impact to LXD users and downstream projects that integrate with LXD or provide solutions based on it. The first is the re-licensing of LXD from the Apache2 license to the AGPLv3 license. This happened in: https://github.com/canonical/lxd/pull/12663 The second is the addition of the Canonical CLA as requirement for all further contributions. This happened in: https://github.com/canonical/lxd/pull/12665https:// github.com/canonical/lxd/pull/12663 Disclaimer What's below is my personal analysis of the situation, it is not legal advice, anyone affected is very strongly encouraged to seek proper legal advice from their counsel. Real license of 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. This is likely to make it very "fun" for anyone performing licensing reviews to evaluate LXD for adoption in their environment. Impact to LXD users 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. However, if you were altering LXD in any way, then you will need to familiarize yourself with the AGPLv3 license as unlike Apache2, it does require any changes be made available under the AGPLv3 even if you don't expose your users to your modified binaries. This is the main design characteristics of the AGPLv3 license, it was meant to force those operating modified versions of open source as a hosted service to share their modifications. Impact to downstreams (consumer of LXD Go packages) Up until now, all the Go packages of LXD were under the Apache2 license, that was fitting quite well in the Go ecosystem where the Apache2, BSDs and MIT licenses are very popular. Now with this change, you need to realize that you may start to include/bundle AGPLv3 code within your own project. This a copyleft license and so may require re-licensing of your own project to comply with it. Again, this is quite the can of worms, with my usual recommendation being "stay away", but if you must use any of LXD's Go packages, I'd strongly recommend talking to a lawyer to fully understand your exposure to that new license. Impact on Incus Now for what obviously impacts me the most, what this is going to do to Incus. As a brief reminder Incus is a fork of LXD which was started in August 2023. So far, it's been tracking LXD changes, applying those that make sense and otherwise fixing bugs and making improvements of its own, as most forks do. This change from Canonical is going to be causing two unfortunate side effects: * Incus will no longer be including changes originating from LXD as that would require us to include AGPLv3 code into our codebase and so get us into the same mixed license mess as LXD now put itself. This is obviously unacceptable to us, we very much like licensing clarity and quite enjoy the Apache2 license. * LXD will similarly no longer be able to take changes from Incus, as those are going to remain under the Apache2 license and more importantly, will not have been released under the Canonical CLA. To enforce that second part, the tooling we've been using thus far to monitor LXD changes and automatically backport them to Incus will be used to detect any changes to LXD which originated from Incus. Unless the author gave express consent for them to be released under a different license and under the Canonical CLA, those changes should not be included in LXD. Incus is also a consumer of the LXD Go API in the lxd-to-incus tool. Thankfully, we have no need for anything recent in there, so will simply be making sure that we never import code past the licensing change. Conclusion Overall, I'm very disappointed, although absolutely not surprised in seeing this change happen. It's certainly going to be quite annoying for Incus, and I suspect this is the whole point of it. But it's also a very odd move by Canonical as it puts LXD into a problematic grey area as far as its true license is concerned which will likely seriously hurt its adoption both by companies and distributions. In any case, I'd urge anyone who has concerns about this change to reach out to their legal representation and maybe consider switching over to Incus where we will happily keep releasing our CLA-free Apache2 licensed fork of this once great project. [svg] About Stephane Graber Project leader of Linux Containers, Linux hacker, Ubuntu core developer, conference organizer and speaker. View all posts by Stephane Graber - This entry was posted in Incus, Planet Ubuntu, Zabbly. Bookmark the permalink. - Announcing Incus 0.3 Leave a Reply Cancel reply Your email address will not be published. Required fields are marked * [ ] [ ] [ ] [ ] [ ] [ ] [ ] Comment * [ ] Name * [ ] Email * [ ] Website [ ] [Post Comment] [ ] Notify me of followup comments via e-mail [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] This site uses Akismet to reduce spam. Learn how your comment data is processed. * Sponsor + Github + Patreon * Social + Github Github + Twitter Twitter + LinkedIn LinkedIn + Mastodon Mastodon * Feeds + RSS feed RSS feed + RSS feed (comments) RSS feed (comments) * Categories + Arkose + Canonical voices + Conferences + Edubuntu + gbtsco + Incus + IPv6 + iTalc + LTSP + LXC + LXCFS + LXD + mirrorkit + pastebinit + Planet Revolution-Linux + Planet Ubuntu + Sandbox + Ubuntu Touch + WebLive + Zabbly * Archives + December 2023 + November 2023 + October 2023 + September 2023 + August 2023 + July 2023 + June 2021 + December 2020 + June 2017 + April 2017 + March 2017 + February 2017 + January 2017 + December 2016 + October 2016 + June 2016 + April 2016 + March 2016 + December 2015 + April 2015 + September 2014 + February 2014 + January 2014 + December 2013 + September 2013 + July 2013 + February 2013 + November 2012 + October 2012 + September 2012 + July 2012 + May 2012 + March 2012 + February 2012 + January 2012 + September 2011 + August 2011 + July 2011 + June 2011 + May 2011 + April 2011 + March 2011 + February 2011 + January 2011 + December 2010 + November 2010 + October 2010 + September 2010 + February 2010 + January 2010 + December 2009 + November 2009 + October 2009 + July 2009 + April 2009 + March 2009 + December 2008 + September 2008 + July 2008 + June 2008 + May 2008 (c) 2023 - Stephane Proudly powered by WordPress. 2010 Weaver Graber's website by WPWeaver.info