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

David Singer <singer@apple.com> Thu, 04 December 2014 02:08 UTC

Return-Path: <singer@apple.com>
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 50D941A87E7 for <rtcweb@ietfa.amsl.com>; Wed, 3 Dec 2014 18:08:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.101
X-Spam-Level:
X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, 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 93cEvubdfV-r for <rtcweb@ietfa.amsl.com>; Wed, 3 Dec 2014 18:08:24 -0800 (PST)
Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6039B1A87EB for <rtcweb@ietf.org>; Wed, 3 Dec 2014 18:08:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1417658892; x=2281572492; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Kt3Nmcieh6zes7O7Oct7EvFcklcGL38lstxChKauEsk=; b=ixQWqEAxTIn0kar8vXsdKCAXUP6594fDXkbJhfC/MYy83qr/MlHyw3tQ/mhKohlK YR3fyYgvV8mMakUHOlAuCeOCXwmU6tGlBgblWa98dMkb4KiO+C7suTKvvcfz2jnD r9+hglufyA4WW6gW0Yi8sf2qK+7SqjCx8EDGNXpuFgk8d0OYrF7+FfmHPrzPmVTf 87Voce7DieBe8uD1EuIEyLqhcJu+gSKVyjI5c7tiw7/kSbk7w3P5TR5NBx39j8wk UX5fBeh+0QKMqMVbpwE2oSisgwRvGue7f6B/olln4sHizD5yv8+wstq3JSo516iz lj2MXa49TJy30dU5CM+tDA==;
Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 8B.C7.05330.C02CF745; Wed, 3 Dec 2014 18:08:12 -0800 (PST)
X-AuditID: 11973e15-f791b6d0000014d2-8d-547fc20cea69
Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 68.E6.05858.602CF745; Wed, 3 Dec 2014 18:08:06 -0800 (PST)
Received: from [10.132.54.69] (server.frittshanna.com [76.74.153.41]) by koseret.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NG1001M7CLMDL00@koseret.apple.com> for rtcweb@ietf.org; Wed, 03 Dec 2014 18:08:12 -0800 (PST)
Content-type: text/plain; charset=utf-8
MIME-version: 1.0 (1.0)
From: David Singer <singer@apple.com>
X-Mailer: iPad Mail (12B435)
In-reply-to: <CAHp8n2m+KMnui30_fMrwM+81UX-RUJM2ktuiZuPpRSnC7dxqcA@mail.gmail.com>
Date: Wed, 03 Dec 2014 18:08:11 -0800
Content-transfer-encoding: quoted-printable
Message-id: <57A07A1B-DB2B-429E-BBFC-24500F91EE60@apple.com>
References: <547511DB.5050100@nostrum.com> <54759A4C.6020806@gmail.com> <5476092D.4010406@nostrum.com> <15EF2452-2C2C-420B-B972-C37EACE57850@apple.com> <CAHp8n2m+KMnui30_fMrwM+81UX-RUJM2ktuiZuPpRSnC7dxqcA@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FDorMtzqD7EYPUjVYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8XHJZqaCzWoVz368Zm9g/C7XxcjJISFgIvHzViszhC0mceHe erYuRi4OIYG9jBJb17xnhCn6s2AbM0SihUni0+x2JghnAZPEppnzWboYOTiYBdQlpkzJBWng FRCXeH10ClizsECExJHOM+wgNpuAqsSDOceghspINN1cyApicwoES3z4vw3sChagmuWbjrOB 2CAjl05ugLK1JZ68u8AKMd9G4s7byVA3PGKUWHz6JlhCREBfovnYFhaQhITAS1aJi7uvs09g FJ6FcN8sJPfNQjJ3ASPzKkah3MTMHN3MPDO9xIKCnFS95PzcTYygQJ5uJ7qD8cwqq0OMAhyM Sjy8hbvrQ4RYE8uKK3MPMUpzsCiJ8yZlA4UE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwar6f ei+A+WKuwq194cX7N6yavWsCl8oSve1JxqdCeJte8TevPS02/W3+/3svli9hWf3566IfZ12a bnzo+rZmS+f9qv8THF+mpk/lWG+48fDPaokLvOYyc/qubTf8mLCnkdN1U/q2Lw05x3+sveLl dU8gr62TT0pKaVaeptKBi24z3f+sfr1m2kQlluKMREMt5qLiRACEQevjRQIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUiON1OXZftUH2IwakfKhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4+OSzUwFm9Uqnv14zd7A+F2ui5GTQ0LAROLPgm3MELaYxIV7 69m6GLk4hARamCQ+zW5ngnAWMElsmjmfpYuRg4NZQF1iypRckAZeAXGJ10enMILYwgIREkc6 z7CD2GwCqhIP5hxjhBgqI9F0cyEriM0pECzx4T/EMhagmuWbjrOB2CAjl05ugLK1JZ68u8AK Md9G4s7byVA3PGKUWHz6JlhCREBfovnYFpYJjAKzEE6aheSkWUhGLWBkXsUoUJSak1hppJdY UJCTqpecn7uJERR4DYXOOxiPLbM6xCjAwajEw1uwuz5EiDWxrLgy9xCjBAezkghvTi9QiDcl sbIqtSg/vqg0J7X4EKM0B4uSOG9xNlBKID2xJDU7NbUgtQgmy8TBKdXAGNShHHuVzyp0Q/Wh Cg/pSx9ffU/a5SDif2Zr70yJ/RfEpK9V6901uOAzQ2FT1yM5hyyNvM+dnV/l9x2trq7zdVON UOsp/yiWG7TViPFJc9/CjMOv+a0TWr99mXHtrIC59NYX/Bby4r8epz9OOugjcdIoQH+Rn+66 6z/PCLzNnbCtxFRbu6ZIiaU4I9FQi7moOBEAAOw3LDgCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sV1DPuzt9rnMj1IXa05kcrOlzIE
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Thu, 04 Dec 2014 02:08:32 -0000

You're missing something. I am considering a company that has ipr in *other* aspects of webrtc, that gives a license to that only to conformant implementations. Not the codec.

What do you do? Defy the Nokia declaration, defy the 'must' and not do vp8 and be non-conformant, or not do webrtc at all? None are good choices.

Sent from my iPad

> On Dec 3, 2014, at 5:25 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
> 
>> On Thu, Dec 4, 2014 at 5:33 AM, David Singer <singer@apple.com> 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.
>> 
>> 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 don't see the risk of 1. having changed because of the IETF's
> statement. Plenty of small companies are already doing 1. and have had
> to risk getting sued by Nokia at this point in time already. In fact,
> it's a risk that small companies always have to deal with since there
> is so much patented technology around that you invariable will step on
> something. I doubt very much that the IETF's decision has any impact
> on small business' risk in that space at all.
> 
> 
>> I do not think that the IETF should be placing anyone into the position of having three extremely unpalatable choices.
> 
> For a small company in the WebRTC space, 3. is a non-choice. 2. Is
> more of a business decision than an IP decision - which market are you
> trying to address? Are you trying to be interoperable with (current)
> browsers - then implement VP8. Are you trying to be interoperable with
> legacy devices - then implement H.264 (and probably even H.263).
> 
> If you are trying to argue for a large company, the situation changes.
> However, as a large company, you tend to have an existing portfolio of
> patents. You're already playing the game of patents. As long as your
> hypothetical "IPR owners to grant a license only to ‘conforming
> implementations’" doesn't happen, you are free to choose 2. and avoid
> Nokia.
> 
> As for the threat in your option 2. - I can only see Google with IPR
> around VP8. Now, Google's IPR statement on WebM codecs, which includes
> VP8 and VP9 currently states: "Google hereby grants to you a
> perpetual, worldwide, non-exclusive, no-charge, royalty-free,
> irrevocable (except as stated in this section) patent license"
> http://www.webmproject.org/license/additional/
> The word "perpetual" implies (to my non-lawyer eyes) that they can't
> suddenly change this to mean "only if you are conformant to the
> standard". So you can't be referring to such a risk associated with
> VP8 being created by Google. I don't know which other company you
> would want to be afraid of for your hypothetical threat in 2. Could
> you clarify?
> 
> 
> Best Regards,
> Silvia.
> 
> 
>> (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.)
>> 
>> 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