Request: consider dual licensing for GPLv2 compatibility

[adamsilverstein]

Hello libultrahdr team!

I am a WordPress core committer, currently working on a project to bring modern image processing to WordPress via client side media processing and would love to add support for UltraHDR images to the ~35+% of the web using WordPress. However the current Apache2.0 license is not compatible with the WordPress GPLv2 license (I am not a lawyer, but have confirmed this with one). Would you consider dual licensing under the Apache License 2.0 and BSD 3-Clause?

A maintainer of the libvips library suggested this in a comment, mentioning that Highway took a similar approach to ensure compatibility with NumPy's BSD-3 license (see e.g. the removed licensing paragraph in commit numpy/numpy@f09ab71).

If this is not feasible we will not be able bundle UltraHDR support directly with WordPress (forcing users to install a separate plugin to get support) which would be a huge loss for the web, one of the main potential beneficiaries of UltraHDR imagery.

cc: @gregbenz

[adamsilverstein]

If the licensing can't be changed we will either build without ultrahdr support (requiring a plugin to use ultrahdr), or use the new GPL compatible version I built with help from Claude: https://github.com/adamsilverstein/lib-open-ultrahdr

[ram-mohan]

update: the request was communicated to code owners. awaiting their response.

[adamsilverstein]

Friendly ping for updates?

[kleisauke]

FWIW, wasm-vips v0.0.17 was released today and now builds against libultrahdr.

If you need to avoid this dependency, you can disable it using the --disable-uhdr flag or alternatively pin wasm-vips to v0.0.16 or earlier. See also:
https://github.com/kleisauke/wasm-vips/blob/master/THIRD-PARTY-NOTICES.md

[gregbenz]

@kleisauke Great to see that. I just created a test page using wasm-vips v0.0.17 and see great results using both sRGB and P3 test images with tests to recompress, resize, crop, and flip horizontally. Seems to produce valid output in all scenarios I've tested.

However, I do not see a parameter to control quality of the gain map. It stays at high quality when it could allow for compression. Ideally, we would have an option to compress that (probably some default value based on the main quality, but with an option to override). If there is a better place to raise the discussion, please let me know (I see only issues not discussions active for wasm-vips).

@adamsilverstein How are quality parameters set in WordPress and passed on to wasm-vips? I'm happy to do some testing now based on the parameters you would use by default to check and see if they should be refined for gain maps.

[kleisauke]

However, I do not see a parameter to control quality of the gain map. It stays at high quality when it could allow for compression. Ideally, we would have an option to compress that (probably some default value based on the main quality, but with an option to override).

The JPEG compression factor can be controlled using the Q argument of image.uhdrsave(). It appears that this optional argument is missing from the docs at https://www.libvips.org/API/current/method.Image.uhdrsave.html, it need to be regenerated after commit libvips/libvips@b5c6241. I'll fix that.

If there is a better place to raise the discussion, please let me know (I see only issues not discussions active for wasm-vips).

For general image processing questions not specific to wasm-vips, it's best to ask them at https://github.com/libvips/libvips/discussions, which is the right place for such topics.

[temcguir]

Thanks for reaching out and for the detailed context!

I'm stepping in to help out while the code owners are currently out.

I've taken a look at your request and am currently checking with our internal open source licensing team to confirm if this dual-licensing approach is something we can implement for this repository.

I'll follow up here as soon as I have more information or next steps. Thanks for your patience in the meantime!

[temcguir]

@adamsilverstein I've confirmed with our open-source licensing team that dual-licensing should be possible.

Internally, our most common and preferred structure for dual-licensing (which we use heavily in the Rust ecosystem) is an Apache 2.0 / MIT dual license.

Since the MIT license is also fully compatible with GPLv2, would an Apache 2.0 / MIT dual license work just as well for WordPress instead of BSD 3-Clause?

[adamsilverstein]

Excellent news @temcguir! Thanks.

Since the MIT license is also fully compatible with GPLv2, would an Apache 2.0 / MIT dual license work just as well for WordPress instead of BSD 3-Clause?

I believe so although I will also try to verify that with someone who has more professional expertise.

[adamsilverstein]

Since the MIT license is also fully compatible with GPLv2, would an Apache 2.0 / MIT dual license work just as well for WordPress instead of BSD 3-Clause?

I verified the answer is yes, given the license covers the whole library.

I will open a PR. It would be great to have this changed by July 1 so we can include it in WordPress 7.1.

[adamsilverstein]

@temcguir I opened #386 for your consideration