Re: [rtcweb] H.261

Ron <> Wed, 27 November 2013 16:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B49831ACCE8 for <>; Wed, 27 Nov 2013 08:31:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UiNOu-7X4tgC for <>; Wed, 27 Nov 2013 08:30:59 -0800 (PST)
Received: from ( [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by (Postfix) with ESMTP id B3D3E1AC829 for <>; Wed, 27 Nov 2013 08:30:58 -0800 (PST)
Received: from (HELO audi.shelbyville.oz) ([]) by with ESMTP; 28 Nov 2013 03:00:57 +1030
Received: from localhost (localhost []) by audi.shelbyville.oz (Postfix) with ESMTP id 5E3B24F8F3 for <>; Thu, 28 Nov 2013 02:55:53 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([]) by localhost (audi.shelbyville.oz []) (amavisd-new, port 10024) with LMTP id G0ICrRHwsLge for <>; Thu, 28 Nov 2013 02:55:52 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 6CDB44F902; Thu, 28 Nov 2013 02:55:52 +1030 (CST)
Date: Thu, 28 Nov 2013 02:55:52 +1030
From: Ron <>
Message-ID: <20131127162552.GP3245@audi.shelbyville.oz>
References: <20131122171020.GY3245@audi.shelbyville.oz> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] H.261
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: Wed, 27 Nov 2013 16:31:00 -0000

On Wed, Nov 27, 2013 at 03:30:55AM +0000, Cullen Jennings (fluffy) wrote:
> I do get they MPEG LA terms can be confusing at times
> but lots of people have figured it out.

I can only assume that you mean this in the same sense that "lots of people"
have "figured out" those click through EULA conditions that don't actually
allow them to do the things they'll be doing but obviously aren't intended
to be read since a 50 page document is presented in a 4 line scroll box with
no button that says "click here to send this to your lawyer". [1]

Like the ones that say your TV can report everything that's ever watched on
it to the manufacturer, even after you click the Don't Do That button. [2]

Or in the same sense that they drive their motor vehicles without complying
with their legal obligation to keep a bale of hay in the trunk or have some
person walk in front at all times waving a flag.

A licence that says "we'll take your money, but we can't actually grant you
the rights to use this since we don't own or control them - we'll just sort
of promise that WE won't drag you through the courts, in exchange for being
able to track exactly how profitable your business is" -- isn't a licence at
all.  It's a protection racket.  With a dash of industrial espionage thrown
in for good measure.

This isn't something we should be booby trapping IETF standards with.

The IETF has disclosure rules that are aimed at avoiding, so much as is
possible, this sort of Don't ask Don't tell nonsense.  And yet we *still*
don't have disclosures from the H.264 IPR holders that *are* present here
for the use of H.264 in this standard.  Despite them having core dumped
their IPR restrictions on alternative proposals.

How can we possibly take mandating that technology seriously in this light?

That alone should already rule this out from consideration.

> If people have questions about specific use case I'm glad to try and get
> them answers. 

The specific question about how the Cisco offer resolves the problem of
MPEG LA not being the only holder of IPR that would need to be licenced
has so far met with deafening silence.

Glad answers to that would certainly be nice.

People keep making claims about that offer "solving everything", which
can't possibly be true unless you pretend those other licence holders
don't exist.

By comparison, Google at least has shown that it is *very* willing to
do whatever is necessary to ensure that the licence and IPR of VP8 is
very unambiguously exactly as they claim it to be.

That seems a lot more reassuring than the state of denial that has
surrounded promoting H.264.  First pretending the IPR wasn't a problem,
then pretending they could buy us all free tickets, then claiming they
"really wished there was a solution with no IPR burden", then rejecting
that solution when it was actually presented as a compromise.

Then pushing for getting the IETF to vote ...

The number of dimensions in which we'd have to disconnect from reality
to make this proposal acceptable makes even string theory start to look
well grounded.