Re: [rtcweb] On the topic of MTI video codecs

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Fri, 01 November 2013 14:28 UTC

Return-Path: <keith.drage@alcatel-lucent.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 8BC4D21E8388 for <rtcweb@ietfa.amsl.com>; Fri, 1 Nov 2013 07:28:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.532
X-Spam-Level:
X-Spam-Status: No, score=-110.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 8Hi91L4o71gv for <rtcweb@ietfa.amsl.com>; Fri, 1 Nov 2013 07:27:47 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id D0E3F21E822D for <rtcweb@ietf.org>; Fri, 1 Nov 2013 07:27:46 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rA1ERh8N020110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Nov 2013 09:27:45 -0500 (CDT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rA1ERhmQ012607 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Nov 2013 15:27:43 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 1 Nov 2013 15:27:43 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Simon Perreault <simon.perreault@viagenie.ca>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] On the topic of MTI video codecs
Thread-Index: AQHO1wkQNqalYrgjX0CF2LD2UOOxJpoQbMEg
Date: Fri, 01 Nov 2013 14:27:42 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0C5BA1@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <527147FF.5010506@nostrum.com> <C72DB04F-F363-45A9-A51F-31900037C239@vipadia.com> <C81F0BD3-F5E6-4E1A-955D-16D55E698BD1@edvina.net> <5272C6C8.3070006@gmail.com> <CABcZeBM6T0a9iLHVujzAiwFi5X5=S0oNK=xR3=FkHM2wi5bngQ@mail.gmail.com> <CAL02cgTwJwf27PuxGhhZAZgDN2jguxhNFBNPeJC4W1dwd5jzYA@mail.gmail.com> <5273A746.4060504@viagenie.ca>
In-Reply-To: <5273A746.4060504@viagenie.ca>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Subject: Re: [rtcweb] On the topic of MTI video codecs
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: Fri, 01 Nov 2013 14:28:09 -0000

I suspect the fallacy in your argument is in the statement

"Unlicensed binary comes in, licensed binary comes out."

If it was as simple as that, you ISP would them become liable for you H264 license fees.

I suspect that what occurs for Cisco to become liable to the license fees is some degree of ownership of the product they are distributing.

That ownership means they are also take responsibility for any of the liabilities arising from defective code they so distribute. I see no reason why Cisco would want to do that under anything but a controlled evironment, which would have its own set of non-trivial costs.

Keith

> -----Original Message-----
> From: rtcweb-bounces@ietf.org 
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Simon Perreault
> Sent: 01 November 2013 13:06
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] On the topic of MTI video codecs
> 
> Le 2013-10-31 18:36, Richard Barnes a écrit :
> > You would need something more than that if you don't trust 
> Cisco not 
> > to tinker with the binaries (no offense).  But even that 
> doesn't have 
> > to be complicated.  You could just do something like have 
> the software 
> > call back to the vendor whenever it gets a new binary from Cisco to 
> > check that the binary it just got is good (say, by 
> comparing hashes).
> 
> Is it even necessary that Cisco do the actual compiling of 
> source code?
> 
> As far as I understand, Cisco only needs to be distributing 
> the binaries. So here's a crazy idea... how about a 
> self-serve binary hosting service? You compile your code, 
> upload it to Cisco, Cisco does the download tracking and 
> accounting, and you and your users just need to download and 
> verify the checksum. Heck, Cisco could even host binaries of x264!
> 
> That would be much simpler on Cisco's part: much less 
> investment in manpower, much fewer things to maintain and 
> care for. It would just be a glorified FTP server. Unlicensed 
> binary comes in, licensed binary comes out. Platforms could 
> multiply without any effort from Cisco. Win win.
> 
> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>