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

Ron <> Sat, 06 December 2014 04:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E13E51A8AB7 for <>; Fri, 5 Dec 2014 20:19:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bCZBmMfru96U for <>; Fri, 5 Dec 2014 20:19:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7EE821A8AB5 for <>; Fri, 5 Dec 2014 20:19:20 -0800 (PST)
Received: from (HELO mailservice.shelbyville.oz) ([]) by with ESMTP; 06 Dec 2014 14:49:19 +1030
Received: from localhost (localhost []) by mailservice.shelbyville.oz (Postfix) with ESMTP id EA8DCFFED0 for <>; Sat, 6 Dec 2014 14:49:06 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at mailservice.shelbyville.oz
Received: from mailservice.shelbyville.oz ([]) by localhost (mailservice.shelbyville.oz []) (amavisd-new, port 10024) with LMTP id zJOpD09D1kjj for <>; Sat, 6 Dec 2014 14:49:05 +1030 (CST)
Received: from hex.shelbyville.oz (hex.shelbyville.oz []) by mailservice.shelbyville.oz (Postfix) with ESMTPS id 9EBD7FFDA9 for <>; Sat, 6 Dec 2014 14:49:05 +1030 (CST)
Received: by hex.shelbyville.oz (Postfix, from userid 1000) id 9040280470; Sat, 6 Dec 2014 14:49:05 +1030 (ACDT)
Date: Sat, 6 Dec 2014 14:49:05 +1030
From: Ron <>
Message-ID: <20141206041905.GA19538@hex.shelbyville.oz>
References: <> <> <20141205035706.GB21150@hex.shelbyville.oz> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
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: Sat, 06 Dec 2014 04:19:23 -0000

On Fri, Dec 05, 2014 at 03:13:48PM -0800, David Singer wrote:
> Hi Ted
> > On Dec 5, 2014, at 14:32 , Ted Hardie <> wrote:
> > 
> > Hi David,
> > 
> > On Fri, Dec 5, 2014 at 1:42 PM, David Singer <> wrote:
> > 
> > 
> > (Much snipped)
> > 
> >> It really is not similar.  Maybe there are licenses that one or other does not carry:  in the Cisco case, we are unaware of any “unwilling to license”, whereas for VP8 there is a clear statement that no license can be had. 
> >> 
> > In both cases, the participant needs to assess whether they know of all the salient IPR, whether they have all the licenses for that IPR which they need.   While I am not a lawyer, I imagine that in both cases that would involve making a determination of the relevance of the claim as well as an analysis of its license terms.  It also involves an assessment of the risk that there are other claims which may later arise.
> > 
> > To my lay person's eyes, the two assessments do look pretty similar.  It appears, honestly, that you disagree with the results' of others assessments, rather than that the assessments do not need to take place in both cases.  But I may be misunderstanding your point.
> OK, let me see if I can persuade you of a qualitative difference.  For
> each ‘must’, what is the nature and availability of licenses that I
> might need from those claiming IPR?
> * H.264: all those claiming IPR offer licenses, though most of them
> ask for payment * VP8: almost all offer licenses that are either free
> or effectively so (pre-paid, in the case of the MPEG-LA), but there is
> one for which no license is available (and it’s not an insignificant
> company, or one not active in the field, or a small set of patents)

Ted was doing such a good job explaining this, that I was just going to
leave it to him.  But if you're going to call me out to be your champion,
to make your point here, then ...  ok :>

> For me, that is a major difference.  Clearly for others (e.g. Ron who
> has said as much), the cost is more significant than the license
> availability.

No.  You've clearly missed the point here, and you've missed it on the
order of Astronomical Units, not Barns.  You're going have to repeat
Free Software 101 I'm afraid.  I've never said anything of the sort.

Let me see if I can explain to you the qualitative difference ...

I'd gladly pay to be able to use VP8.  This isn't about money at all.
There simply is no amount of money that can remove the real crippling
costs of being burdened with or indentured to H.264 at present.

This is about Freedom.  The availability of a license for Freedom even.

The freedom to not have to count and track the users of my software.
The freedom to not have to ask permission to do what I need to do.
The freedom to not have to worry about anticompetitive patent abuse.
The freedom to interoperate with anyone else who values freedom.
The freedom to actually be able to get on with doing genuinely
interesting things instead of dealing with dinosaur legalese from
companies that no longer know how to do that.

I could go on, but that's probably enough for you to be able to
google the concept from there as your first homework assignment.

Do you want to know the really fun part about where I learned how
important these things were?  You're going to get a kick out of
this.  Go find a manual for an apple][ and turn to the back page!

When you're done studying its schematics and the source for its
ROM, we can get together for a beer and reminisce about where it
All Went So Sadly Wrong. :)

> I think inserting the ‘must’ here means that companies will either
> ignore it, or claim not to be a WebRTC Browser, neither of which
> advance the cause of interoperability at all.

So far we have something like 75% or more of the browser user market
share on board.  The only players in that game who aren't, are a
company that won't even tell us whether they plan to implement this
or not (which clearly makes their opinion vitally important!), and
another company who at some point at least seemed quite determined
to fork this effort and go off and do something completely different
all on their own.

That seems like a pretty good base to start from to me.

Maybe the holdouts will want to come play with us eventually, and
maybe they won't.  But we can't wait for them forever while they
learn to tie their shoelaces.  Enough people made that mistake
with SIP, let's not repeat it again here.