SixLabors.ImageSharp is pinned at 3.1.12 and Blurhash.ImageSharp at 3.0.0 in
src/Directory.Packages.props. They were held back in #187 because ImageSharp 4 cannot be built
without a licence key.
What actually happens
SixLabors.ImageSharp.targets(28,5): error : No Six Labors license found.
Set $(SixLaborsLicenseKey), set $(SixLaborsLicenseFile), or add a 'sixlabors.lic' file
to the project/workspace.
Please obtain a license from https://sixlabors.com/pricing/
🔴 This is an ERROR in Release and only a WARNING in Debug. That asymmetry is the trap: a
local dotnet build src/ looks fine, and the failure appears in the Worker image, whose
Dockerfile builds -c Release. It is also why the Docker jobs are the only place CI catches it —
they needs: build-and-test, so they are skipped on any run that is already red.
The licence did not change; the enforcement did
Both 3.1.12 and 4.1.2 ship the same Six Labors Split License 1.0. What 4.x adds is a
build/SixLabors.ImageSharp.targets that enforces a key at build time — 3.1.12 ships only a
.props with no such check. So this is not a new licence to evaluate so much as a key to
provision.
The two packages move together
Blurhash.ImageSharp 4.1.1 takes a hard dependency on SixLabors.ImageSharp 4.1.1, where
3.0.0 only floors at >= 2.0.0. Upgrading either forces the other, so they are held as a pair.
What adopting v4 would require
- A key from https://sixlabors.com/pricing/ — determine whether this project qualifies for a
free/OSS tier under AGPL-3.0, or whether it is a paid licence
$(SixLaborsLicenseKey) (or a sixlabors.lic) reaching two places, not one: the CI job,
and the Worker docker build — the latter needs it as a build secret, and ⛔ a build arg
would bake the key into image history
Options
- Stay on 3.x (current state). No key, no credential in the build. Accepts that 3.x will
eventually stop receiving fixes.
- Provision a key and thread it through CI and the Docker build.
- Replace ImageSharp. Largest change — it backs the proxy generators, the EXIF path and
blurhash generation.
No action is required for v1.0; this is recorded so the holdback is a decision rather than drift.
Context: #187.
SixLabors.ImageSharpis pinned at 3.1.12 andBlurhash.ImageSharpat 3.0.0 insrc/Directory.Packages.props. They were held back in #187 because ImageSharp 4 cannot be builtwithout a licence key.
What actually happens
🔴 This is an ERROR in Release and only a WARNING in Debug. That asymmetry is the trap: a
local
dotnet build src/looks fine, and the failure appears in the Worker image, whoseDockerfile builds
-c Release. It is also why the Docker jobs are the only place CI catches it —they
needs: build-and-test, so they are skipped on any run that is already red.The licence did not change; the enforcement did
Both 3.1.12 and 4.1.2 ship the same Six Labors Split License 1.0. What 4.x adds is a
build/SixLabors.ImageSharp.targetsthat enforces a key at build time — 3.1.12 ships only a.propswith no such check. So this is not a new licence to evaluate so much as a key toprovision.
The two packages move together
Blurhash.ImageSharp4.1.1 takes a hard dependency onSixLabors.ImageSharp4.1.1, where3.0.0 only floors at
>= 2.0.0. Upgrading either forces the other, so they are held as a pair.What adopting v4 would require
free/OSS tier under AGPL-3.0, or whether it is a paid licence
$(SixLaborsLicenseKey)(or asixlabors.lic) reaching two places, not one: the CI job,and the Worker
docker build— the latter needs it as a build secret, and ⛔ a build argwould bake the key into image history
Options
eventually stop receiving fixes.
blurhash generation.
No action is required for v1.0; this is recorded so the holdback is a decision rather than drift.
Context: #187.