Description of problem: BMFF file formats such as heif, CR3 etc are supported in exiv2-0.27.4 but are not built by default Version-Release number of selected component (if applicable): exiv2-0.27.4 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: This feature can be enabled by adding: -DEXIV2_ENABLE_BMFF:BOOL=ON to the %build %cmake section in the exiv2.spec file It improves the function of the exiv2 libraries for those using image files with the new formats.
Begs question why exiv2 upstream doesn't enable this support by default. I'll try to find out
Found so far in README.md included in exiv2 source: 2.3 Build options ... It is planned to set the default -DEXIV2\_ENABLE\_BMFF=On for Exiv2 v1.00. BMFF support is disabled by default in v0.27.4. ... 2.14 Thread safety ... The use of the _**thread unsafe function**_ Exiv2::enableBMFF(true) is discussed in [2.19 Support for bmff files](#2-19) ... ### 2.19 Support for bmff files (CR3, HEIF, HEIC, and AVIF) **Attention is drawn to the possibility that bmff support may be the subject of patent rights. _Exiv2 shall not be held responsible for identifying any or all such patent rights. Exiv2 shall not be held responsible for the legal consequences of the use of this code_.** Access to the bmff code is guarded in two ways. Firstly, you have to build the library with the cmake option: `-DEXIV2_ENABLE_BMFF=On`. Secondly, the application must enable bmff support at run-time by calling the following function. So looks like there are both possible technical (multithreading) and legal (patents) reasons for not enabling this feature yet.
I see. Given that this is only about having access to metadata within these files I didn't expect this sort of issue. I will monitor the situation and see if this is resolved by upstream.
I believe there is nothing to "resolve" upstream. It is left up to packagers and 3rd party apps to do their due diligence and decide whether they enable this or not, the README is clear. As far as thread safety goes, it is also up to 3rd party apps to call Exiv2::enableBMFF(true) in a thread safe way.
Blocking FE-LEGAL to review software patent claims and concerns here, see comment #2 I see at least 3 scenarios from legal review: 1. OK to enable BMFF support 2. Not OK to enable BMFF support 3. Not OK to enable BMFF support, must strip sources of patent-infringing code
Ack. Will check with Legal.
It would be nice Xmass present. Cheers.
ICMPv6 Echo Request. What's going on with this so long?
Awaiting legal review
I've nudged Legal on this again.
Ping?
I still don't have an answer from Legal, so if you want to proceed, the best choice for now is: > 3. Not OK to enable BMFF support, must strip sources of patent-infringing code
R U kidding?
So, maybe next year? Anyway, MC & HNY. Cheers!
Sorry, but we have tons of libraries in the distribution implementing ISOBMFF. AV1/AVIF: libavif, firefox, chromium JPEG2000: openjpeg2 and so on ...
Re: "we have tons of libraries... implementing ISOBMFF" And yet few of those projects chose to include a legal disclaimer like exiv2 did. So again, due diligence. Ben, I just noticed now in your comment about not having heard from legal, you removed the Blocker on FE-LEGAL. Was that intentional? Because we *are* still ideally waiting for a legal review.
I removed it because I said we should go with > 3. Not OK to enable BMFF support, must strip sources of patent-infringing code In other words, the legal question is as answered as we're likely to get.
OK (I'm sad now)
Sorry for additional follow-up, but in practical terms, without a formal legal review, it's hard to know how best to implement the stripping of offending code too.
So, this year? Or next one?
The ISOBMFF format is directly based on Apple’s QuickTime container format: https://www.loc.gov/preservation/digital/formats/fdd/fdd000052.shtml The QuickTime container format was first released in 1991 by Apple. In 2001 Apple released public documentation about the format. ISOBMFF is based on that: https://www.loc.gov/preservation/digital/formats/fdd/fdd000079.shtml This site has some useful information (CTRL+F History): * ISO BMFF is directly based on Apple’s QuickTime container format. * It was developed by MPEG (ISO/IEC JTC1/SC29/WG11). * The first MP4 file format specification was created on the basis of the QuickTime format specification published in 2001. * The MP4 file format known as "version 1" was published in 2001 as ISO/IEC 14496-1:2001, as a revision of MPEG-4 Part 1: Systems. * In 2003, the first version of MP4 file format was revised and replaced by MPEG-4 Part 14: MP4 file format (ISO/IEC 14496-14:2003), commonly known as MPEG-4 file format "version 2". Note: As of September 2020, the current version of ISO/IEC 14496-14 is from 2020. * The MP4 file format was generalized into the ISO Base Media File format (ISO/IEC 14496-12:2004 or ISO/IEC 15444-12:2004), which defines a general structure for time-based media files. ISOBMF is used by a lot of video and image formats, among them are JPEG2000, JPEG XL, AVIF, AV1 any many more. However it is really old in the meantime.
Maybe try telling exiv2 upstream that so they will remove their warning/notice that this is/may-be patent encumbered? README.md (still) contains the text "Attention is drawn to the possibility that bmff support may be the subject of patent rights. Exiv2 shall not be held responsible for identifying any or all such patent rights. Exiv2 shall not be held responsible for the legal consequences of the use of this code."
This is promising: https://github.com/Exiv2/exiv2/issues/1447 Exiv2 is considering joining OIN or kde.org (which is already a OIN member).
Can FE-LEGAL at least check if this presumption of expired patents is valid? https://github.com/macports/macports-ports/pull/15389#issuecomment-1207284871
When? This year? Next one? 2030? 2050?
This prevents me from being able to read photo camera EXIF metadata in JPEG XL files (as I found out through https://github.com/Exiv2/exiv2/issues/2398 that points to this being a downstream build enablement issue); I can only hope that this becomes available in Fedora at some point, as I'm planning to use JPEG XL as my main archival format for decades to come and this kinda makes the exiv2 package in Fedora useless for dealing with modern formats. Alternatively, would there be a 4th possibility, a "fusion" (ahem) variant for the free world?
Just for the record (as it took me a while to find this otherwise), there actually was a request for this to be considered for rpmfusion: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6167 ...but it was closed in part because it is blocked on legal review, and in part because… I'm not sure, I think because there needs to be someone to propose a package to review in rpmfusion that doesn't conflict with the mainline Fedora exiv2 package? Did I understand that correctly? I wish there was a COPR or something out there so that I could at least test the applications ahead of time with such a version of exiv2, to verify whether it would work "automagically" or if the applications would also need some additional work to be able to read JPEG XL EXIF metadata through exiv2 (in which case I'd then need to be filing bugs on those individual applications as well); I personally don't have the skills/knowledge to do such packaging.
Just to clarify: 1. If it cannot be in Fedora then it cannot be in COPR. 2. If it replaces a Fedora package then it cannot be in RPM fusion. Legal will not answer 1. as per comment #19 (they will probably never answer "not OK", only "OK" if it is; still "we have checked" would be a matter of courtesy). 2. is a technical question. "freeworld" packages in rpmfusion typically provide additional .so etc. which add functionality to the Fedora package but do not replace it (no file conflicts). libexiv2 is a single library. So I dunno how feasible the usual approach is here - packages linking to exiv2 would have to adjust, too.
Given that: 1. AVIF and JPEG XL use ISOBMFF 2. Fedora has packages for libavif and libjxl 3. Applications can parse metadata via libavif and libjxl Questions: 1. Why parsing metadata via libavif and libjxl is OK but parsing metadata via ISOBMFF-enabled exiv2 is not OK? 2. If ISOBMFF is problematic, shouldn't libavif and libjxl be removed from Fedora's repos?
Maybe I can shed a little light on that sentence, because I am the one that kind of sparked that: When exiv2 went on to read meta-data from HEIF, which was initially thought to be done using libheif, I raised the concern that people might want to have that optional, because legal/ethical reasons. That somewhat got out of hand and extended to the whole of BMFF somehow, and was, in some parts, deliberately misunderstood and in the end went tits up in the option being off by default and that sentence. But I can only agree with the previous comment: Why is it ok to parse BMFF in the other libraries and here not? that's not consistent. The exiv2 implementation is, as far as I know, a clean-room from the scratch implementation done by Robin, as outlined in his book.
So, we we can expect boolean result from Red Hat/Fedora legal? This year? Next one? In 2030? Or never?
exiv2 certainly does not encroach or attempt to encroach on any proprietary methods, but utilizes standards which have multiple commercially existing implementations protected by certain patents and pooled-parents across the globe. It does not preclude anyone from designing another implementation, but does highlight the tendency for a development in software to become used for nefarious purposes such as the design of weapons of mass destruction. Free use of the technology could potentially be construed as anti-competitive due to the potential for communication between competitive intellectual property owners. At the same time any prohibition of novel applications of the documented technology could be equal construed as anti-competitive because it reserves the underlying against scientific and technical research, which is the operating environment in which open-source software exists. Application therefor of anti-competitive terms need not apply. Here are the facts as I see them presently: A) Inclusion of exiv2 in MIT-licensed Fedora compilations don’t alter the reciprocal license status of either fedora or exiv2, who both retain indemnity to all potential intellectual breaches by the statement of license. Basis: “…this compilation license does not supersede the licenses of code and content contained in Fedora Linux, which conform to the guidelines described…” source: https://docs.fedoraproject.org/en-US/legal/fedora-linux-license/ Cf.: https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ B) exiv2 reads certain metadata using methodologies derived from ISO 14496-12 aka MPEG4 Part 12. Basis: “BMFF .CR3, .HEIC, .AVIF, .JXL … I obtained the standard here: https://mpeg.chiariglione.org/standards/mpeg-4/iso-base-media-file-format/text-isoiec-14496-12-5th-edition” source: https://exiv2.org/book/#BMFF C) As of the time of this writing, six patent claims from 3 corporations have been filed against ISO 14496-12. Basis: https://www.iso.org/home.isoDocumentsDownload.do?t=q7W5xottsc9obZl9kp-qDHnjrsqD-GkkULb5NVeVdUL3kXGa8jBqIg68jBfDLHc-&CSRFTOKEN=N00X-71X9-C49Y-GZW3-ZWSO-7IYR-DXJD-HZF4 https://www.iso.org/home.isoDocumentsDownload.do?t=hYYtRe8hIqp_lZXh3pb6gyLsZD0GqiCDLB1GhZ-qut3dVlaHAAWM3UbO-0asS1fk&CSRFTOKEN=N00X-71X9-C49Y-GZW3-ZWSO-7IYR-DXJD-HZF4 https://www.iso.org/home.isoDocumentsDownload.do?t=2Tbg5LzrbWnjIJwlG5UPQIFba4oPhtMRjO60bRD9NI4SYgF_LiaHugi648I2Ppcy&CSRFTOKEN=N00X-71X9-C49Y-GZW3-ZWSO-7IYR-DXJD-HZF4 https://www.iso.org/home.isoDocumentsDownload.do?t=ehXTtIbRCPNQFsjcyL_J1gtXOcbp6zMNJLewxCzAmMU0LPRrTXWG1f85sFOsDJ9T&CSRFTOKEN=N00X-71X9-C49Y-GZW3-ZWSO-7IYR-DXJD-HZF4 https://www.iso.org/home.isoDocumentsDownload.do?t=ZKGs1fihgEgeU68Q2EcJd_uWOsH3d91o35r0irrrxxNPToI3r1_8SLeew1vFefeo&CSRFTOKEN=N00X-71X9-C49Y-GZW3-ZWSO-7IYR-DXJD-HZF4 https://www.iso.org/home.isoDocumentsDownload.do?t=0in8OZoKOpS4zc9-4jZAajNEdSppq6Q7tJraQTns7-CaiR1VzoYZLuYHED3ImmlY&CSRFTOKEN=N00X-71X9-C49Y-GZW3-ZWSO-7IYR-DXJD-HZF4 source: https://isotc.iso.org/livelink/livelink/Open/13622347 D) All six claims filed against ISO 14496-12 indicate the claims seek reciprocal licensing. Basis: “x 2.The Patent Holder is prepared to grant a license to an unrestricted number of applicants on a worldwide, non-discriminatory basis and on reasonable terms and conditions to make, use and sell implementations of the above document. Negotiations are left to the parties concerned and are performed outside the ITU-T, ITU-R, ISO, or IEC. Also mark here _x_ if the Patent Holder's willingness to license is conditioned on Reciprocity for the above document.” source: Six documents listed above in letter C). E) The intention of the desired arrangement is reciprocal free-of-charge use with reasonable conditions. Basis: “Free of Charge: The words "Free of Charge" do not mean that the Patent Holder is waiving all of its rights with respect to the Patent. Rather, "Free of Charge refers to the issue of monetary compensation; i.e., that the Patent Holder will not seek any monetary compensation as part of the licensing arrangement (whether such compensation is called a royalty, a one-time licensing fee, etc.). However, while the Patent Holder in this situation is committing to not charging any monetary amount, the Patent Holder is still entitled to require that the implementer of the same above document sign a license agreement that contains other reasonable terms and conditions such as those relating to governing law, field of use, warranties, etc.” “Reciprocity: The word "Reciprocity" means that the Patent Holder shall only be required to license any prospective licensee if such prospective licensee will commit to license its Patents) for implementation of the same above document Free of Charge or under reasonable terms and conditions.” “Patent: The word "Patent" means those claims contained in and identified by patents, utility models and other similar statutory rights based on inventions (including applications for any of these) solely to the extent that any such claims are essential to the implementation of the same above document. Essential patents are patents that would be required to implement a specific Recommendation | Deliverable.” source: six documents listed above in letter C). F) Both fedora and exiv2 at present stand indemnified by fact of license (MIT/GNU2+) against potential violations of any reasonable licensing agreement. Basis: “…reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program…” source: https://www.gnu.org/licenses/gpl-3.0.html Basis: “…IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY…” source: https://opensource.org/license/mit/ Absent liability and monetary recompense in either exiv2 or fedora distributors, fedora should not block community inclusion of exiv2. Perhaps right now is the right time for fedora legal to conclude proceedings on this matter and allow exiv2 to utilize its novel ISOBMFF methodologies which have been in public development for years without a single court challenge.
* by "tendency" I meant to say "possibility".
I dropped a mail in Fedora legal mailing list to raise attention on this ticket, hopefully someone will chime in.
Two weeks passed and still no response? time_t is flying quickly.
Month++ and still 0 sum.
What is going on here? Indecision hurts the Exiv2 project badly.
Hello, wake up! There is a v0.28.1
https://bugzilla.redhat.com/show_bug.cgi?id=2196493
Ok outside of the legal parts which is anon issue, 0.28.0 brought out breaking changes. We need to patch several applications, some of them unmaintained. Work in progress here: https://copr.fedorainfracloud.org/coprs/eclipseo/exiv2-0.28.1/builds/ So far I have made patch for 11 aps, 12 apps are remaining to be fixed.