Should ImageSharp extension packages avoid introducing ImageSharp as a transitive dependency?

[skttl]

Hi James and team,

I maintain ImageSharpCommunity.Providers.Remote, an open-source NuGet package that extends ImageSharp with support for remote image providers.

With the new licensing requirements in ImageSharp v4, I've been thinking about how extension packages like mine should handle their dependency on ImageSharp.

I understand that I'll need a Community License to build my package against ImageSharp, which is perfectly fine.

However, there's an interesting edge case with the transitive dependency exception in the Split License.

The scenario

Unlike something like Umbraco, which uses ImageSharp internally to provide image processing functionality, my package is specifically designed to extend ImageSharp itself.

Currently, my package has a regular dependency on SixLabors.ImageSharp.

This means a commercial application could potentially:

1. Install ImageSharpCommunity.Providers.Remote without referencing ImageSharp directly.
2. Get ImageSharp automatically as a transitive dependency.
3. Use ImageSharp APIs directly, even without using any functionality from my package.
4. Avoid the direct-dependency licensing requirements.

I understand from #2151 that this kind of transitive dependency loophole has previously been acknowledged as a potential trade-off in the licensing model.

A possible approach

I've been considering changing my ImageSharp dependency to use PrivateAssets="all", so my package would no longer introduce ImageSharp transitively into consuming projects.

The consuming application would then need to provide ImageSharp itself, either:

• As a direct dependency, with whatever licensing requirements apply.
• Through another dependency, such as Umbraco, where ImageSharp is already included transitively.

I could potentially add an MSBuild target to validate that ImageSharp is available in the consuming project's dependency graph.

The intention wouldn't be to enforce SixLabors' licensing rules myself, but simply to avoid my extension package becoming an unintended way of obtaining ImageSharp without a direct reference.

My question

Is this something you'd recommend extension package maintainers do, or is it unnecessary?

Would you prefer that packages like mine avoid introducing ImageSharp as a transitive dependency, or is the current approach perfectly acceptable and consistent with the intended licensing model?

I'm happy to continue with the existing dependency setup if this is an intentional and accepted consequence of the Split License.

I'd just like to make sure I'm following the spirit of the licensing model rather than introducing an unintended workaround.

Thanks for your work on ImageSharp!