Bug 1979565 - New file formats not enabled during exiv2 build
Summary: New file formats not enabled during exiv2 build
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: exiv2
Version: rawhide
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: FE-Legal 1991257
TreeView+ depends on / blocked
 
Reported: 2021-07-06 12:29 UTC by Brian Morrison
Modified: 2023-11-14 09:18 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
RPM Fusion 6167 0 P1 RESOLVED Exiv2+BMFF 2023-01-02 16:45:42 UTC

Description Brian Morrison 2021-07-06 12:29:39 UTC
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.

Comment 1 Rex Dieter 2021-07-06 21:39:51 UTC
Begs question why exiv2 upstream doesn't enable this support by default.

I'll try to find out

Comment 2 Rex Dieter 2021-07-07 15:58:10 UTC
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.

Comment 3 Brian Morrison 2021-07-07 16:26:37 UTC
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.

Comment 4 Miloš Komarčević 2021-07-26 13:17:16 UTC
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.

Comment 5 Rex Dieter 2021-07-26 15:25:11 UTC
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

Comment 6 Ben Cotton 2021-07-26 15:45:37 UTC
Ack. Will check with Legal.

Comment 7 Peter Kovář 2021-10-22 06:20:21 UTC
It would be nice Xmass present.

Cheers.

Comment 8 Peter Kovář 2021-10-27 06:43:32 UTC
ICMPv6 Echo Request.

What's going on with this so long?

Comment 9 Rex Dieter 2021-10-27 11:41:46 UTC
Awaiting legal review

Comment 10 Ben Cotton 2021-10-27 13:18:52 UTC
I've nudged Legal on this again.

Comment 11 Peter Kovář 2021-11-19 15:53:33 UTC
Ping?

Comment 12 Ben Cotton 2021-11-23 00:45:46 UTC
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

Comment 13 Peter Kovář 2021-11-23 16:21:12 UTC
R U kidding?

Comment 14 Peter Kovář 2021-12-16 11:14:47 UTC
So, maybe next year?

Anyway, MC & HNY.

Cheers!

Comment 15 Andreas Schneider 2021-12-26 14:48:37 UTC
Sorry, but we have tons of libraries in the distribution implementing ISOBMFF.

AV1/AVIF: libavif, firefox, chromium
JPEG2000: openjpeg2

and so on ...

Comment 18 Rex Dieter 2022-03-24 13:46:05 UTC
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.

Comment 19 Ben Cotton 2022-03-24 14:05:24 UTC
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.

Comment 20 Rex Dieter 2022-03-24 14:34:26 UTC
OK (I'm sad now)

Comment 21 Rex Dieter 2022-03-24 14:36:33 UTC
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.

Comment 22 Peter Kovář 2022-03-24 15:14:49 UTC
So, this year? Or next one?

Comment 23 Andreas Schneider 2022-03-24 18:41:43 UTC
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.

Comment 24 Rex Dieter 2022-03-24 21:48:40 UTC
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."

Comment 25 Rex Dieter 2022-03-24 21:51:51 UTC
This is promising:
https://github.com/Exiv2/exiv2/issues/1447

Exiv2 is considering joining OIN or kde.org (which is already a OIN member).

Comment 26 Miloš Komarčević 2022-08-19 10:14:12 UTC
Can FE-LEGAL at least check if this presumption of expired patents is valid?

https://github.com/macports/macports-ports/pull/15389#issuecomment-1207284871

Comment 27 Peter Kovář 2022-10-06 08:38:27 UTC
When? This year? Next one? 2030? 2050?

Comment 28 Jean-François Fortin Tam 2022-10-31 14:35:33 UTC
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?

Comment 29 Jean-François Fortin Tam 2023-01-02 16:45:43 UTC
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.

Comment 30 Michael J Gruber 2023-01-02 17:04:02 UTC
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.

Comment 31 lplt77p20omx 2023-01-04 12:49:39 UTC
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?

Comment 32 Jens Georg 2023-03-21 12:23:50 UTC
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.

Comment 33 Peter Kovář 2023-03-21 12:32:23 UTC
So, we we can expect boolean result from Red Hat/Fedora legal?

This year? Next one? In 2030? Or never?

Comment 34 Richard E Barber 2023-08-09 03:45:51 UTC
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.

Comment 35 Richard E Barber 2023-08-09 04:09:41 UTC
* by "tendency" I meant to say "possibility".

Comment 36 Mattia Verga 2023-08-14 07:07:53 UTC
I dropped a mail in Fedora legal mailing list to raise attention on this ticket, hopefully someone will chime in.

Comment 37 Peter Kovář 2023-09-01 20:04:03 UTC
Two weeks passed and still no response? time_t is flying quickly.

Comment 38 Peter Kovář 2023-09-28 08:23:06 UTC
Month++ and still 0 sum.

Comment 39 Peter Kovář 2023-10-11 00:59:13 UTC
What is going on here?

Indecision hurts the Exiv2 project badly.

Comment 40 Peter Kovář 2023-11-06 12:42:43 UTC
Hello, wake up! There is a v0.28.1

Comment 41 Brian Morrison 2023-11-06 15:07:49 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=2196493

Comment 42 Robert-André Mauchin 🐧 2023-11-14 09:18:20 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.