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

David Singer <> Thu, 07 November 2013 06:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5FB0221E8090 for <>; Wed, 6 Nov 2013 22:01:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LZKgDSO1NmBm for <>; Wed, 6 Nov 2013 22:01:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D2A9F21E80C3 for <>; Wed, 6 Nov 2013 22:01:12 -0800 (PST)
Received: from ( []) by (Apple Singapore Mail Gateway) with SMTP id AD.FB.21841.A9C2B725; Thu, 7 Nov 2013 14:00:58 +0800 (MYT)
X-AuditID: 1152fe11-b7f256d000005551-b3-527b2c9a8d74
Received: from ( []) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by (Apple Singapore relay) with SMTP id 49.E8.26194.A9C2B725; Thu, 7 Nov 2013 14:00:58 +0800 (MYT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from [] (unknown []) by (Oracle Communications Messaging Server 7u4-24.01 ( 64bit (built Nov 17 2011)) with ESMTPSA id <> for; Thu, 07 Nov 2013 14:00:58 +0800 (SGT)
From: David Singer <>
In-reply-to: <20131106211149.GA1763@unaka.lan>
Date: Thu, 07 Nov 2013 15:00:58 +0900
Message-id: <>
References: <20131106211149.GA1763@unaka.lan>
To: Toshio Kuratomi <>
X-Mailer: Apple Mail (2.1510)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUiGHRCUHeWTnWQwfFzBhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr483X7+wFLUIVs2e3szYwnuLrYuTkkBAwkeh4c5cNwhaTuHBv PZDNxSEksJtRouvdDxaYouV9zawQiX4miZ/LXoJ18AoISvyYfA+oiIODWUBe4uB5WZAws4CW xPdHrSwQ9QuZJKbvOckOUiMsECpxdaUaSA2bgKrEgznHGEFsTgE9ideN18FGsgDFz/U0M0LM EZb4/hhiPK+AjUT3hDyQsJCArsSbQ5fBSkQENCSmf33DCnGmrMTpc8/B1koIfGWV2Dz/F/ME RuFZSC6dhXDpLCSXLmBkXsUonpuYmaObmWeol1icmaiXWFCQk6qXnJ+7iREczP8EdzBOXWh4 iFGAg1GJh9czqThIiDWxrLgy9xCjBAezkgjvvWdVQUK8KYmVValF+fFFpTmpxYcYpTlYlMR5 f/8tDxISSE8sSc1OTS1ILYLJMnFwSjUw8sosSLO2Fj25sf6fvZrC9KO5l/7ICZgILj2U4LLn 5dUVL6tdherSZMtvTjGJv9UqlvfWNHFt4LQ5uRGn5HiYjxnOXrX0uA7n/WX79uk+eDJPgu9S 8PlVdZJ9wqpZpx39595Nfvng1p/lMduP5q4UcPinrfDbWdBaU3mqm6ut8lunbTWi+WJ+SizF GYmGWsxFxYkAJDKnR2ICAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUiGHSiQneWTnWQQfcpXYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8ebrd/aCFqGK2bPbWRsYT/F1MXJySAiYSCzva2aFsMUkLtxb z9bFyMUhJNDPJPFz2Us2kASvgKDEj8n3WLoYOTiYBeQlDp6XBQkzC2hJfH/UygJRv5BJYvqe k+wgNcICoRJXV6qB1LAJqEo8mHOMEcTmFNCTeN14HWwkC1D8XE8zI8QcYYnvjyHG8wrYSHRP yAMJCwnoSrw5dBmsRERAQ2L61zdQZ8pKnD73nGUCo8AsJMfNQjhuFpLjFjAyr2IULUrNSaw0 1ksszkzUSywoyEnVS87P3cQICT7BHYwfphoeYhTgYFTi4WV6XRQkxJpYVlyZe4hRgoNZSYT3 3rOqICHelMTKqtSi/Pii0pzU4kOM0hwsSuK8sv/Kg4QE0hNLUrNTUwtSi2CyTBycUg2MG52d dM0lHF593bB0E4dqxbwFUcWTLlbXf03dWbz+kJGD4z0Nc8H8N2EfZ2fYtExne6rX6MPWN6Xd McShNrr/Vr/O5OONRvvfN9swmjlsX1YpxdrOvMIixvm35aPdB1fv6fjtHOR2mC/Pi/PIIY0g /Zd283icNkz7f3f/TTeFbdb17U97u1YrsRRnJBpqMRcVJwIAoxUS3zoCAAA=
Subject: Re: [rtcweb] One consuming project's concerns with OpenH264 as a MTI codec
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Nov 2013 06:01:27 -0000

Note that you would not have to include it in your distribution; you could suggest it in your installer, for example, and if the suggestion is taken, facilitate the install.

On Nov 7, 2013, at 6:11 , Toshio Kuratomi <> wrote:

> 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
> _______________________________________________
> rtcweb mailing list

David Singer
Multimedia and Software Standards, Apple Inc.