Dependency - SixLabors License Change #10663

4 Answer(s)

• 

  0

  AI-Bot created 4 months ago

  Support Team ABP Agent

  • ABP currently provides an image manipulation abstraction (resize/compress) and ships implementations based on ImageSharp and Magick.NET. So, if you pull ABP packages that include the ImageSharp implementation and you force SixLabors.ImageSharp >= 4.0.0, you can hit SixLabors’ license enforcement behavior (the “license file required” build/runtime check you’re seeing).

  • ABP is not “hard-coupled” to SixLabors for image manipulation: the system is explicitly designed to be extensible so you can avoid ImageSharp by:

    1. Not referencing / not using the ImageSharp-based contributor package(s) in your solution, and
    2. Using the Magick.NET-based contributor (or implementing your own contributor) instead.

  • Is there a plan to migrate away from SixLabors?
    I couldn’t find a verified, official ABP statement/roadmap item in the available indexed docs/support context that says “we will migrate away from SixLabors by date X” or “we will drop ImageSharp entirely”. So I can’t confirm a plan from verified sources.

  • Practical options you can apply immediately in your ABP-based solution:

    1. Use Magick.NET instead of ImageSharp for the ABP image manipulation feature.
    2. Implement your own image resizer/compressor contributor and register it, so your solution doesn’t depend on SixLabors at all.
    3. If you only get the issue when compiling ABP itself (not your app), avoid bumping the ABP framework’s ImageSharp dependency to v4+ unless you intend to comply with SixLabors’ licensing requirements.

  If you need an official commitment/decision (roadmap / package changes / licensing stance), that’s not something I can verify from public ABP docs; please contact Volosoft directly: https://abp.io/contact

  (Validated links)

  • https://abp.io/docs/latest/framework/infrastructure/image-manipulation
  • https://sixlabors.com/posts/licence-enforcement-changes/
  • https://abp.io/contact

  ---

  This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created 4 months ago

  Support Team Fullstack Developer

  Hi,

  Quick clarification on the current state: ABP pins SixLabors.ImageSharp to 3.1.11 in Directory.Packages.props. Per the SixLabors announcement, the sixlabors.lic requirement only applies to ImageSharp 4.0.0+, so building ABP itself does not need a license file. The error you're seeing is almost certainly because your own solution is overriding the package to 4.x.

  About our plan: if SixLabors keeps the paid-license model on v4+, we won't upgrade SixLabors.ImageSharp to a paid version. We'll either stay on 3.x or move to a free, open-source alternative.

  You don't need to wait for us though — ABP already abstracts image manipulation behind IImageResizer / IImageCompressor, and ships three independent implementations. You can switch any time:

  | Package | Underlying library | License | |---|---|---| | Volo.Abp.Imaging.ImageSharp | SixLabors.ImageSharp 3.x | Six Labors Split License (free on 3.x) | | Volo.Abp.Imaging.MagickNet | Magick.NET | Apache 2.0 | | Volo.Abp.Imaging.SkiaSharp | SkiaSharp | MIT |

  Just swap the ImageSharp package and module dependency for the Magick.NET or SkiaSharp one — your business code keeps using the same IImageResizer / IImageCompressor abstractions, no code changes needed.

  Docs: https://abp.io/docs/latest/framework/infrastructure/image-manipulation

  Thanks

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  cfd000 created 4 months ago

  The license already requires paying, but they don't break the build with the license file requirement until you target 4.0.0 - if you're using version 3 without paying you're already violating their license - this is their article from 4 years ago: https://sixlabors.com/posts/license-changes/

  If ABP already makes multiple image options available, why not default to SkiaSharp, which has the most permissive license? We pay for source code so we can build ourselves (in case of zero day vulnerabilities that we have to push before a sanctioned fix is available), but any change that requires us to manually manipulate the ABP source directly prior to building is onerous. We would prefer to only build the packages we need without edits.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created 4 months ago

  Support Team Fullstack Developer

  Hi,

  Thanks for the correction — you're right. The Split License has applied since ImageSharp v3.0.0; the v4 .lic enforcement just makes it visible at build time. I shouldn't have written "free on 3.x" without that qualifier.

  Where ImageSharp comes from on our side today:

  • ABP upgraded SixLabors.ImageSharp from 2.1.6 to 3.0.2 in ABP 8.0, pinned at 3.1.11 on dev. We don't plan to move to v4 while the paid-license model stays as it is.
  • The open-source abp/ codebase and all project templates do not reference ImageSharp directly. The transitive reference in a Pro solution comes from Volo.Abp.Account.Pro.Public.Application, which today depends on AbpImagingImageSharpModule to compress user avatars via IImageCompressor.

  Agreed — patching ABP source on every build isn't a workflow we should expect from customers, especially when source access is there for fast zero-day responses.

  Plan for ABP 10.4:

  1. Decouple Volo.Abp.Account.Pro.Public.Application from any specific imaging implementation — it will depend only on Volo.Abp.Imaging.Abstractions. The default implementation will be picked at the application level, so swapping it out won't require touching ABP source.
  2. Add an ImageCompressorContributor implementation to Volo.Abp.Imaging.SkiaSharp (today that package only ships a resizer).
  3. Upgrade Magick.NET-Q16-AnyCPU past the currently reported NuGet vulnerability warnings, assuming an upstream fixed version is available.

  Before 10.4 ships, the simplest workaround: ABP already ships a Magick.NET-based implementation in Volo.Abp.Imaging.MagickNet (Apache 2.0), which provides both compressor and resizer contributors. Reference that package in your own *.Application module, depend on AbpImagingMagickNetModule, and explicitly remove the ImageSharp contributors from the DI container. Just adding DependsOn(AbpImagingMagickNetModule) isn't enough on its own — both contributors would coexist in the container, and ABP's IImageCompressor iterates the registered contributors and uses the first one that supports the input mime type, so ImageSharp would still run at runtime. After RemoveAll, only the Magick.NET contributors remain and ABP's conventional registration picks them up automatically — no custom code needed.

  MyCompanyName.MyProjectName.Application.csproj:

  <PackageReference Include="Volo.Abp.Imaging.MagickNet" Version="x.y.z" />
  

  MyProjectNameApplicationModule.cs:

  using Microsoft.Extensions.DependencyInjection;
  using Microsoft.Extensions.DependencyInjection.Extensions;
  using Volo.Abp.Imaging;
  using Volo.Abp.Modularity;
  
  [DependsOn(typeof(AbpImagingMagickNetModule))]
  // ... your existing DependsOn list
  public class MyProjectNameApplicationModule : AbpModule
  {
      public override void ConfigureServices(ServiceConfigurationContext context)
      {
          context.Services.RemoveAll(d =>
              d.ServiceType == typeof(IImageCompressorContributor) &&
              d.ImplementationType == typeof(ImageSharpImageCompressorContributor));
  
          context.Services.RemoveAll(d =>
              d.ServiceType == typeof(IImageResizerContributor) &&
              d.ImplementationType == typeof(ImageSharpImageResizerContributor));
      }
  }
  

  After that, IImageCompressor and IImageResizer use the Magick.NET contributors at runtime for these interfaces. You can pin the underlying Magick.NET-Q16-AnyCPU to whichever version you've audited.

  One thing to be aware of for license compliance: this RemoveAll only stops ABP imaging services from invoking ImageSharp at runtime. Because Volo.Abp.Account.Pro.Public.Application still has DependsOn(typeof(AbpImagingImageSharpModule)) in 10.3, both Volo.Abp.Imaging.ImageSharp.dll and SixLabors.ImageSharp.dll will still be restored and copied to your build output as transitive dependencies. The transitive package reference itself will go away in 10.4 once we decouple the Account module from a specific imaging implementation. Whether the runtime-only avoidance is enough for your compliance position is a call you'll need to make against the Six Labors Split License terms.

  If neither ImageSharp nor Magick.NET works for you, IImageCompressor / IImageResizer (and their IImageCompressorContributor / IImageResizerContributor) are plain DI abstractions — you can register your own implementation backed by any library you trust (NetVips, libvips wrappers, your own code, etc.) in your own module. Outside the current Account.Pro module dependency in 10.3, the imaging services are abstractions you swap at the application level; the Volo.Abp.Imaging.* packages are just convenience implementations on top of those abstractions.

  Thanks

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel