HashiCorp license change
HashiCorp just changed the license of its software to the Business Source License 1.1 (SPDX identifier BUSL-1.1) [1][2][3]. This change affects:
- community/terraform
- community/packer
- community/vault
- community/consul
- community/nomad
As a not-yet-member of the-not-yet-official license team, I would like to try to clarify the new license a bit:
The new license is not open source.
On the SPDX license page [4], the notes clearly states:
The Business Source License [...] is not an Open Source license.
This sentence also appears on the MariaDB page of the license [5], who created it in the first place.
Fedora gives further evidence, as this license is in the list of Not-Allowed Licenses [6].
The Licensor hereby grants you the right to copy, modify, create derivative works, redistribute, and make non-production use of the Licensed Work.
The word that makes this license not opensource is non-production, which violates point 6 of the OSD [7] as well as the proposed Alpine license policy [8] "No Discrimination Against Fields of Endeavor". Production is a part of a Field of Endeavor, often a business.
In conclusion, I don't think we can allow the new versions of HashiCorps software in aports. I would suggest to not update these packages as long as no one complains, since the current versions are still open source. When the demand gets high we could switch to forks which are still active and look like they might be further maintained.
[1] https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license
[2] https://www.hashicorp.com/license-faq
[3] https://www.hashicorp.com/bsl
[4] https://spdx.org/licenses/BUSL-1.1.html
[5] https://mariadb.com/bsl11/
[6] https://docs.fedoraproject.org/en-US/legal/not-allowed-licenses/
[7] https://opensource.org/osd/
[8] https://gitlab.alpinelinux.org/lmarz/license-policy/-/blob/main/policy.md
Activity
I asked about this in alpine-devel IRC a few hours ago and a brief discussion ensued.
The word that makes this license not opensource is
non-productionIt is a bit more complicated as https://www.hashicorp.com/license-faq states:
- What is the Business Source License (BSL, or BUSL)? ... Non-production use of the code is always free, and the licensor can also make an Additional Use Grant allowing production use under specific restrictions.
and
- What are the usage limitations for HashiCorp’s products under BSL?
All non-production uses are permitted. All production uses are allowed other than hosting or embedding the software in an offering competitive with HashiCorp products or services.
so Hashicorp are making an "Additional Use Grant".
It would seem that the stable branch for vault (used in Alpine v3.18) does not have a new license (yet?): https://github.com/hashicorp/vault/tree/release/1.13.x
But I guess we can not back-port any commits, but possibly OK if their own employees back-port!?
For the upgrade to 1.13.5 I see no issue, since this release was before the license change.
For future releases: As long as they don't backport commits with the SPDX-Identifier
BUSL-1.1in them, we can assume that these commits are additionally licensed underMPL-2.0, like the rest of the branch.But yeah, only officially backported commits count.
marked this issue as related to #15200 (closed)
mentioned in issue #13082 (closed)
@ncopa sent an e-mail to Hashicorp to get their stance. Their response:
We address this in the FAQ (Q12, 13). Since you are only redistributing it, this is allowed under BSL. The restriction around redistribution is covered in Q15 of the FAQ but that does not seem to be the use case here so please continue to include our products as part of your distro packages.
In the meantime, regarding terraform: https://opentf.org/announcement
mentioned in merge request !52011 (merged)
mentioned in merge request !52139 (merged)
mentioned in issue #15297 (closed)
I think the precedent here is mongodb (I can’t seem to find the link to that conversation though); their change to SSPL resulted in them being dropped from the distro. While I’m not personally a fan of this, as the maintainer of the Vault package, I also don’t think it’s a good idea for us to carry non-free software.
That being said, the counter-argument would be that their FAQ relies heavily on “competitive offering” and a Linux distribution is not a “competitive offering”, nor really could it be, with the products licensed under the BSL. The other words they use such as “non-production” are really between the consumer’s opinion of their use and Hashicorp. The packager of their software isn’t involved in that relationship and should be able to safely redistribute it; how people consume the packaged software is up to them.
Furthermore, I disagree that this license restricts “Field of Endeavour” in its use of the word “non-production”. Production is a stage of use not a field of use. If you were to use the software in any field you could do so, according to the license, so long as you don’t deploy it to a “production” environment.
Interestingly, neither their license nor FAQ define what “production” actually means.
Reading the Vault LICENSE file more closely, it seems that the additional usage grant does specifically allow production use provided:
You may make production use of the Licensed Work, provided such use does not include offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with HashiCorp's products.
So I guess that’s directly against “Free Redistribution” of the software in the proposed license policy.
Regardless of the outcome here; it would be really nice to have a documented, ratified, license policy. It would also be nice to have a decision log with documented rational for some of these eviction decisions so that future conversations of this type have a set of examples to use for considering their decisions.
zerotier-one was removed due to BSL: 7f7b355d
As a tiny nit to remove any possible confusion, the commit should read "BUSL-1.1". "BSL-1.1" doesn't exist but may be confused with "BSL"/"BSL-1.0" (Boost Software License) which is FSF and OSI approved.
Edited by Steven Guikal
mentioned in merge request !50732 (closed)
Vault has been updated to 15.1
I don't yet see consensus here on what the correct approach is for BUSL licensed packages but given than Vault is a security sensitive package for users I don't want to leave it lingering at old versions. I have no objections if we decide to drop it from the distro but I'm not in favor of letting it go stale.
Edited by Mike Crute-
Regarding terraform specifically: I would prefer if we leave the latest FLOSS version in community until OpenTofu has a stable release and is promoted to replace it.
In future, I think it might be wise to add
replaces="terraform"toopentofu.The release channels I guess will have to stick to the last FLOSS terraform version.
-
In future, I think it might be wise to add
replaces="terraform"toopentofu.Why? Are they expected to have conflicting files?
marked this issue as related to #15410 (closed)
The fact is that historically Alpine has only shipped binaries of free software. This is important because it is one of the reasons why users can depend on Alpine -- they have security in the knowledge that Alpine will not provide them with software that carries the risks associated with non-free software.
Vault should be downgraded back to the free version unless there is a known security vulnerability, in which case the security team should attempt to backport the patch, or Vault should be dropped from the distribution.
There are some CVEs that are fixed in the most recent version so I don't think downgrading is the right option. Given that Vault is a security sensitive piece of people's infrastructure, I do not think it's correct for a distribution to maintain local backported security patches; that's really the place for a full fork of the software.
I would be happy to hand-over maintenance of this package to someone who has the time and experience to carefully backport security fixes. However, both as a maintainer and a consumer of Vault I would much rather see Alpine drop the package rather than backport security fixes and I would not consume this package if we decided to go with the backport approach.
Does anyone object to just dropping Vault at this time?
-
Not being comfortable maintaining backported security patches is fair (also some may be under BUSL licenses so you would have to write them yourself IIUC). You're the maintainer and other packages have been dropped for BUSL (and I agree with everyone's reasoning to drop it here). I think you can drop it.
In the absence of any objections by 18:00 PST I will remove the Vault package.
Edited by Mike Crute
-
The other words they use such as “non-production” are really between the consumer’s opinion of their use and Hashicorp.
This is the risk. What Hashicorp says is "fine" today may not be "fine" tomorrow. The risk was never to Alpine for the act of physically redistributing this software, but rather to the consumer.
The packager of their software isn’t involved in that relationship and should be able to safely redistribute it; how people consume the packaged software is up to them.
While I can understand the logic behind this argument, part of the role of the distribution is to help to de-risk the consumption of software by ensuring it is well-integrated and tested.
Accordingly, the distribution in its role as a de-risking tool, has an ethical obligation to distribute only software which does not carry risk to consume on its own, especially in the context of a FOSS distribution like Alpine where the expectation (and therefore legal risk profile) is that all software included is FOSS.
changed milestone to %3.19.0
mentioned in merge request !54482 (merged)
removed Low label
This should be mentioned in the 3.19 Release Notes - that Vault has been removed and so this will affect anyone already using Vault and expecting to upgrade.
I have not yet removed Nomad from Alpine and again I'm concerned about how such a removal would be communicated to existing users, especially it I remove if before the Alpine 3.19 release.
I expect the Vault (and Nomad, Consul, etc) removal in Alpine 3.19 will result in some/many Issues/complaints, especially from Docker users who likely don't read the Release Notes.
Edited by Dermot Bradley
i added a short mention to https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.19.0 - should that also mention that security updates for other HashiCorp packages might be only backports / might not happen at all?
