Re: [rtcweb] H.261

Ron <> Sat, 23 November 2013 00:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 732BB1AE21A for <>; Fri, 22 Nov 2013 16:36:50 -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] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oUMJlDebLCpd for <>; Fri, 22 Nov 2013 16:36:48 -0800 (PST)
Received: from ( [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by (Postfix) with ESMTP id 15B8E1AE1CB for <>; Fri, 22 Nov 2013 16:36:47 -0800 (PST)
Received: from (HELO audi.shelbyville.oz) ([]) by with ESMTP; 23 Nov 2013 11:06:39 +1030
Received: from localhost (localhost []) by audi.shelbyville.oz (Postfix) with ESMTP id 881644F8F3 for <>; Sat, 23 Nov 2013 11:05:49 +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 2P4HmIVfB+Ap for <>; Sat, 23 Nov 2013 11:05:48 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 706C14F902; Sat, 23 Nov 2013 11:05:48 +1030 (CST)
Date: Sat, 23 Nov 2013 11:05:48 +1030
From: Ron <>
Message-ID: <20131123003548.GD3245@audi.shelbyville.oz>
References: <> <> <> <> <> <> <> <> <> <>
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: Sat, 23 Nov 2013 00:36:50 -0000

On Fri, Nov 22, 2013 at 03:45:02PM -0800, David Singer wrote:
> On Nov 22, 2013, at 14:44 , Basil Mohamed Gohar <> wrote:
> > On 11/22/2013 05:01 PM, Adam Roach wrote:
> >> On 11/22/13 14:22, Daniel-Constantin Mierla wrote:
> >>> They plan to release the sources under BSD, but who wants to use them
> >>> directly, they have to deal with mpeg-la. 
> >> 
> >> 
> >> Every time this kind of statement is made without also including "if
> >> they distribute more than 100,000 copies a year", it's a bald
> >> misrepresentation of the situation.
> >> 
> >> I'm not saying the 100,000-copy exemption is a silver bullet. But it
> >> sure does cut down the number of people who have to deal with MPEG-LA,
> >> and completely addresses the "what if I want to have a enterprise disk
> >> image?" question. And ignoring it to exaggerate your case doesn't do
> >> anyone any favors.
> >> 
> >> /a
> > 
> > Free software projects do not have a reliable mechanism by which to
> > count their distribution, since it is sent out through many means, not
> > the least of which can include direct downloads, SCM code checks (e.g.,
> > Github), GNU/Linux and *BSD distibutions (which can easily exceed
> > 100,000 for the most popular ones), to name a few.
> > 
> > Where does the liability for counting lie in each of these cases?  The
> > licensing restrictions that MPEG-LA has placed on H.264 is very
> > free-software unfriendly for any cases where you want rights to be
> > transitive - which is a key, fundamental aspect of software freedom.
> Curiously, I think that the position is that if you distribute source (e.g.
> of FFMPeg, X264) then the person who compiles it is making the final product,
> so if everyone builds it themselves, they are in a product distribution group
> size of 1.

The whole point of many distros is to supply binaries, often built
many times for many different system architectures.  So even when
source copies are also distributed there's a large multiplier for
binaries, which is then multiplied again by uncountable tiers of
(both public and private) distribution mirrors.

And many projects available as source also produce binary releases,
in particular for systems where people aren't used to building
binaries for themselves (like Windows and OSX).  These also are
often mirrored by other services that specialise in this (but
provide no auditable account of downloads) - often without the
knowledge of, and almost always without asking the permission of,
the original binary creator, as is their right for any freely
licenced software.

Then maybe you've heard of this newfangled thing called CDN ...

The problem is quite simply intractable without a major change to
the H.264 licencing scheme.

No amount of saying "well my homepage never gets 100k hits", and
"my appstore app only had 20 downloads" is really going to change
that a 100,000 download limit is effectively the same as a Zero
download limit on an internet that wasn't designed to count every
copy of every thing made by every user.

Once you publish it anywhere you have no idea how short a time it
will take to exceed that.  And you can't even take it back down
again, even if you wanted to.  And if somebody claims you have made
X copies, based on some fuzzy math, you have no way to dispute that
except with more fuzzy guesswork.

If H.264 is really this important to you, for reasons other than
vendor exclusivity and lock-in, then do what Google did, go and
buy out the licence holders and put it under a useable licence.
If "nobody is making any money out of this" as they all claim,
then it should even be pretty cheap, right?

People might actually Really Genuinely thank you for that :)