Dear Maintainer, * What led up to the situation? HashiCorp adopts the BSL. https://ir.hashicorp.com/news-releases/news-release-details/hashicorp-adopts- business-source-license-future-releases-its Currently, vagrant 2.3.4+dfsg-1 was packaged in debian. * What exactly did you do (or not do) that was effective (or ineffective)? Should we keep non-BSL licenced version (A) or drop it (B)? * What was the outcome of this action? Plan A. - Update to 2.3.7 and hold it. (2.3.7 is the last non-BSL licenced version) - Follow a newer version only when BSL limitation expired (4 years). - As a result, we can't use newer feature in timely manner if you stick on packaged vagrant in Debian. Plan B. - Drop vagrant because of that changed licence and no need to keep older vagrant. - No vagrant avaiable in Debian. Just use upstream's package. * What outcome did you expect instead? N/A
Plan C. - Move BSL-licenced versions of vagrant into debian's non-free section.
Hi, FWIW, I have been maintaining vagrant in Debian for several years. Thank you for raising this as I have been too lazy to push this discussion. I am copying the Debian Ruby team plus all the people that I could find listed as maintainer or uploader of vagrant related packages (mostly plugins, vagrant-*, but also other related packages) so that they are aware. TL;DR: I will not be maintaining vagrant anymore. of my time is made effectively non-free by its corporate upstream. The first time was with Chef: while the license itself was not changed, they started imposing trademark-related requirements that would impose a large amount of busywork to keep something that looks like Chef (Cinc, their "community" fork) in Debian. I decided to just give up, and moved on to using something else. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959981 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963750 This is now my second time with this, and this time HashiCorp actually made new versions of vagrant non-free. I have used Chef Inc and HashiCorp stuff for free for several years, but I also put in a large amount of work to make their tools available trivially to Debian users by taking care of those packages in the Debian archive. Both Chef Inc and HashiCorp care a lot about having people that use Debian consuming their products, so much so that they provide binary packages for Debian. But they don't care at all about the time of downstream maintainers, and why would they? They are private companies trying to maximize their profit at the expense of whoever is in their way. In this case, HashiCorp is apparently trying to counter other companies who are selling solutions based on their tools that compete with them, they have no incentive to care about the time of a few individuals. I don't see this change as a particularly evil move, but it effectively destroys my motivation to continue working on it. I had already looked into this, even before the relicensing being announced, and it turns out that vagrant 2.3.7 has a few extra dependencies that would need to be packaged too (something like 3 or 4 NEW packages), and I wasn't ready to put the necessary work in yet. After the news came out, I gave up on doing it entirely, since after this vagrant would be a dead end. I think keeping a stale version of vagrant in the archive is worse than telling people to just use upstream packages. As far as my volunteer time is concerned, this is the most likely outcome. I have some private notes on my requirements for a vagrant replacement, and when I reach a conclusion I will most probably pursue this path and just move on. I will not maintain any packages in non-free. Hopefully, being burned a second time will teach me to not put my volunteer time in non-copyleft packages provided by a single corporation.
Please consider officially orphaning the package if realistically you are the only maintainer of this package. This should help increase the visibility of the problem and make users think more about whether using vagrant from debian is the right solution to whatever they may be trying to achieve.
Hi, This license change is so disappointing... do about Debian Vagrant images provided on Vagrant Cloud (https://app.vagrantup.com/debian/) ? A/ continue to maintain them. But as the main uploader of those images in the recent times, I might not continue to maintain them, especially if I move to another tool for my own uses, so we might need to look for other volunteers. B/ stop maintaining them B.1/ ... and remove existing images from the 'debian' Vagrant Cloud account B.2/ ... and leave the 'debian' Vagrant Cloud account as it is currently I don't think B.2 is a good idea. Note that the fact that Vagrant was using a non-copyleft license is not entirely relevant. The same relicensing could be achieved by organizations using a copyleft licence with a copyright transfer agreement for external contributions. (I suspect that this is how it was achieved for other Hashicorp products, but I haven't checked). Lucas
I agree. Just as we provide cloud images for proprietary platforms, I think we as a project want to control what is available as "Debian" for Vagrant users, just like we do with images targetted at proprietary cloud platforms. Yes, that's true.
Hi! BTW, thank you for having done that, it's been much appreciated! […] […] […] There's perhaps a: Plan D. - Package Vagrunt (https://github.com/vaagrunt/vagrunt) a fork of Vagrant, that is stated should remain free software. And as it does not have a CLA, if it gets several contributions it will be increasingly hard to relicense. - Transition from vagrant to vagrunt via a transitional package. (We use Vagrant at work, and I'm not planning on relying on a non-free tool, so a fork would do, otherwise I'd have to look into alternatives for us to switch to.) While it's certainly true that contributing into a project with single-corp-control + non-copyleft has uncertain odds to take, at least everyone is on the same footing. I think, as Lucas has mentioned, the most problematic aspect in this kind of cases is where there are both single-corp-control and a CLA, as that's what grants the possibility of a relicense and this asymmetrical relationship, which could have happened here as well even with a copyleft license. (Out of principle I never sign CLAs for my volunteer work, with the exception of the one for the FSF due to its nature and its assurances, but which I supposedly rescinded some time ago anyway.) Thanks, Guillem
I have seen this a couple of days ago. So far vagrunt is vaporware. The GitHub user which created has -- as far as I looked, i.e. on GitHub itself -- 0 contributions to Ruby projects. I'm also not confident that it will be easy to keep up with e.g. new VirtualBox versions without effectively infringing on HashiCorp copyrights. I will love to be proven wrong, but I'm not holding my breath here.
Hi, An update on this: I plan to take care of the Debian vagrant package (in the framework of the Ruby team, as this is currently done). I uploaded the latest free version of Vagrant to unstable/testing (2.3.7+git20230731.5fc64cde+dfsg-2). Of course help is welcomed. An easy and useful entry point is to look at existing bugs, try to reproduce them with the latest version, and report back. I do not plan to package the non-free versions of Vagrant. I also plan to continue to take care of the Debian Vagrant images, including ensure that they work with the version of Vagrant in Debian. I also looked a bit at potential alternatives. A project with a good potential is Incus (a LXD fork by the original LXC/LXD main developer). It is easy to install, and it provides both VMs and containers support. However currently it does not provide an equivalent to a Vagrantfile (to describe the infrastructure to create, what to execute on nodes, etc.). There's a terraform/opentofu provider, but that doesn't sounds very exciting regarding complexity. I raised that topic in https://discuss.linuxcontainers.org/t/incus-as-a-vagrant-replacement/19586 but the discussion did not go anywhere interesting. Maybe a third party project could create an incus frontend that provides a Vagrantfile-like interface. Given infinite free time, I would likely work on that. :) Lucas
Hi, did you consider to patch for Virtualbox 7.1 support? It should be quite immediate, I don't see any specific problem in the provider, I could provide a patch agains 3.7 series just in case...
Hi, A patch would be great. For now Virtualbox 7.1 is not in unstable yet. Lucas
Here it is.
Sorry, I missed the update of the Log4r logger name, this is a bit better. Just to clarify I'm using it under stable with 7.1, apparently there are no special issues as for some past versions.
Hi, I worked on an Vagrant-inspired Incus-frontend, called Incant: https://github.com/lnussbaum/incant/ Incant is probably too new to ship it in Debian trixie, but I think that it can reasonably meet use cases where Vagrant was useful. If feedback is positive, I will package it in Debian and plan to provide it through backports. But that also means that I've lost interest in maintaining or using Vagrant in Debian. Also, the HCP episode in January (see #1092987), where downloading boxes was broken for free versions of Vagrant for several weeks, shows that we should not expect HashiCorp to be extremely helpful with maintaining free versions of Vagrant. I therefore think that it's better not to ship Vagrant as part of trixie, and am raising the severity of this bug to 'serious'. If someone commits to maintaining it, feel free to dowgrade the severity again. Lucas
Lucas Nussbaum: Thanks for all the maintenance over the years! With F-Droid, we'll be stuck on Vagrant for a while longer. So I figure I'd put my effort into maintaining the packages in Debian rather than elsewhere. I recently when through all the relevant plugins (e.g. vagrant-libvirt) to fix bugs to they make it into trixie. That said, F-Droid's usage of Vagrant is basically limited to libvirt. We don't use it with cloud services or Docker. In the meantime, we've completing an architectural overhaul that makes it easy to swap container/VM backends for our buildservers. Right now, we support Vagrant and Podman. The incident that broke downloading boxes was actually inspiring to me, because there was rapid cross-distro collaboration for how to fix it. I also want to maintain this because I don't want to let Hashicorp win that easily. We should demonstrate that free software communities won't just sheepishly go along with companies that build up value based on free software communities, then take it proprietary to cash in. .hc
Hi Filippo, I tried to update the image, but again ran into issues with authenticatiing on the Hashicorp cloud. This is so frustrating. Back in January, HashiCorp broke authentication for free versions of Vagrant for several weeks (<< 2.4), and I had to use the non-free version to update the image. I still managed to upload the new version manually using the web interface. As I said in #1049999, I gave up on maintaining Vagrant. I'm also giving up on maintaining Debian images. If someone wants to take over, the tooling at https://salsa.debian.org/cloud-team/debian-vagrant-images/ still works (except for the upload part) and I can walk you through it if needed. But Vagrant is now non-free, has a limited future in Debian, and I would urge anybody looking at it to investigate alternatives. Personnally, I switched to Incus and since I missed a declarative way to describe my environments, I wrote Incant, a Vagrant-inspired frontend that brings that to Incus. (See https://github.com/lnussbaum/incant/) Also Incus has an image for Debian trixie uploaded on a regular basis (daily I think). Lucas
Hello Lucas, Thank you for that -- much appreciated also given how many hoops uploading requires now :( I was already planning on moving away from Vagrant and this might be the last straw, I'll be looking at Incus and Incant best, Filippo
Hello, Upgrading linux kernel to linux-image-6.16.3+deb14-amd64 was broken because it failed to build the Virtualbox kernel module. I upgraded virtualbox as well to version 7.2. It solved the problem, but it removed Vagrant because it was incompatible with virtualbox 7.2. I used Francesco's patch to add support for virtualbox 7.1, I also added the same kind of patch for 7.2 (there is also this kind of commit upstream: https://github.com/hashicorp/vagrant/commit/4978fab04546b74ccf4ef9664d910b76d55c54dd) and built the package locally. It seems it works fine. Could you please add a patch to support virtualbox 7.2 and upload to unstable? Philippe.