Re: [rtcweb] Proposal for H.263 baseline codec

Basil Mohamed Gohar <> Fri, 20 April 2012 20:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB8A821F85AF for <>; Fri, 20 Apr 2012 13:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iBkvAFVbGzy4 for <>; Fri, 20 Apr 2012 13:28:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1E5EA21F8566 for <>; Fri, 20 Apr 2012 13:28:15 -0700 (PDT)
Received: from [] ( []) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 61DA76430F8 for <>; Fri, 20 Apr 2012 16:28:14 -0400 (EDT)
Message-ID: <>
Date: Fri, 20 Apr 2012 16:28:12 -0400
From: Basil Mohamed Gohar <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Proposal for H.263 baseline codec
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: Fri, 20 Apr 2012 20:28:16 -0000

On 04/20/2012 04:24 PM, Kevin P. Fleming wrote:
> On 03/29/2012 09:53 AM, Stephan Wenger wrote:
>> The other issue, though (the fact that the license grant extends only to
>> the VP8 implementation as provided by google, and does not extent to
>> derivative works such as hardware implementations) should be moderately
>> alarming even for an open source person.  With respect to this clause, I
> <snip>
> This is concerning, even for us open source software distributors. In
> fact, a similar situation existed some time ago with iLBC; the license
> that GIPS offered covered only the code as distributed as part of the
> RFC (although the language stating this was quite poorly constructed),
> and that code had (and still has) fundamental issues (it has at least
> two places where it invokes 'undefined behavior' according to the C
> standard). When we fixed these problems in our distribution, and then
> I re-read the license, I realized that the license did not allow us to
> distribute this modified version. We later managed to get explicit
> permission from Google to distribute a modified version, as they have
> changed the license to no longer have this restriction.
> The WebM patent license has much of the same problem, though: it only
> applies to distributions of the code made by Google, without changes
> (no derivative works). At least, this is my reading of it, being an
> engineer married to a lawyer who handles such things, but not a lawyer
> myself :-)
The answer that I have seen mentioned is simply that Google cannot know
what patents someone is infringing on if they extend or modify the code
or make an independent implementation.  One thing that I do know is a
completely independent implementation is being done by some of the
developers of x264 (and naming their project xvp8 as a result), and this
is happening with the implicit blessing of Google, because development
is being tracked in the #vp8 channel on FreeNode.

So, Google is fine with this kind of development happening.  However,
having explicit license for this kind of behavior would be much better,
and is sorely needed, considering all the other challenges facing VP8

Libre Video