Re: [rtcweb] Finishing up the Video Codec document, MTI (again, still, sorry)

[David Singer <[e-mail]>]

Hi Ted

> On Dec 5, 2014, at 14:32 , Ted Hardie <[e-mail]> wrote:
> 
> Hi David,
> 
> On Fri, Dec 5, 2014 at 1:42 PM, David Singer <[e-mail]> wrote:
> 
> ​
> ​(Much snipped)​
> 
>> It really is not similar.  Maybe there are licenses that one or other does not carry:  in the Cisco case, we are unaware of any “unwilling to license”, whereas for VP8 there is a clear statement that no license can be had. 
>> 
> ​In both cases, the participant needs to assess whether they know of all the salient IPR, whether they have all the licenses for that IPR which they need.   While I am not a lawyer, I imagine that in both cases that would involve making a determination of the relevance of the claim as well as an analysis of its license terms.  It also involves an assessment of the risk that there are other claims which may later arise.
> 
> To my lay person's eyes, the two assessments do look pretty similar.  It appears, honestly, that you disagree with the results' of others assessments, rather than that the assessments do not need to take place in both cases.  But I may be misunderstanding your point.

OK, let me see if I can persuade you of a qualitative difference.  For each ‘must’, what is the nature and availability of licenses that I might need from those claiming IPR?

* H.264: all those claiming IPR offer licenses, though most of them ask for payment
* VP8: almost all offer licenses that are either free or effectively so (pre-paid, in the case of the MPEG-LA), but there is one for which no license is available (and it’s not an insignificant company, or one not active in the field, or a small set of patents)

For me, that is a major difference.  Clearly for others (e.g. Ron who has said as much), the cost is more significant than the license availability.

I think inserting the ‘must’ here means that companies will either ignore it, or claim not to be a WebRTC Browser, neither of which advance the cause of interoperability at all.  If, in fact, we expect there to be a significant number of WebRTC Endpoints, and that we expect that they will be sometimes at both ends of a call, then this tentative agreement already has given up on ensuring interop, and I suggest we simply move to the webRTC Endpoint requirements and delete the webRTC Browser one.  (We could enhance it in various ways: add a ‘recommend both at least for decode’, for example.)


David Singer
Manager, Software Standards, Apple Inc.