Re: [rtcweb] Proposal for H.263 baseline codec
"Kevin P. Fleming" <kpfleming@digium.com> Fri, 20 April 2012 21:50 UTC
Return-Path: <kpfleming@digium.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 962A721F851B for <rtcweb@ietfa.amsl.com>; Fri, 20 Apr 2012 14:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.953
X-Spam-Level:
X-Spam-Status: No, score=-105.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rizD2nvrXIjr for <rtcweb@ietfa.amsl.com>; Fri, 20 Apr 2012 14:50:47 -0700 (PDT)
Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4F08521F850C for <rtcweb@ietf.org>; Fri, 20 Apr 2012 14:50:47 -0700 (PDT)
Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from <kpfleming@digium.com>) id 1SLLj4-0000vx-6O for rtcweb@ietf.org; Fri, 20 Apr 2012 16:50:46 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 319021A2006 for <rtcweb@ietf.org>; Fri, 20 Apr 2012 16:50:46 -0500 (CDT)
Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zqf797JiSOV3 for <rtcweb@ietf.org>; Fri, 20 Apr 2012 16:50:45 -0500 (CDT)
Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 9047F1A2001 for <rtcweb@ietf.org>; Fri, 20 Apr 2012 16:50:45 -0500 (CDT)
Message-ID: <4F91DA2F.1080406@digium.com>
Date: Fri, 20 Apr 2012 16:50:39 -0500
From: "Kevin P. Fleming" <kpfleming@digium.com>
Organization: Digium, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
CC: "rtcweb@ietf.org" <rtcweb@ietf.org>
References: <CB9A41D4.853AB%stewe@stewe.org>, <4F91C613.4050701@digium.com> <BCB3F026FAC4C145A4A3330806FEFDA94086731B60@EMBX01-HQ.jnpr.net>
In-Reply-To: <BCB3F026FAC4C145A4A3330806FEFDA94086731B60@EMBX01-HQ.jnpr.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rtcweb] Proposal for H.263 baseline codec
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Apr 2012 21:50:48 -0000
On 04/20/2012 04:19 PM, Gregory Maxwell wrote: > pfleming@digium.com 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 >> 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), > > Stop. All of you are confused. > > Maybe I can help— > > There are _two_ VP8 patent license grants: > > One for the specification: http://www.webmproject.org/license/bitstream/ > One for the software: http://www.webmproject.org/license/additional/ > > These grants are subtly different in the scope of what they cover. > > There are important licensing drafting reasons for a construction > which distinguishes "an implementation" and "any implementation". > In particular, the license drafter writing this kind of a royalty free > license has a tricky time making sure that the permission is broad > enough to include all the correct coverage, but not so over-broad that > a malicious implementer could (e.g.) add a search engine to their VP8 > encoder and claim that the VP8 license entitles them to search patents. > > So, the drafter says something like— "those patent claims [...] that > are necessarily infringed by implementation of this specification", > which achieves the desired limited scope— and that is _all_ you get > with the MPEG-LA pool patent licenses. This is what the Google bitstream > spec license provides. > > But, if we're to be serious and honest about making a royalty free format > and implementation that permission isn't quite sufficient: The reference > implementation might practice some VP8 related techniques which are not > "necessarily infringed"— they're helpful performance enhancements, > they could simply be one option out of many ways of doing the same thing, > or could just be something that was incidentally included (or even a > malicious patent trap snake in the grass)— and so it's important that > everything in the reference software also be licensed— even if its not > "necessarily infringed" by the specification. But since it's not a > goal to also license unrelated things that a downstream user may cram in > (e.g. a search engine), that license must be limited in scope to things > which are actually in the reference implementation: "This grant does not > include claims that would be infringed only as a consequence of further > modification of this implementation." (this language is actually almost > identical to the language for this purpose in the GPL, FWIW) > > So, in summary: > > You are licensed, via the bitstream license, for anything Google controls > which is necessary to implement the specification— in hardware, > software, home grown, or reference implementations. This is pretty > much as strong a grant as you can find anyone offering for any other > format specification. > > You are also licensed, via the additional rights license, for any > use of the VP8 reference implementation including modified versions, > limited to the extent that the modifications don't expand the scope of > the coverage. (Exactly as the GPL explicit patent grant does) > > This has already been clarified by Google on this list: > "Google confirms that the VP8 patent grant applies to both > third-party hardware and software implementations of VP8." > http://www.ietf.org/mail-archive/web/rtcweb/current/msg04006.html > > I admit that the fact that there are two similar but distinct licenses > is a little confusing, but I don't understand why we have to go over > it again and again on this list. I would think that the prior Google > comment would have been sufficiently definitive. Well, I apologize, somehow I missed that while catching up on this list. Your explanation certainly covers my concerns; the patent grant allows us to distribute modified versions, as long as they don't infringe on any patents that aren't necessarily infringed by the reference implementation. Thanks for the clue-bat :-) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org
- Re: [rtcweb] Proposal for H.263 baseline codec Basil Mohamed Gohar
- Re: [rtcweb] Proposal for H.263 baseline codec Stephan Wenger
- Re: [rtcweb] Proposal for H.263 baseline codec Basil Mohamed Gohar
- [rtcweb] Proposal for H.263 baseline codec Dean Willis
- Re: [rtcweb] Proposal for H.263 baseline codec Lorenzo Miniero
- Re: [rtcweb] Proposal for H.263 baseline codec Markus.Isomaki
- Re: [rtcweb] Proposal for H.263 baseline codec Bernard Aboba
- Re: [rtcweb] Proposal for H.263 baseline codec Piers O'Hanlon
- Re: [rtcweb] Proposal for H.263 baseline codec Basil Mohamed Gohar
- Re: [rtcweb] Proposal for H.263 baseline codec Stephan Wenger
- Re: [rtcweb] Proposal for H.263 baseline codec Stephan Wenger
- Re: [rtcweb] Proposal for H.263 baseline codec Basil Mohamed Gohar
- Re: [rtcweb] Proposal for H.263 baseline codec Silvia Pfeiffer
- Re: [rtcweb] Proposal for H.263 baseline codec Paul E. Jones
- Re: [rtcweb] Proposal for H.263 baseline codec Silvia Pfeiffer
- Re: [rtcweb] Proposal for H.263 baseline codec Paul E. Jones
- Re: [rtcweb] Proposal for H.263 baseline codec Marshall Eubanks
- Re: [rtcweb] Proposal for H.263 baseline codec Randell Jesup
- Re: [rtcweb] Proposal for H.263 baseline codec Gregory Maxwell
- Re: [rtcweb] Proposal for H.263 baseline codec Marshall Eubanks
- Re: [rtcweb] Proposal for H.263 baseline codec Randell Jesup
- Re: [rtcweb] Proposal for H.263 baseline codec Dean Willis
- Re: [rtcweb] Proposal for H.263 baseline codec Kevin P. Fleming
- Re: [rtcweb] Proposal for H.263 baseline codec Basil Mohamed Gohar
- Re: [rtcweb] Proposal for H.263 baseline codec Harald Alvestrand
- Re: [rtcweb] Proposal for H.263 baseline codec Kevin P. Fleming
- Re: [rtcweb] Proposal for H.263 baseline codec David Benham (dbenham)