IETF, MTI codecs and Fedora

Background

Cisco announced that they will be releasing an implementation of H.264 under a BSD license along with distributing binaries to encode and decode this video format. Their purpose for doing so is to push it as a WebRTC standard with the IETF. The problem faced by Fedora is that the patent licensed granted by Cisco covers only the binaries that they themselves build and distribute. If the IETF approves the use of H.264 in addition to (or instead of) the VP8 codec as part of mandatory compliance in the WebRTC standard, Fedora would have to ship (or provide access to) a pre-compiled binary codec over which we have no control. We cannot ship a version that we ourselves build because it would not be covered under the patent license grant.

Fedora’s Response

The issue was escalated to FESCo, the Fedora Engineering Steering Committee, today with the question of how we should respond. We elected to make the following statement[1]:

Fedora is a distribution that cares about software freedom and our users
freedom. Firstly, we cannot ship binary-only prebuilt software within Fedora.
This rules out inclusion of OpenH264 binaries direct from Cisco, or other
providers. Secondly, we cannot ship software built from source which is not free
for any use, freely distributable, and free from patent restrictions.
Therefore, Fedora is similarly unable to ship rebuilt OpenH264 code.

Fedora would be much happier with a non-patent encumbered codec in the standard
as it would relieve us of the burden of caring for a codec implementation that
we cannot fix if it is buggy on our platform, let us ship improved or more
efficient versions of the codec if that is asked for, and relieve us of the
burden of making sure all implementors of the standard were using a proper
technique to retrieve the patent-encumbered portion from the internet so that
we weren't shipping non-free code.

Acceptance of an insufficiently-free license of the OpenH264 codec would mean
that open-source vendors are not able to implement it on their own terms. They
must rely on the implementation provided by a third party (Cisco) and create
workarounds to have the user download that implementation after installation,
increasing the burden on open-source users. This creates an unequal environment
for open-source vendors.

As members of the Open Source community, we feel that it is necessary to take a principled stand here. Allowing the WebRTC standard to mandate a patent-encumbered codec ensures an uneven playing field for open source distributions. I would like to encourage anyone reading this to write to the IETF at rtcweb@ietf.org and express concern at how much damage it would do to force an insufficiently open codec to be required for compliance with the future of the World Wide Web. Please make it clear to the IETF that to select H.264 as a mandatory codec would be to reduce the availability of competitive and alternative implementations.

[1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg09546.html

About these ads

8 thoughts on “IETF, MTI codecs and Fedora

  1. At least the Cisco H264 download puts a nail in the coffin of non-free (beer) codecs. From now on it’ll be “but H264 is free (beer) so why pay for H265?”

    Then VP9 steps in with free beer and freedom.

    In terms of downloading BLOBs from Cisco, you can verify the SHA hash. Ultimately it is open source, you just can’t compile it yourself. Whatever the heck that means.

    The biggest danger is of course if Cisco can’t/don’t actually do this…

    1. That pretty much means it “isn’t” open-source. Plus, there’s no way to confirm whether it actually was built from those sources. Since the license effectively prohibits rebuilding and releasing it, the only safe assumption from a security perspective is to assume that it is a Trojan Horse. If you think I’m being overly-paranoid… read the Snowden NSA leaks.

      1. The explanation from Cisco was that all the exact source code, build scripts, etc that are used to create the binary will be provided so anyone can verify the checksum. As much as I disagree with the whole concept, I will say that they are definitely trying to do it as well as possible.

      2. Unfortunately, that’s nowhere near sufficient. Without the ability to perfectly replicate their build environment, you cannot match the checksum with your own build. Even the smallest deviation (such as a vendor-patched header file) can render the whole thing different. And even if they provide you the entire build environment, you would still need to examine it (and the source to any binaries involved in it, like the compiler) to confirm. It’s virtually impossible to validate that large of a stack unless you’ve already got an environment built around doing just that, as with Koji in the Fedora build system.

  2. Nowhere did I read that RedHat(Fedora) had contacted CISCO and had an unsuccessful outcome. Has anyone thought to ask Cisco to put the sources in escrow, such that if a bug with the executable arises, via a Non Disclosure Agreement between Fedora and Cisco, the source could be compiled in debug mode to allow for repairs.

    If I recall from articles I read on the internet, while the IETF was in the process of nailing down the last bits of H.264 definitions, patents were already being applied for, ahead of the H.264 spec releases. I can’t say that it is true.

    If the source is not open, don’t support it. There can be a work around, that produces superior results, nullifying the need for H.264

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s