IETF Logo Mail Archive

[rtcweb] One consuming project's concerns with OpenH264 as a MTI codec

Toshio Kuratomi <a.badger@gmail.com> Wed, 06 November 2013 21:11 UTC

Return-Path: <a.badger@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713D021E81AB for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 13:11:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.665
X-Spam-Level:
X-Spam-Status: No, score=-2.665 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIdb4Ur1wZl4 for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 13:11:53 -0800 (PST)
Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id C0A7021F9ECA for <rtcweb@ietf.org>; Wed, 6 Nov 2013 13:11:52 -0800 (PST)
Received: by mail-pd0-f177.google.com with SMTP id p10so69947pdj.22 for <rtcweb@ietf.org>; Wed, 06 Nov 2013 13:11:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=4kRHu9hHaw4+1q7YD9+KIZLzK+vX0Tb3AWLfhYU/+/k=; b=ec43xZe6KINao4zDSfb0VwuOHFR2XeLvxSibkw9a7IBnDeF1Xu4LjL1Y/s1TlfjVGv fP0O0Z7Qm4gqD3n5X3sohKy4PsNv0s3Zukieib1cLK/4wwV8/qGo43pmaO/Kpun9JZRY ZJ3QJ11XdybAN/Uu/oWL6P//rg297pQXAoPLrA4TC6n5wGctd8fbClKGG0VNAD169T4z RB8MNkG/2JUFd57jbAaVLSQ05JnOxAWdQ+0Z1v8BwJDgsqDUVANaX7xvrEAi3LVWAyq7 GYdZg1W7lQCkun/xJpa3ypPsf7Ou/lQHLqOa47fy0U+Eh4LM+e5Q+JPnTBp31jICJNfo Twwg==
X-Received: by 10.66.188.203 with SMTP id gc11mr5815777pac.63.1383772312254; Wed, 06 Nov 2013 13:11:52 -0800 (PST)
Received: from unaka.lan ([65.78.164.85]) by mx.google.com with ESMTPSA id fa4sm780198pab.17.2013.11.06.13.11.50 for <rtcweb@ietf.org> (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 06 Nov 2013 13:11:51 -0800 (PST)
Date: Wed, 06 Nov 2013 13:11:49 -0800
From: Toshio Kuratomi <a.badger@gmail.com>
To: rtcweb@ietf.org
Message-ID: <20131106211149.GA1763@unaka.lan>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="NNMNuNcS5bf7Nky/"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [rtcweb] One consuming project's concerns with OpenH264 as a MTI codec
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Nov 2013 21:11:54 -0000

Greetings,

I serve on the Engineering Steering Committee for the Fedora Project, a Linux
Distribution.  A few days ago we were asked if we could give input on
OpenH264 becoming a MTI codec in the rtcweb standard.  We discussed the
issue at our weekly meeting and agreed on this statement:


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.


I hope that helps in your decision making.

Thank you for your time,
Toshio Kuratomi

v2.23.0 | Report a Bug | By Email