Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"

Silvia Pfeiffer <> Thu, 14 November 2013 00:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D403521E8094 for <>; Wed, 13 Nov 2013 16:04:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.557
X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sR5KGcFrJ+Ft for <>; Wed, 13 Nov 2013 16:04:32 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c02::22f]) by (Postfix) with ESMTP id 171C421E8090 for <>; Wed, 13 Nov 2013 16:04:32 -0800 (PST)
Received: by with SMTP id i7so1384007oag.20 for <>; Wed, 13 Nov 2013 16:04:31 -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; bh=5qz8MCGNpU8bx/Zdg7GCV+ZvDFBEVYoRtY+szXd5lvQ=; b=OewWZcxeK21PBqSjCdT+CzPfbWbO16oWSxFR33DvEC8vTxTN3xqjvpMy9+yJjrlq5H sr9sQ8HhdVF7gq9r+gg0lEQZcZziIRn4I1uAQ+qWDd5vnOwO4l7rSfjqEG9t4E29elzY tDgoK7V0U6pMLgYytkbiQ7V/prU4YrfCs31z+pspBBVM4NIp3Mfg63kUvgZ0lW34T/+P 1FiOpPEl9YIVbgkI2JiYlj+Is2Nl3qKgs56ugTr5t/cfn7QFGb9u+hafGwJuYBckgx0A aue8R0K6bT1cdFHkn2dGh01uzKEBluAkGSA2o/7N20+EwiUJ94RJq89JWgejVdM22ust 4T4g==
X-Received: by with SMTP id mq10mr4371872oeb.90.1384387471470; Wed, 13 Nov 2013 16:04:31 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 13 Nov 2013 16:04:11 -0800 (PST)
In-Reply-To: <20131113165526.GA13468@verdi>
References: <> <20131113165526.GA13468@verdi>
From: Silvia Pfeiffer <>
Date: Thu, 14 Nov 2013 08:04:11 +0800
Message-ID: <>
To: John Leslie <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" <>
Subject: Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"
X-Mailman-Version: 2.1.12
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, 14 Nov 2013 00:04:32 -0000

On Thu, Nov 14, 2013 at 12:55 AM, John Leslie <> wrote:
> Mike Linksvayer <> wrote:
>> I strongly support VP8 for MTI, and oppose H.264. Undecided on which
>> of both, either, or neither would be second best.
>    I'm _very_ glad you care which is "second best!"
>    I went into last week's session quite prepared to accept either, both
> or neither. I came out unwilling to support _either_ as MTI.
>    This is mostly because I came to understand the "cisco" postition.
>    (Please excuse me for assigning names to the two main positions, but
> it will make the discussion _much_ simpler.)
>    The "cisco" position is:
> - look at all the H.264 hardware out there: we must make use of it;
> - if VP8 is MTI, we'll get sued and our customers will get hassled.
>    The "linux" position is:
> - look at all the VP8 software out there: we must make use of it;
> - if H.264 is MTI, we'll get sued and our customers will get hassled.
>    And, alas, they're both right.
>    What I didn't understand before the presentations was why Cisco
> believes they'll get sued over VP8, but not H.264.
>    Basically H.264 has quite a consortium to slap down the likes of
> Nokia in court should they sue anyone in the consortium. This greatly
> reduces the chance of Nokia's lawyer suing.

What makes you think that? I am not aware of a requirement on MPEG-LA
to get involved in any lawsuit that involves a company suing somebody
over a patent that is part of the H.264 pool.

On the contrary: if you get sued over VP8, you will likely find that
Google has an interest to support you.


>    But this consortium won't lift a finger if Nokia sues Cisco over
> VP8. Cisco is a _very_ attractive target over VP8.
>    Thus, Cisco management would _very_much_ prefer that VP8 _not_ be
> MTI. They probably won't implement it.
>    Conversely, of course, "linux" management would _very_much_ prefer
> that H.264 not be MTI. They probably won't implement it.
>    Understanding this, I now strongly recommend against making either
> H.264 or VP8 MTI. (And I will not consent to a RFC 3929 process limited
> to choosing between them.)
>    This issue has dragged on long enough already. We need to start
> reading the riot act to the folks who claim we "need" either of these
> as MTI in order to have "satisfied" users.
>    Both H.264 and VP8 deserve "SHOULD implement" status. Neither,
> IMHO, will achieve consensus for "MUST implement" status. Yes, this
> is a sorry state to find ourselves in. But the marketplace has
> sorted out much worse problems in my memory.
>    And I claim that both camps are actually more likely to implement
> (or allow extensions for) the other side's codec if it is _not_ MTI,
> simply because they can back out at the first sign of lawyers.
>    I will not go into any details about how VP8 endpoints might talk
> to H.264 endpoints, but I'm _very_ confident ways will be found if
> we actually _publish_ an RFC saying both are "SHOULD implement".
>    (Surely I'm not the _only_ person who'd like to see _both_ H.264
> and VP8 legacy devices using our standard...)
> --
> John Leslie <>
> _______________________________________________
> rtcweb mailing list