Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

Harald Alvestrand <harald@alvestrand.no> Wed, 03 December 2014 19:12 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3911A1AC8 for <rtcweb@ietfa.amsl.com>; Wed, 3 Dec 2014 11:12:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apwMABttEu2R for <rtcweb@ietfa.amsl.com>; Wed, 3 Dec 2014 11:12:54 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 45DCD1A8F40 for <rtcweb@ietf.org>; Wed, 3 Dec 2014 11:12:47 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 8C3347C0972 for <rtcweb@ietf.org>; Wed, 3 Dec 2014 20:12:46 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_pmCPSJFrXU for <rtcweb@ietf.org>; Wed, 3 Dec 2014 20:12:42 +0100 (CET)
Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:70d4:5af0:ebdf:3bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 1AC287C0426 for <rtcweb@ietf.org>; Wed, 3 Dec 2014 20:12:42 +0100 (CET)
Message-ID: <547F60A8.3080302@alvestrand.no>
Date: Wed, 03 Dec 2014 20:12:40 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com>
In-Reply-To: <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/fkDm672ZXRYubBJpOeVOgJt0Mio
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 03 Dec 2014 19:12:59 -0000

On 12/03/2014 07:33 PM, David Singer wrote:
> As I understand it, the recent face to face meeting decided to draft the requirement that WebRTC browsers be required to implement both VP8 and H.264, and get feedback on this, on the list.
>
> This is some feedback.
>
>
>
> I’d like to point out that this could easily place companies in an impossible position.
>
> Consider: it is not uncommon for IPR owners to grant a license (often free) only to ‘conforming implementations’. (A common rationale is that they want to use their IPR to bring convergence and interoperability to the industry).  Let’s hypothesize that this happens, now or in future, from Company X, for some IPR in the WebRTC specifications.

I'm having trouble following the logic here. What technology are you 
imagining that Company X will put IPR claims on, and what conformance do 
you imagine that it would require?

(We could also consider the case of someone, call it Company G, claiming 
IPR on some non-codec part of WebRTC technology and refusing to license 
it at all. We can discuss the relative chances of the two things happening.)

>
> Consider also: we have an “unwilling to license” statement from Nokia on VP8, on the formal record (and including a long list of patents).
>
> Consider finally: a small company for whom WebRTC is important.
>
>
>
> Let’s look at the choices:
>
> 1.  Follow the mandate, implement VP8, and risk a ruinous lawsuit from Nokia.
>
> 2.  Reject the mandate, do not implement VP8, and be formally therefore not conformant and therefore not in receipt of a license from company X; risk a ruinous lawsuit from X.
>
> 3.  Do not implement WebRTC, and risk a ruinous loss of relevance.
>
>
> I do not think that the IETF should be placing anyone into the position of having three extremely unpalatable choices.
If Company G does its thing, both 1 and 2 risk a ruinous lawsuit from 
Company G.
>
> (Yes, I am aware that #2 is ‘unlikely’, but one day someone will decide that the “only to conformant implementations” clause needs to be real and enforced, and will do this; our hypothetical small company might prefer not to be the example case.)
>
> (I use a small company as the example, because for them the risk is bankruptcy, but of course no-one likes to step into the path of trouble even if they have the resources to weather it.)

My impression from the meeting was that the people speaking in favour of 
the proposed solution had evaluated the risks, and were ready to make a 
decision based on their evaluation.

YMMV.

>
> Dave Singer
>
> singer@mac.com
>
> David Singer
> Manager, Software Standards, Apple Inc.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb