As some JPEG XL files can be stored in an ISO BMFF container, they’re unfortunately in the same boat currently as CR3/HEIF/AVIF w.r.t. parsing by Exiv2 and the issues described above.
The IP situation of the actual JPEG XL codec is an entirely different matter and out of scope for Exiv2. I have not looked into it as I have not yet seen any formal warnings like above, just forum posts saying there might be some related patents out there, and contrary claims by the JPEG XL interest group claiming there is no encumbrance.
But, IANAL, and would really prefer that some legal expert eventually sorts this out for the community.
I don’t need to. I don’t see in any way how there is a patent issue here. I never understood how any of the arguments of the exiv2 dev were valid. But you can see how it has effected things.
OP here. Since my original post I’ve achieved a better workaround by recompiling exiv2 with BMFF/CR3 support using the simple option in the first post in the link that darix shared: https://bugzilla.redhat.com/show_bug.cgi?id=1979565
With the recompiled exiv2, the OBS package of darktable works fine.
That technique is specifically for RPM-based Linux distros, but I assume there must be something analogous for DEB-based distros too.
But I agree that the whole legal rigamarole around this is silly and annoying.
Of course it is. But when the only way to prove the invalidity of a patent is in court, and when that’s prohibitively expensive for many of the parties concerned, who wants to take the risk?
In Fedora, we try to build and ship only packages which we know (as far as we can know) not to create any legal challenges, at least in the US jurisdiction. That can be frustrating for users and packagers at times. But it is part of our definition of “free”, and it is why Fedora can be a baseline distro in certain areas.
That big warning that exiv2 put up can hardly be ignored. In particular, now that it is there: If we continued building exiv2 with ISOBMFF support we would do so being fully aware of these patent claims. That is riskier than it used to be.
For similar reasons, RedHat’s legal team will never say “yes it is patent encumbered” - that would be an invitation for the patent holder to go after prior uses of the code.
All we currently know is that we will not get an “OK” from RedHat’s legal team in the current state of affairs. We would need exiv2 to become part of a legal entity (KDE was under discussion) which takes on liabilities in case of patent issues.
Alternatively, if exiv2 could load format support as modules, we could easily have the missing module at rpmfusion so that it enhances the Fedora exiv2 for those users accepting the risk individually. I don’t think exiv2 supports this right now.
you could also have an exiv2 package in the distro with the formats turned off. and then ship the same source package via fusion and isobmff enabled there. then the user can just replace the exiv2 copy with the fusion one and be done. That’s what openSUSE does with packman.
Sure, but don’t you think the guidelines are there for very good reasons, too?
We are getting somewhat OT. I meant to provide the background for OP’s observations. In Fedora and neighboring lands (RHEL/EPEL/RPM fusion), we handle legal things and the “boundaries” between different lands in a specific way, which serves us well most of the time, and provides challenges sometimes. That could probably be said about most alternative ways of doing things, too. There’s always at least one way which would be easier in a specific scenario. No reason to change your long tome committment to a generally good way of doing things, though.
I might have a very good idea, why those guidelines might be there. And I also know very well in which cases it might make sense to amend those guidelines and create solutions that will make sure that those 2 packages do not diverge (e.g. lacking security updates) while at the same time giving the users the support for the additional formats.
e.g. for openSUSE it is solved by packman just following the original sources in the distro. and the spec file already having the needed conditionals in place to build it fully functional in packman.
If wanted drop me a PM or contact me on IRC and i can show you the details
Yes. And darktable already had a tone mapping module already. Would you suggest discussing sigmoid vs. filmic rgb in a Fedora bugzilla entry?
Next time I know better than offering background on Fedora’s packaging situation here, even if it affects darktable users. If you are really interested in an answer to your question (rather than dragging the discussion further OT from OP’s concern) you find everything in my posts above.
As an example, mlt-freeworld from RPM fusion provides only libmltavformat.so and similar, and the mlt package in Fedora has everything except a few so’s for specific formats. But mlt is a program, and exiv2 is a library … Maybe it could split out parts into separate so’s?
But I’ll mute this thread shortly. Time management …
