Dear Harald, Stephan, All.
Thank you for your answers.
I have further comments and request for clarifications marked in red with [gmc].

Sincerely,
Gaëlle

From: Stephan Wenger [mailto:stewe@stewe.org]
Sent: Sunday, March 03, 2013 11:52 AM
To: Harald Alvestrand; Gaelle Martin-Cocher
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Input to Video Codec Selection

Hi Harald,
Thanks for these candid answers.  I have a few comments, marked in blue and with StW:
Stephan

From: Harald Alvestrand <harald@alvestrand.no<mailto:harald@alvestrand.no>>
Date: Saturday, 2 March, 2013 01:57
To: Gaelle Martin-Cocher <gmartincocher@blackberry.com<mailto:gmartincocher@blackberry.com>>
Cc: "rtcweb@ietf.org<mailto:rtcweb@ietf.org>" <rtcweb@ietf.org<mailto:rtcweb@ietf.org>>
Subject: Re: [rtcweb] Input to Video Codec Selection


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.
[GMC] I see many valid reasons why one implementer would want to comply to a formal specification available in a standardization body where an IPR disclosure process takes place. That specification would have had the right level of scrutiny by a wide group of experts.
>From a technical viewpoint, I would want to develop an implementation from such a specification and I would want to test it against some conformance point/spec.
>From an IP side, it should be noted that for some legal entities it is certainly easier to declare IP against a "spec" than against a "code". Having "just" a code may have prevented some entities to make their declarations.

So it seems from your answer and from StW answer below that for RFC 6386:
"The Spec" is "the code".
There will not be in IETF a more formal spec. is that correct?
It will not move to the standard track hence not reach the level of scrutiny/consensus that everyone was asking for.
On the other hand in MPEG, we may/will (?) get a formal spec (that is, syntax, semantic, decoding process, conformance) and a more thorough scrutiny/review.


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".

StW; While this answer IMO correctly interprets the language of BCP79, you answer the question IMO to directly.  Therefore, the answer is somewhat misleading in it misses to mention an important point:

The main (sole?) purpose of an IETF WG is to facilitate consensus building, which necessarily involves more than one party, and those contributing to the discussions (belonging to more than one party) have a disclosure obligation.  To which extent there is real discussion and consensus building dependent from draft to draft and WG to WG, but there is at least some.

ISE submissions, like the draft that lead to RFC 6386, OTOH, are almost always NOT the result of a multiparty consensus building process.  Quite commonly, they involved only a small authors' group, often from the same company.  That's the case here.  No technical community input from IETF participants was received in an IETF context, no WG consensus was required, and the IESG "no conflict" statement is also no indication of IETF consensus.

Insofar, almost inevitably, the disclosure obligations for an ISE submission are different in practice.  In this case, it appears that only the authors (and perhaps the IESG members-I'm not clear on this point) had a disclosure obligation.  Which they fulfilled.
/StW


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=6386

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.
[gmc] I am afraid you are not answering Q4. Those are WebM licenses that don't apply to the RFC (more precisely to the RFC code).
You may be making the assumption that everyone will refer to and use the WebM code.
I am making the assumption that if the RFC is self-sufficient one would want to derive a VP8 compliant implementation from the RFC (either from section 1 to 19 or from section 20 to 20.24 or from both).
Hence what is the meaning of 20.26 and 20.27 in the RFC and how does that apply to the RFC itself?
This is still confusing.



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.
[gmc] the question is not "are modifications permitted" but which license apply to those modifications (again referring to the RFC code and not to WebM).
It seems that only the IETF declaration attached to the RFC apply to the RFC code. (though that would depend on answers to Q4)



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.
[gmc] I believe the statement in MPEG in MPEG is similar to other MPEG statement except for the "other reasonable conditions" that triggers significant confusion as they are undefined.

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
[gmc] again, one would want to use a standard specification not the WebM code to develop a conformant implementation and test it.





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.
[GMC] again that is not what matters.
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.
[gmc] the issue is not that Google would permit or not the usage of VP8. The issue is: will VP8 become a "standard" one way or another, and/or will it get the right level of scrutiny so that OTHER will/could declare their IP and thereby will finally get clarity on that aspect for implementers.
I think that this is/was the purpose of the exercise of bringing VP8 via an RFC or in MPEG. This exercise needs to be completed.
Sincerely,
Gaëlle

Hope that helps!

           Harald

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.