Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"

[Kaiduan Xie <[e-mail]>]

"if an implementer gets sued they can simply drop the codec"

Thing is not that simple as "simply drop the codec", for some case you
still have to pay a lot of money.

/Kaiduan


On Wed, Nov 13, 2013 at 3:54 PM, cowwoc <[e-mail]> wrote:

> Hi John,
>
> First, thanks for summarize the positions brought up in the meeting.
>
> A few weeks ago I advocated making both H.264 and VP8 MTI with the
> reasoning that if an implementer gets sued they can simply drop the codec,
> notify the community, and have that codec removed en-mass from the
> specification. A few months later we would replace it with another MTI
> codec. According to what you wrote above, Cisco is under the impression
> that once a codec is MTI they cannot drop it even if they get sued.
>
> Practically speaking, is that really true? I mean, if the specification
> requires everyone to implement both VP8 and H.264 and one implementer
> temporarily drops one of the codecs, shouldn't things keep on working until
> the lawsuit is over (codec returns) or the community replaces the codec
> with another?
>
> Thanks,
> Gili
>
>
> On 13/11/2013 11:55 AM, John Leslie wrote:
>
>> Mike Linksvayer <[e-mail]> wrote:
>>
>>> I strongly support VP8 for MTI, and oppose H.264. Undecided on which
>>> of both, either, or neither would be second best.
>>>
>>     I'm _very_ glad you care which is "second best!"
>>
>>     I went into last week's session quite prepared to accept either, both
>> or neither. I came out unwilling to support _either_ as MTI.
>>
>>     This is mostly because I came to understand the "cisco" postition.
>>
>>     (Please excuse me for assigning names to the two main positions, but
>> it will make the discussion _much_ simpler.)
>>
>>     The "cisco" position is:
>>
>> - look at all the H.264 hardware out there: we must make use of it;
>> - if VP8 is MTI, we'll get sued and our customers will get hassled.
>>
>>     The "linux" position is:
>>
>> - look at all the VP8 software out there: we must make use of it;
>> - if H.264 is MTI, we'll get sued and our customers will get hassled.
>>
>>     And, alas, they're both right.
>>
>>     What I didn't understand before the presentations was why Cisco
>> believes they'll get sued over VP8, but not H.264.
>>
>>     Basically H.264 has quite a consortium to slap down the likes of
>> Nokia in court should they sue anyone in the consortium. This greatly
>> reduces the chance of Nokia's lawyer suing.
>>
>>     But this consortium won't lift a finger if Nokia sues Cisco over
>> VP8. Cisco is a _very_ attractive target over VP8.
>>
>>     Thus, Cisco management would _very_much_ prefer that VP8 _not_ be
>> MTI. They probably won't implement it.
>>
>>     Conversely, of course, "linux" management would _very_much_ prefer
>> that H.264 not be MTI. They probably won't implement it.
>>
>>     Understanding this, I now strongly recommend against making either
>> H.264 or VP8 MTI. (And I will not consent to a RFC 3929 process limited
>> to choosing between them.)
>>
>>     This issue has dragged on long enough already. We need to start
>> reading the riot act to the folks who claim we "need" either of these
>> as MTI in order to have "satisfied" users.
>>
>>     Both H.264 and VP8 deserve "SHOULD implement" status. Neither,
>> IMHO, will achieve consensus for "MUST implement" status. Yes, this
>> is a sorry state to find ourselves in. But the marketplace has
>> sorted out much worse problems in my memory.
>>
>>     And I claim that both camps are actually more likely to implement
>> (or allow extensions for) the other side's codec if it is _not_ MTI,
>> simply because they can back out at the first sign of lawyers.
>>
>>     I will not go into any details about how VP8 endpoints might talk
>> to H.264 endpoints, but I'm _very_ confident ways will be found if
>> we actually _publish_ an RFC saying both are "SHOULD implement".
>>
>>     (Surely I'm not the _only_ person who'd like to see _both_ H.264
>> and VP8 legacy devices using our standard...)
>>
>> --
>> John Leslie <[e-mail]>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>