[License Exception Request] Packer for image-builder

[AverageMarcus]

The image-builder project relies on the use of Packer (as a pre-built binary) to provision VMs to be used for building the OS images.

The recent HashiCorp license change means this is now covered by the BUSL v1.1 license so we'd like to request a license exception for this dependency.

As far as we understand it, the image-builder project is still considered acceptable under the new license but would love a second opinion on that if available. The main aspect we're still unclear about is if including the Packer binary within our container image is considered "embedding" and falls foul of the license.

The use of Packer is currently essential for the image-builder project and having to migrate to something else (if anything suitable actually exists currently) would be a large undertaking. For now, we've pinned our dependency to v1.9.2 which is the latest release covered by the old license.

Resources:

• Tracking issue: Investigate implications of new Packer licensing kubernetes-sigs/image-builder#1246
• Relevant entry in the HashiCorp FAQ: https://www.hashicorp.com/license-faq#non-competitive-oss-usage
• Slack thread discussing the impact of this change on image-builder (which lead to this request being submitted): https://cloud-native.slack.com/archives/C0MP69YF4/p1692108926999039

[amye]

https://github.com/cncf/foundation/blob/main/source-available-recommendations.md#recommendations may be helpful here.

[AverageMarcus]

@amye We're already following that advice and that has what has lead to raising this request.

There is no suitable alternative to switch to at this point in time and we've pinned the version for the time being but that is only suitable until the end of the year when HashiCorp stop offering security fixes backported.

[krook]

On March 21, 2024, the Governing Board decided to reject this exception request because BUSL-1.1 is not an open source license.

[AverageMarcus]

@krook just for clarification - does that then mean that we're also unable to use Packer as a runtime dependency even if we find a way to no longer package and distribute it with our project? As in, must we completely stop our usage of Packer within the project?

[fabriziopandini]

If I can give my 2 cents, there might be a misunderstanding around "use Packer as a runtime dependency"

The key point:

The main output of the image builder project is a set of images (OVA, ami etc), this is why the project exists.
Those images (OVA, ami etc) do not have packer embedded or they don't use packer as a runtime dependency.

The project mainly uses packer during the build process to create the above images. Preserving the capability to use packer as a build/ci tool is what is important to the project, and we are not using it as a runtime dependency (it is only used during the build project).

There is also something is less crucial we should consider:

In order to make the build process easier locally by eliminating the need to manually install and maintain pre-requisite packages like Ansible, Packer, libraries etc., on users machines, the project also generates a "commodity image"
that in this case embeds the packer binary. Also in this case, the "commodity image" is just an alternative tool to build target images.

I understand that this is not ideal, but in case this can help in addressing the issue, IMO the image builder project can consider stopping publishing those "commodity images". Users can always install the required tools locally, or eventually build the "commodity image" locally if they prefer.

TL;DR;

I hope that the above comments might help in clarifying that:

• the image builder project is not using packer in production, only at build time (All non-production uses are permitted).
• maintainers can eventually drop the "commodity image" who embeds packer if this is controversial, and still preserve the main goal of the project, which is to build images (OVA, ami etc) who don't embed packer at all.