Re: Alternative decision process in RTCWeb

Eric Burger <eburger@standardstrack.com> Sat, 30 November 2013 15:56 UTC

Return-Path: <eburger@standardstrack.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C721AE43C for <ietf@ietfa.amsl.com>; Sat, 30 Nov 2013 07:56:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.121
X-Spam-Level:
X-Spam-Status: No, score=-3.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, LOTS_OF_MONEY=0.001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emoj13pOsF_i for <ietf@ietfa.amsl.com>; Sat, 30 Nov 2013 07:56:48 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 731561AE44D for <ietf@ietf.org>; Sat, 30 Nov 2013 07:56:48 -0800 (PST)
Received: from ip68-100-74-215.dc.dc.cox.net ([68.100.74.215]:52875 helo=[192.168.15.104]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <eburger@standardstrack.com>) id 1VmmuM-0002WU-F8; Sat, 30 Nov 2013 07:56:41 -0800
Content-Type: multipart/signed; boundary="Apple-Mail=_141DFE0E-3EA2-4645-B9FA-95C7E935508F"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Subject: Re: Alternative decision process in RTCWeb
From: Eric Burger <eburger@standardstrack.com>
In-Reply-To: <D9F35A16-58D8-4F7F-A640-3E9B0A341BD8@iii.ca>
Date: Sat, 30 Nov 2013 10:28:56 -0500
Message-Id: <AFC22981-4D07-4ACB-9383-3D5812CB0228@standardstrack.com>
References: <52970A36.5010503@ericsson.com> <529719D7.9020109@cisco.com> <CAMm+LwgF-NL=LxaAjkVPVVO6a1oevLvvNqYxn6ug5w-zxdez3Q@mail.gmail.com> <D9F35A16-58D8-4F7F-A640-3E9B0A341BD8@iii.ca>
To: IETF Discussion <ietf@ietf.org>
X-Mailer: Apple Mail (2.1822)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: rtcweb-chairs@tools.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Nov 2013 15:56:51 -0000

Correct me if I am mistaken. I think the following two messages say is:
	(1) just about everyone has IMPLEMENTED both H.264 and VP8
	(2) people are worried about the availability or lack thereof of H.264 free licensing
	(3) people are [should be] worried about lawsuits resulting from the use of H.264 or VP8

Frankly, I am now fully in Sam’s camp:
On Nov 28, 2013, at 10:35 AM, Sam Hartman <hartmans-ietf@mit.edu> wrote:
> I'd personally favor coin-flips, external arbitors or similar over
> voting.  We don't want to encourage voting because we could get into
> situations where people block the consensus process in order to force a
> vote.  Absent things like well-defined membership and procedures to
> avoid one company stuffing the ballot box, going there seems
> problematic.
> 
> Coin flips are nice.  They really create pressure among anyone who
> actually cares about the outcome to compromise, to explore whether a
> consensus can be built.  However for the frequent situations where a
> decision is critical but it really doesn't matter (even if some people
> think it does), they get the job done.

We are way beyond picking a technically better solution. They smell like even trade-offs. We are way beyond picking a businessly better solution. They are both promised to be either free, nearly free, or you-might-have-to-license-but-the-platform-you-run-on-already-has-a-paid-license-so-it-is-free. We cannot tell which codec has less legal liability. Well, it is clear H.264 has more deterministic liability, but VP8’s liability today is literally unbounded.

At this point, the King Solomon Solution <http://en.wikipedia.org/wiki/Judgment_of_Solomon> is the solution. Cut the baby in half. See who blinks. I need practice with my Tai QI sword - I will be happy to provide the blade.


On Nov 28, 2013, at 6:05 PM, Cullen Jennings <fluffy@iii.ca> wrote:

> 
> On Nov 28, 2013, at 3:45 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> 
>> The issue here is different, the question is whether the people who write an deploy code can come to a consensus. A vote is not  going to make that happen. If the WG votes for X but a browser provider with 30% of the market insists that they won't do X, a vote is not going to change matters.
> 
> As a quick cheat sheet to where browser vendors might stand on this matter...
> 
> There are four major browsers. Firefox has said they will implement the standard and everyone I have talked to in the WG believe they will regardless of this video codec choice. Chrome awhile back said they will implement the standards but they have not updated that opinion recently. Many people believe they will implement the standard regardless of this choice (keep in mind Chrome already has both 264 and VP8 in it for the video tag). IE and Safari has not said if they will do WebRTC at all.
> 
> Mozilla plans to support both VP8 and H.264 and as far as I can tell prefers Daala. Google prefers VP8. Apple and Microsoft prefer H.264. 
> 
> From an IPR point of view. Mozilla plans to support both VP8 and H.264. Chrome, IE, and Safari already use 264 and license the IPR. And Chrome also uses VP8.


On Nov 29, 2013, at 1:22 PM, Stephan Wenger <stewe@stewe.org> wrote:

> Hi,
> I agree with the basic sentiment of Philip’s email.  However, in the (perhaps forlorn) hope to shed some light into the IPR situation, allow me to correct inline below some aspects of it that were painted in an overly broad brush.  I hope my characterization is reasonably impartial.  All aspects below were discussed on the rtcweb list ad nauseam, and in much greater detail.
> Stephan
> 
> From: Phillip Hallam-Baker <hallam@gmail.com>
> Date: Thursday, 28 November, 2013 at 14:53 
> To: Dave Cridland <dave@cridland.net>
> Cc: IETF Discussion <ietf@ietf.org>, Dave Crocker <dcrocker@bbiw.net>, "rtcweb-chairs@tools.ietf.org" <rtcweb-chairs@tools.ietf.org>
> Subject: Re: Alternative decision process in RTCWeb
> 
> 
> 
> 
> On Thu, Nov 28, 2013 at 10:04 AM, Dave Cridland <dave@cridland.net> wrote:
> On Thu, Nov 28, 2013 at 2:40 PM, Dave Crocker <dhc@dcrocker.net> wrote:
> BTW, as distasteful as it might be, is there a reason that making /both/ MTI would not work?
> 
> […]
> 
> The issues for vendors are litigation risk and cost.
> 
> If you are a commercial vendor with an existing H.264 license there is no cost and no litigation risk for using that codec but the licenses you have acquired are almost certainly specific to H.264. So using any other CODEC is likely to create a substantial liability risk.
> 
> StW: A commercial vendor with an obtained pool license and current on your reports and your bill has a license and insofar there is virtually no litigation risk from the 30 pool members.  I write “virtually no risk”, because fraudulent lawsuits are not exactly unheard of, and there is nothing one can do about those.  The cost is $0.00 or $0.20 or $0.10 per codec, depending on volume.  According to Cisco, even without a license of your own, the cost can be $0 if your product implements the download mechanism they offer.  Note that the definition of “codec” in the MPEG-LA agreements is hardware centric and difficult to interpret in a software environment.  So there is cost (although potentially not for you). 
> Even with an MPEG-LA license, there also is litigation risk from those rightholders who are not pool members, which is a not insignificant percentage.  However, the monetary damages that can reasonably be expected from licensing or litigation are, according to recent rulings, some of which are under appeal right now, quite low.  This is because H.264 and its patents were developed by a very broad community which agreed to license under RAND terms.  As there is not so much money to be made, the chance that a rightholder would litigate outside of a strategic context (smartphone wars, pool enforcement) is perhaps not overly high.  Of course, that is of little consequence once the multimillion $$$ bill from your lawyer rolls in.  H.264 essential patents have been litigated at least 4 times since 2003, sometimes as pool enforcement actions, and sometimes in the context of smartphone wars.  There are some 1200 licensees of the H.264 pool, including mega companies and little guys one has never heard of.
> 
> In terms of patentable technologies, VP8 is considered by many (including myself) mostly a subset of H.264.  (It contains a few additional features over H.264 but allow me to ignore those here.)  Insofar, one can expect that a subset of the H.264 essential patents may also ready on VP8, in addition to a few VP8 specific patents.  As far as licensing goes, Google has agreed to compensate 11 rightholders (that also happen to be H.264 rightholders) an undisclosed amount, and obtained a license from them which they generously make available to us, along with a license under their own patents, and subject to certain conditions which most people consider bearable.  So I think it’s safe to assume that these rightholders and google are not going to litigate over VP8.  As VP8 was not developed in an organization under RAND IPR policy terms, there is no RAND safety net.  Anyone other but the 12 companies above could theoretically sue over a VP8 patent and demand sun/moon/stars and/or injunctive relief.  Nokia has announced that they are not willing to license patents they believe read on VP8, see here:   https://datatracker.ietf.org/ipr/2035/.  Nokia has also asserted allegedly VP8 essential patents against HTC in (at least) two distinct lawsuits in Germany and one ITC complaint.  One of the lawsuits is dismissed and under appeal and the second is stayed pending an invalidation procedure (something the German courts do only if they consider it likely that the patent is invalid as granted).  AFAIK, the ITC complaint is still in the procedural warm-up phase.  My personal take on these lawsuits is that they have to be seen in the greater context of the smartphone patent wars.  I may be wrong.   However, if I’m right, then there will probably be a settlement in the not too distant future, with terms unpublished, the lawsuits go away, and we would all be none the wiser. /StW
> 
> If you are an open source provider without a H.264 license the situation is very different.
> 
> StW: Yes, it is different.  H.264 implementations have been available in open source form, since at least 2006.  They have been part of major Linux distributions forever.  I’m following the litigation environment related to video codecs quite closely, and I have not heard of a single lawsuit against an open source developer or distributor regarding video codecs, including H.264.  All that  is also true for VP8, except that VP8 is newer.  /StW
> 
> This is not going to be settled by a vote. I am not speaking for any of the parties but if I did have a dog in this fight I would have my corporate counsel write a letter to the WG stating that we are not going to be bound on the WG decision in this case.
> 
> StW: I don’t think that such a letter is needed.  IETF RFCs, or parts thereof, are regularly ignored by the implementer community, sometimes to the detriment and sometimes to the benefit of the Internet at large.  There’s no standard’s police that could enforce compliant implementations. /StW
> 
> 
> We are talking about a decision that could result in a hundred million dollar lawsuit. The issue is not who is going to write code but who is likely to get hit with a suit.
>  
> 
> -- 
> Website: http://hallambaker.com/