Re: [rtcweb] VP8 IPR agreement announced.

Jean-Marc Valin <jmvalin@mozilla.com> Thu, 07 March 2013 20:55 UTC

Return-Path: <jmvalin@mozilla.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 EBF2121F8581 for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 12:55:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.762
X-Spam-Level:
X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
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 df-PR97ZAyiE for <rtcweb@ietfa.amsl.com>; Thu, 7 Mar 2013 12:55:21 -0800 (PST)
Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id F292B21F853D for <rtcweb@ietf.org>; Thu, 7 Mar 2013 12:55:20 -0800 (PST)
Received: from [192.168.1.15] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 00513F2356; Thu, 7 Mar 2013 12:55:19 -0800 (PST)
Message-ID: <5138FEB7.3060807@mozilla.com>
Date: Thu, 07 Mar 2013 15:55:19 -0500
From: Jean-Marc Valin <jmvalin@mozilla.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Matthew Kaufman <matthew@matthew.at>
References: <CAMKM2Lx4MD4sHnCRCoOMowLXkGpt6mO+6vaX39kuxPXDPY1uFA@mail.gmail.com> <5138EB62.9000700@matthew.at>
In-Reply-To: <5138EB62.9000700@matthew.at>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 IPR agreement announced.
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: Thu, 07 Mar 2013 20:55:22 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I would propose that we actually have the discussion in Orlando, while
assuming that the Google license will make it possible for everyone to
implement VP8 with no additional restriction (and in compliance with
the W3C's licensing policies). If it turns out that the license has
unacceptable terms (with Google not willing to fix the issue), then we
can always revisit any decision. Sounds reasonable?

	Jean-Marc

On 03/07/2013 02:32 PM, Matthew Kaufman wrote:
> The below announcement, while an interesting development, comes
> weeks after the traditional deadlines for providing new information
> to the working group prior to an upcoming meeting and certainly
> does not give me enough time to adequately review the development.
> In fact, the sublicense terms referenced below will not be
> available to review until *after* the upcoming meeting and might
> very well contain language that is incompatible with my
> requirements or those of other implementers of RTCWEB
> specifications.
> 
> Therefore I believe the most sensible action is to once again delay
> the MTI video codec discussion, remove it from the agenda from the
> upcoming meeting, and have the call for an MTI codec at a later
> time? no sooner than several weeks after the relevant license terms
> are even available to review. I hope the chairs concur.
> 
> Alternatively, we can have the discussion at the upcoming meeting,
> but it will not be able to incorporate this development at all, and
> without any change in the IPR situation it was clear that H.264 was
> the only suitable alternative (and may still be the best choice,
> given the strong arguments for the technical merits and
> implementation advantages of H.264, irrespective of the IPR
> issues).
> 
> Matthew Kaufman
> 
> On 3/7/2013 11:18 AM, Serge Lachapelle wrote:
>> Hello,
>> 
>> Today, Google Inc. and MPEG LA, LLC have announced that they
>> have entered into an agreement granting Google a license to
>> techniques, if any, that may be essential to VP8. Furthermore,
>> MPEG LA has agreed to discontinue efforts to form a patent pool
>> around VP8.
>> 
>> The official press release can be found here:
>> http://goo.gl/F7xUu
>> 
>> The licensors are part of the group that responded to MPEG LA?s
>> call for patents. They are a group of well-known video IP holders
>> and participants in standards-based video patent pools.
>> 
>> This agreement allows for Google to sublicense the techniques to
>> any user of VP8, whether the VP8 implementation is by Google or
>> another entity; this means that users can develop independent
>> implementations of VP8 and still enjoy coverage under the
>> sublicenses.
>> 
>> Google intends to license the techniques under terms that are in
>> line with the W3C?s definition of a Royalty Free License. This
>> definition can be found here:
>> http://www.w3.org/2001/07/SVG10-IPR-statements  We anticipate
>> having the sublicense ready in the next few weeks. The terms will
>> appear on the WebM Project website at http://webmproject.org
>> 
>> This agreement is not an acknowledgment that the licensed
>> techniques read on VP8. The purpose of this agreement is meant to
>> provide further and stronger reassurance to implementors of VP8.
>> 
>> 
>> On a personal note, I think you will all agree that the RTCWeb
>> MTI video codec discussion included many whispered doubts but
>> little evidence. In contrast, we have taken clear steps to
>> demonstrate the viability of VP8:
>> 
>> 1. Made VP8 available with a strong, simple software license and 
>> patent grant. 2. Continued to innovate and improve VP8 in the
>> open. 3. Licensed a royalty free VP8 enabled RTL (aka hardware
>> source code) to more than 50 SOCs. 4. Built, iterated and
>> launched VP8 powered WebRTC in the Chrome browser to hundreds of
>> millions of users. 5. Worked to ensure WebRTC interop using the
>> VP8 and Opus formats by working closely with Firefox. 6.
>> Introduced a preview of VP8 and Opus based WebRTC in Chrome for 
>> Android beta.
>> 
>> And now, we have taken taken two significant steps that we hope
>> will make the situation clear to all:
>> 
>> 7. Submitted VP8 to ISO SC29/WG11 (MPEG) in January of this year
>> for standardization. 8. Invested a significant amount of time and
>> resources into reaching an agreement with the MPEG LA, to provide
>> further reassurances.
>> 
>> VP8 is a royalty free, open sourced codec that offers several 
>> advantages and innovations for real time and other uses.  It has
>> a publicly-available specification that is getting broadly
>> adopted in hardware; it has been submitted for standardization to
>> a leading standards body, and is the subject of a royalty-free
>> RAND license which will now include a license covering any
>> essential VP8 techniques that may be relevant to major IP holders
>> who responded to the MPEG LA's call for VP8 patents.
>> 
>> It is the most suitable codec for MTI.
>> 
>> I understand the timing is very close to the Orlando IETF
>> meeting. While we tried to do this as quickly as possible, I am
>> sure you will appreciate the sensitivities and enormous effort
>> involved in reaching such an agreement.
>> 
>> I will be in Orlando, arriving monday evening and will be
>> available to answer questions.
>> 
>> /Serge
>> 
>> 
>> _______________________________________________ rtcweb mailing
>> list rtcweb@ietf.org 
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
> 
> _______________________________________________ rtcweb mailing
> list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJROP62AAoJEJ6/8sItn9q937sH/06VBoOteO+VVbS8dk+PXE5W
oRc6KmoH0AfCFEs90FIIJHmvIur+lnenoceoFn3fCTTJcO9FyAfFuh9+XagPzETe
6DjdX42LCAsgQ+1OcVLJ5XikXGu3XGGQecJ3zGJN27wc5aochdu3+cSh6iQg8L/D
sfgKkoilPyxo/N+O+texRLi6nsx/YM/xeKR7Z5aJ5EMd8RMMZ9054Lpz6v62aLRL
+GuKGdPD95FrMTTPuCSYEx6DRdizM5wYLnknZS9RHVgkA1Da/t9qx9gxAsWfNvjN
dfESIwbA9ZipUgUeRZ4kBPqqQGaV8C2oU8rG23pBykS2h5MG5NfOz7f83Lx8Gq4=
=f7ae
-----END PGP SIGNATURE-----