IETF Logo Mail Archive

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

"Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net> Wed, 06 November 2013 21:24 UTC

Return-Path: <matthew.kaufman@skype.net>
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 5CB1A11E8162 for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 13:24:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtewI5kMkuE9 for <rtcweb@ietfa.amsl.com>; Wed, 6 Nov 2013 13:23:58 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id D1BE211E8159 for <rtcweb@ietf.org>; Wed, 6 Nov 2013 13:23:56 -0800 (PST)
Received: from DM2PR03CA003.namprd03.prod.outlook.com (10.141.52.151) by BN1PR03MB024.namprd03.prod.outlook.com (10.255.224.42) with Microsoft SMTP Server (TLS) id 15.0.815.6; Wed, 6 Nov 2013 21:23:47 +0000
Received: from BN1AFFO11FD020.protection.gbl (2a01:111:f400:7c10::177) by DM2PR03CA003.outlook.office365.com (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 mail.microsoft.com (131.107.125.37) by BN1AFFO11FD020.mail.protection.outlook.com (10.58.52.80) with Microsoft SMTP Server (TLS) id 15.0.815.5 via Frontend Transport; Wed, 6 Nov 2013 21:23:46 +0000
Received: from TK5EX14MBXC266.redmond.corp.microsoft.com ([169.254.2.187]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.03.0158.002; Wed, 6 Nov 2013 21:23:05 +0000
From: "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
To: Toshio Kuratomi <a.badger@gmail.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] One consuming project's concerns with OpenH264 as a MTI codec
Thread-Index: AQHO2zTbiaKQn9DEiEqrQAYM3w+FD5oYtkjQ
Date: Wed, 06 Nov 2013 21:23:03 +0000
Message-ID: <AE1A6B5FD507DC4FB3C5166F3A05A4843D48AD5F@TK5EX14MBXC266.redmond.corp.microsoft.com>
References: <20131106211149.GA1763@unaka.lan>
In-Reply-To: <20131106211149.GA1763@unaka.lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.75]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; 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; H:mail.microsoft.com; CLIP:131.107.125.37; 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
X-OriginatorOrg: skype.net
Subject: Re: [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:24:04 -0000

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

Matthew Kaufman

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Toshio Kuratomi
> Sent: Wednesday, November 6, 2013 1:12 PM
> To: rtcweb@ietf.org
> 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

v2.23.0 | Report a Bug | By Email