Security Support and License Enforcement

Today we are announcing expanded security support for Six Labors libraries, giving users greater flexibility to upgrade on a schedule that works for them.

We are also making Six Labors easier to use in open-source and source-available projects. New assembly-scoped community keys can be committed to a public repository, so contributors can build the named projects with the included key. Maintainers can share that key openly instead of managing it as a private build secret.

Previously, security updates were available only for the latest major version. Under the expanded policy, each major version will remain eligible for security updates for 12 months after the first stable release of its successor. This gives teams more time to plan, test, and deploy major version upgrades while keeping their existing applications secure.

To make this extended support sustainable, new releases within supported older majors will include the build-time license enforcement already used by the current major versions.

Enforcement is not a license change. ImageSharp v3 and v4 use the same Six Labors Split License. The requirement to purchase a commercial license, where applicable, already exists. A license key makes that requirement enforceable during the build.

Why we are making this change #

Over the last six months, ImageSharp v3 has accounted for around 95% of ImageSharp downloads on NuGet, despite v4 having been available for several months. V3 also targets .NET 6, for which Microsoft ended support on 12 November 2024.

Maintaining older versions takes time. Backporting security fixes means maintaining the code, build infrastructure, and release process for each supported version. We cannot sustain that work if organizations that are required to purchase a license continue using the libraries without paying.

Organizations that comply with the license support the continued development and maintenance of the libraries. Consistent enforcement ensures that organizations required to purchase a license contribute to that work.

We want users to be able to install security updates without immediately moving to a new major version. Extending enforcement to the maintained older versions makes that work more sustainable.

What changes #

The upcoming releases bring security fixes to supported older major versions of Six Labors libraries. These releases will also require a valid license key for projects that directly reference the packages. For ImageSharp v3, these changes arrive in ImageSharp 3.2.0.

Our previous announcement described enforcement starting with future major releases. We are now extending it to new releases within supported older majors as well. This changes the build requirements for those releases. It does not change their license terms.

Existing published packages are not being modified. To receive the security fixes, you need to install the updated package and configure a valid key.

If you already have a valid Six Labors key, use it. If you qualify for a community license, you can apply for a free key. If your use requires a commercial license, you can purchase one.

Security support #

The latest major version of each library remains eligible for security updates until its successor is released. It then remains eligible for another 12 months, measured from the successor's first stable release date.

The same policy applies to every Six Labors library. Each library has its own release dates and support deadlines.

Example: ImageSharp support dates #

Each major version has its own deadline. A v5 release before 12 May 2027 would not change v3's deadline.

After its deadline, a major version is end-of-life and no longer receives security updates.

Within a supported major, you must install the latest available patch or minor release to receive the fixes. For v3, this means upgrading to ImageSharp 3.2.0.

This policy covers security fixes. It does not include feature backports or extend Microsoft's support for the underlying .NET version. Security fixes remain at Six Labors' discretion.

Community keys built for open-source collaboration #

Currently, each contributor to an open-source or source-available project needs their own license key to build projects that directly reference Six Labors packages. The maintainer cannot commit an unrestricted key to the public repository, so every new contributor must obtain and configure their own key before they can build and test those projects.

With assembly-scoped community keys, maintainers can commit a single key to the public repository for contributors to use. The key is valid for the assembly names registered in the application, so sharing it does not make it an unrestricted key for other assemblies.

That gives projects a simpler way to work:

• Contributors can use the included key to build the named projects without applying for their own key for those assemblies.
• Forks can use the same key while retaining the registered assembly names.
• CI can use the committed license file without storing that key as a secret.

This brings the license configuration into the repository alongside the code. Maintainers can configure it once and share it with everyone contributing to the named projects. The key still has an expiry date and must be renewed.

New open-source and source-available applications must provide the exact assembly names of the projects that will use the key.

For example, if your project contains:

<PropertyGroup>
  <!-- Use this exact value when applying for an assembly-scoped key. -->
  <AssemblyName>MyProject.Core</AssemblyName>
</PropertyGroup>

The application needs the assembly name of each project that directly references a Six Labors package. Enter one name per field.

• If MyProject.csproj sets <AssemblyName>MyProject.Core</AssemblyName>, enter MyProject.Core.
• If MyProject.Core.csproj does not set AssemblyName, enter MyProject.Core. The project filename supplies the default assembly name.
• If both MyProject.Core.csproj and MyProject.Tests.csproj directly reference Six Labors packages, add two fields: MyProject.Core and MyProject.Tests.

Enter the name without .dll or .csproj. Use the exact capitalization. This is the assembly name, not the namespace, solution name, or Six Labors package name. If a shared props file sets AssemblyName, use that value.

Existing community license holders can request one early replacement with an assembly-scoped key. These upgrade requests are approved automatically, without another eligibility review. You do not need to wait for your current key to enter its renewal window.

Select open-source or source-available, use the same email address, and provide the exact assembly names. Later requests follow the normal renewal window: the final 90 days before the expiry date in your license. Commercial licenses are not eligible for this early replacement.

Unrestricted keys must remain private.

Configure the build #

Use the supplied sixlabors.lic file without changing its contents. Place it in the project directory, or set its path in the project file or a shared props file:

<PropertyGroup>
  <!-- Set the path to your supplied license file. -->
  <SixLaborsLicenseFile>path/to/sixlabors.lic</SixLaborsLicenseFile>
</PropertyGroup>

For environment variables, CI secrets, and other build configuration options, see the license configuration documentation.

We will continue to provide security updates within this support window, giving users time to plan major version upgrades. This policy supports that work through consistent enforcement of the existing license terms.

• Previous: Fitting Type to the Pixel Grid