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

Silvia Pfeiffer <> Thu, 04 December 2014 01:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1AF291A6F32 for <>; Wed, 3 Dec 2014 17:26:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.75
X-Spam-Status: No, score=-0.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8FSWYKfeFgyh for <>; Wed, 3 Dec 2014 17:26:08 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 75B3E1A6F30 for <>; Wed, 3 Dec 2014 17:26:08 -0800 (PST)
Received: by with SMTP id 10so7478053ykt.33 for <>; Wed, 03 Dec 2014 17:26:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=rI1cPdW/iHUEp0D9rT5GpmznfHDp2kNT36+ES3y0JOI=; b=P8ty8vI1Z6DZ6Hn6Ay8Qu51xcAsGeyyNx1j6wrXG62bhoH9fJLEsZNHZLslHimOZnY 9MxWjASUsD31bcvKLOQvNkOkT0qK0APVUH5ZmMvVUq2HhPBNekWwU3BZZ6tqY5cq+mTm O2nLYNinX3Uub1xuMIs/cT0nWfEIEle8vIYPKFAeJSLMnlW7QVvKI3hAGs+LtyvpMZBA kCDDj8K4Y3fnNQWyp4qM/Uiv1Tz8D6IPpk78bL99JH1rYFYhzUE0setupa1EcSbtYCtf MWQm/qFmm/YTqyqZBCpwiy5LICR9SCU73wv6cCheAj7rKaYulug7RLCxLbOo+bAOZegl OxIw==
X-Received: by with SMTP id 46mr10290846yhc.78.1417656367446; Wed, 03 Dec 2014 17:26:07 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 3 Dec 2014 17:25:47 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Silvia Pfeiffer <>
Date: Thu, 04 Dec 2014 12:25:47 +1100
Message-ID: <>
To: David Singer <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)
X-Mailman-Version: 2.1.15
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: Thu, 04 Dec 2014 01:26:10 -0000

On Thu, Dec 4, 2014 at 5:33 AM, 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.
> 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

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"
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,

> (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
> David Singer
> Manager, Software Standards, Apple Inc.
> _______________________________________________
> rtcweb mailing list