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

"Matthew Kaufman (SKYPE)" <> Wed, 06 November 2013 21:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5CB1A11E8162 for <>; Wed, 6 Nov 2013 13:24:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HtewI5kMkuE9 for <>; Wed, 6 Nov 2013 13:23:58 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D1BE211E8159 for <>; Wed, 6 Nov 2013 13:23:56 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.815.6; Wed, 6 Nov 2013 21:23:47 +0000
Received: from (2a01:111:f400:7c10::177) by (2a01:111:e400:2414::23) with Microsoft SMTP Server (TLS) id 15.0.815.6 via Frontend Transport; Wed, 6 Nov 2013 21:23:47 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.815.5 via Frontend Transport; Wed, 6 Nov 2013 21:23:46 +0000
Received: from ([]) by ([]) with mapi id 14.03.0158.002; Wed, 6 Nov 2013 21:23:05 +0000
From: "Matthew Kaufman (SKYPE)" <>
To: Toshio Kuratomi <>, "" <>
Thread-Topic: [rtcweb] One consuming project's concerns with OpenH264 as a MTI codec
Thread-Index: AQHO2zTbiaKQn9DEiEqrQAYM3w+FD5oYtkjQ
Date: Wed, 6 Nov 2013 21:23:03 +0000
Message-ID: <>
References: <20131106211149.GA1763@unaka.lan>
In-Reply-To: <20131106211149.GA1763@unaka.lan>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(51744003)(13464003)(51704005)(377454003)(66066001)(65816001)(55846006)(50466002)(80022001)(44976005)(80976001)(74662001)(74706001)(2656002)(46406003)(76482001)(81816001)(33656001)(85306002)(56776001)(74876001)(54316002)(69226001)(81686001)(81342001)(59766001)(79102001)(81542001)(53806001)(74366001)(51856001)(87266001)(46102001)(19580395003)(77096001)(20776003)(47446002)(47776003)(50986001)(23726002)(47736001)(74502001)(56816003)(63696002)(77982001)(54356001)(83072001)(19580405001)(47976001)(83322001)(4396001)(76786001)(31966008)(49866001)(6806004)(224303002)(224313003)(76796001)(87936001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR03MB024;; CLIP:; FPR:; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0022134A87
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: Wed, 06 Nov 2013 21:24:04 -0000

Which "non-patent-enumbered" codec did you have in mind?

Matthew Kaufman

> -----Original Message-----
> From: [] On
> Behalf Of Toshio Kuratomi
> Sent: Wednesday, November 6, 2013 1:12 PM
> To:
> Subject: [rtcweb] One consuming project's concerns with OpenH264 as a MTI
> codec
> 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