On Sun, May 26, 2024 at 4:06 AM Robert-André Mauchin <zebob.m@xxxxxxxxx> wrote: > > Hello, > > Follow-up from : > https://gitlab.com/fedora/legal/fedora-license-data/-/issues/406 > > In order to update Exiv2, we need to know if this is okay to enable BMFF > support. Patents have theoretically expired and it is enabled by default > in the latest version. > > https://bugzilla.redhat.com/show_bug.cgi?id=1979565 > > https://github.com/Exiv2/exiv2/issues/1679 > > Upstream seems to think it is okay because it is over 20 years old. Also > other packages in Fedora are already using it, av1, jpeg-xl, any mp4 > decoding... > > By Jon Sneyers, one of the author of JPEG-XL: > > I think this caution is erring on the side of paranoia, and possibly > based on a misunderstanding. > > ISOBMFF is pretty old, old enough for it to be impossible to still > have applicable patents (patents expire after 20 years). It is a > simple box-based container format that is used by many formats, > including MP4, JPEG 2000, and JPEG XL. > > One particular use of ISOBMFF is HEIF, which is more recent, and for > which there actually are known patent claims by Nokia. HEIF does use > the generic ISOBMFF box structure and extends it by defining > mechanisms to do cropping, layering, grids, rotation etc, which are > described in the HEIF spec. HEIF can be used with various payloads: > when used with HEVC it is called HEIC, when used with AV1 it is > called AVIF. > > While most people would consider patents on a container format > ridiculous, it is a fact that, at least in theory, if you use HEIF, > you might risk patent litigation. Note that it would not be the > application implementor who could be sued, but the end-user who uses > the implementation and thereby possibly needs a patent license from > Nokia. > > This is only true specifically for HEIF though, not for ISOBMFF in > general. Parsing the MP4 or JPEG 2000 container (which do not use > HEIF) carries absolutely no risk in terms of patents, since they > only use ISOBMFF, not HEIF. The same is true for JPEG XL, which has > explicitly avoided using the HEIF container exactly for this reason. > > TL;DR: ISOBMFF is OK, HEIF might be risky. > > So just to be clear: reading BMFF is not an issue, it is over 20 > years old so even if it was an issue in the past (it wasn't) it now > certainly isn't anymore. > > Reading HEIF-specific boxes is something else, but as long as Exiv2 > is not doing that, there obviously is no issue either. Note that > other FOSS tools like libheif and libavif actually do read those > boxes, and they do seem to get away with it (but I can understand > why you wouldn't want to do that; those boxes are from 2015 and > Nokia does claim patents on them so it will only really be 'safe' to > use that functionality in 2035). > > So while I appreciate the caution, I think it's OK to just enable > the BMFF code by default (perhaps have an option to disable it, if > someone is still for some reason worried, but imo that would be an > unfounded worry). Otherwise most of the modern image codecs (jp2, > jxl, avif and heic) end up being unsupported by default, for no good > reason, which seems a sub-optimal situation. > > > Thank you for your time. > I have already been previously informed that we can enable and ship ISOBMFF. Please just update exiv2. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ legal mailing list -- legal@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to legal-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/legal@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
