You have a big fat warning that there might be patents. With it you tell others, we know more than you.
I fully understand that a legel team argues that they can’t take that risk.
I suggest to e.g. watch legal talks from Andrew Tridgell (tridge).
Not “we”. The ISO/IEC 14496-12 specification itself does:
The International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) draw attention to the fact that it is claimed that compliance with this document may involve the use of patents.
ISO and IEC take no position concerning the evidence, validity and scope of these patent rights
The holders of these patent rights have assured ISO and IEC that they are willing to negotiate licences under reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this respect, the statements of the holders of these patent rights are registered with ISO and IEC. Information may be obtained from the patent database available at www.iso.org/patents.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights other than those in the patent database. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
So yes, the risk is passed on as there are no resources to actually check those and potentially indemnify users. Under those circumstances, not passing on that warning would actually be unfair and misleading, and most certainly wouldn’t make the issue “go away”.
Instead of just “not wanting to take that risk”, the Fedora Legal team could actually invest their resources into checking the applicability of those claims and help the community out.
Is the legal risk perceived to be there for jpegxl too?
What aspect of JPEG XL exactly?
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.
Jpegxl can use isobmff, so if that’s an issue for exiv2 then it must be an issue for jpegxl as well. I’ve never heard of an issue with jpegxl, so…
So ask them.
Again, the JPEG XL interest group has some resourceful backing. Exiv2 has none.
Can confirm I’m experiencing this on Debian 11.
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.
1 Like
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?
That is the problem, yes.
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.
1 Like
actually the OBS repository provides an exiv2 package with the required options turned on.
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.
Technically you can do this, of course, it is much easier.
AFAIK it is against RPM fusion guidelines, though.
Sometimes Guidelines need a revision if there is a very good reason 
This could then also be used to have Mesa with the hardware encoder support turned back on 
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
What would be the steps to do this?
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.