Re: [rtcweb] Input to Video Codec Selection

[Stephan Wenger <[e-mail]>]

Hi all,

On 3.3.2013 07:38 , "Cullen Jennings" <[e-mail]> wrote:

>
>Harald,
>
>The IPR disclosure says RF but the grant at webm pages is not RF. It
>includes 
>
> If You or your agent or exclusive licensee institute or order or agree
>to the institution of patent litigation against any entity (including a
>cross-claim or counterclaim in a lawsuit) alleging that any
>implementation of this specification constitutes direct or contributory
>patent infringement, or inducement of patent infringement, then any
>rights granted to You under the License for this specification shall
>terminate as of the date such litigation is filed.

If we were going into the business of analyzing reciprocity clauses in the
IETF, we would have so much fun.  Well, Cisco guys probably less so... :-)
 

I don't understand that discussion.  I didn't understand Gaelle's inquiry
for clarification on which license terms apply, either.  If there are two
licenses (or equivalent) being offered for approximately the same thing, a
potential licensor can choose the one most advantageous to him/her.  (At a
car dealership, if a car is offered for cash value, at certain leasing
terms, and at certain financing terms, the customer can choose dealer has
to honor all three.  Subject to conditions spelled out to either of the
three.  Same here.)

>
>So there seems to be some inconsistency here or perhaps the IPR grand on
>IETF page was just much broader than the one on webm page. Can you help
>make sure the IPR disclosure is correct? I also had the idea that IETF
>preferred if Google actually disclosed patents that google control as
>wells other that are known on VP8 in the disclosure.

That would indeed be helpful.

Even more helpful would be a patent landscape analysis, but I can
certainly understand why no such analysis has been provided.

>
>Cullen 
>
>
>
>On Mar 2, 2013, at 3:57 AM, Harald Alvestrand <[e-mail]>
>wrote:
>
>> 
>> On 03/01/2013 11:21 PM, Gaelle Martin-Cocher wrote:
>>> Dear All,
>>> 
>>> Further to Magnus email, while I assume there might not be "something
>>>new" to learn at the meeting, I believe the below requested
>>>clarifications on existing information would be useful.  Implementers
>>>should clearly know which license they can pick or get when it comes to
>>>VP8 and by which groups.  I believe answers in advance of the meeting
>>>would help the discussion at the meeting.
>>> 
>>> Questions 1 & 2:
>>> It is assumed that in  the case of choosing VP8, RTCWeb would
>>>reference  the informational RFC 6386.
>>> 
>> Yes, that is the intent.
>>> Q1: Is there an intent to move that RFC to the standard track at a
>>>point in time?
>> No. I don't personally see any benefit in doing so at this time.
>>> Q2: Would that change the rule of "who" is obliged to make an IPR
>>>declaration?
>> Speaking with my IETF-amateur-lawyer hat on (and as a former chair of
>>the IPR WG): No, it does not change the rule. The rule depends on
>>whether the technology in question is discussed in the IETF, not on the
>>nature of the contribution. RFC 3979 section 6.1.2 refers to
>>"Contribution", the definition of that term in RFC 3979 section 1 letter
>>j makes it completely explicit that RFC Editor Contributions are covered
>>by the term "Contribution".
>>> 
>>> Question 3:
>>> The IPR disclosure was made on the draft 2 of
>>>draft-bankoski-vp8-bitstream-02" as per
>>> 
>>>https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=63
>>>86
>>> 
>>> Draft 3 and onward contains the copyright license and the additional
>>>IP rights grant.
>>> Q3: Is the initial IPR disclosure still valid?
>>> 
>> Yes. RFC 3979 section 6.2.1.
>> 
>>    The IPR disclosure required pursuant to section 6.1.1 must be made as
>>    soon as reasonably possible after the Contribution is published in an
>>    Internet Draft unless the required disclosure is already on file.
>>    For example, if the Contribution is an update to a Contribution for
>>    which an IPR disclosure has already been made and the applicability
>>    of the disclosure is not changed by the new Contribution, then no new
>>    disclosure is required.
>> 
>>> 
>>> Question 4:
>>> The informational RFC 6386 contains the decoder code and some piece of
>>>encoder code.
>>> Though the IP rights grant mentioned in the RFC is offered against:
>>> 
>>>    "This implementation" means the copyrightable works distributed by
>>>    Google as part of the WebM Project."
>>> 
>>> Q4: As such the  IP rights grant does not seem to apply to the RFC
>>>itself or to an implementation of the code contained in the RFC.
>>>Should that be corrected or is that the intent?
>>> 
>> Speaking with WEBM hat on:
>> 
>> There are two grants - the grant of license to copyrighted works, and
>>the grant of license to patented technology.
>> 
>> Software license: http://www.webmproject.org/license/software/ -
>>classical 3-clause BSD.
>> Patent license 1: http://www.webmproject.org/license/bitstream/ -
>>covers any implementation that produces or consumes VP8 bitstreams.
>> Patent license 2: http://www.webmproject.org/license/additional/ -
>>covers usage of the implementation.
>> 
>>> 
>>> 
>>> Question 5:
>>> The additional IP grant is applied to a particular implementation
>>>(namely the WebM VP8 code) without modifications.
>>> Any derivative work either:
>>> - produced from the reference code in WebM (that is a possible
>>>optimized version of it); or
>>> - produced from the RFC text or the code provided within the RFC
>>>(while not using the WebM code)
>>> does not have the benefit of the additional IP grant.
>>> In other words a conformant implementation does not necessarily have
>>>the benefit of the additional IP grant.
>>> I am not confident that the VP8 code can be used "as is" for certain
>>>platforms. I would think that the code might need some modification to
>>>provide the desired performance. In other words, it should be clear
>>>that those implementers would not necessarily receive the benefit of
>>>that grant.
>>> If the answer to Q3 is negative, then there is no IP license statement
>>>at all that applies to a "conformant implementation of the RFC" (aka a
>>>derivative work).
>>> If the answer to Q3 is positive, it is not clear  how to reconcile the
>>>declaration inside the RFC and the declaration that is attached to the
>>>the RFC draft for implementers that would not modify the code.
>>> Q5: Can this be clarified or confirmed?
>>> 
>> All 3 of the pages referred to above permit the production of
>>derivative works. Quoth:
>> 
>> - bitstream: " ... license to make, have made, use, offer to sell,
>>sell, import, and otherwise transfer implementations of this
>>specification" (whether derived from the example code or not)
>> - copyright: ".... Redistribution and use in source and binary forms,
>>with or without modification, are permitted provided that.."
>> - patent: "... patent license to make, have made, use, offer to sell,
>>sell, import, transfer, and otherwise run, modify and       propagate
>>the contents of this implementation"
>> 
>> I believe there should be no issue here; modification is permitted.
>>>  
>>> 
>>> 
>>> Question 6:
>>> The IPR disclosure in IETF is different than the IPR statement made in
>>>MPEG (see document sent by Harald earlier).
>>> Q6: the differences in license statement and IP grant referring to
>>>WebM code are rather confusing. Can it be clarified which license,
>>>copyright, grant are provided for RFC 6386?
>>> 
>> The statement we made in MPEG was crafted to be as similar to others'
>>statements made in MPEG as possible, in order to respect MPEG's legal
>>language traditions - which in turn should minimize the need for
>>clarification of what was granted when discussing with     people used
>>to the MPEG language tradition.
>> 
>> We believe that the statement made in MPEG is wholly within the
>>statements made on the WEBM website - all permissions implied by the
>>statement in MPEG should also be permitted by the statements on the WEBM
>>website. We haven't tried to analyze whether there are cases where
>>someone can do something within the permissions granted on the WEBM
>>website that would not be permitted under the MPEG statement - the MPEG
>>statement was aimed to allow the document to progress within MPEG;
>>people who want to read the
>>> 
>>> 
>>> 
>>> In conclusion, before advancing this draft, or considering it as a
>>>candidate for RTCWeb,  consistency and clarity should be ensured
>>>between the IPR grant associated with the IETF draft, the IPR grants
>>>within the IETF draft document itself, the IPR grant given for MPEG,
>>>and any IPR grant given in connection with the WEBM project for this
>>>same work.  Otherwise, the IPR status of the work that is undertaken is
>>>indeterminate, and likely will not produce a result that will be
>>>useful.  
>>> 
>> 
>> Speaking with my Google hat on:
>> 
>> We will of course seek maximum clarity of the statements we make.
>>Unfortunately, different organizations have different traditions on
>>how these things should be worded, and we cannot guarantee that there
>>can't be differences in interpretation.
>> 
>> However, I (speaking with my personal hat on) think the current
>>statements on the WEBM website are pretty clear. I have yet to see a
>>concrete scenario where there would be any reasonable doubt about
>>whether usage of VP8 is permitted by Google or not - and in all
>>cases except for those that fall within the defensive suspension
>>exceptions, it is permitted.
>> 
>> Hope that helps!
>> 
>>            Harald
>> 
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb
>