Subject: [rtcweb] Input to Video Codec Selection

From: Magnus Westerlund <[email-masked]>
Date: Fri, 1 Mar 2013 15:22:59 +0100

WG,

I hope everyone, especially Google, now have provided whatever input
they have into the Video Codec discussion and selection. It is important
that everyone has the possibility to evaluate the input in good time
prior to the meeting. It is especially important if one might require
legal or other support when evaluating the proposals or additional
information, which might apply for IPR, as an example.

To be extremely blunt, we don't want anyone revealing new input material
during the presentations in Orlando. These presentations is only
intended to provide a summary of the most important aspects from the
proponents side.

The RTCWEB WG chairs

Magnus Westerlund
Ted Hardie
Cullen Jennings

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Fri, 1 Mar 2013 22:21:42 +0000

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.
Q1: Is there an intent to move that RFC to the standard track at a point in time?
Q2: Would that change the rule of "who" is obliged to make an IPR declaration?

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? 

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?

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?

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?

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.  

Thank you!

Sincerely,
Gaëlle 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Friday, March 01, 2013 9:23 AM
Cc: [email-masked]
Subject: [rtcweb] Input to Video Codec Selection

WG,

I hope everyone, especially Google, now have provided whatever input they have into the Video Codec discussion and selection. It is important that everyone has the possibility to evaluate the input in good time prior to the meeting. It is especially important if one might require legal or other support when evaluating the proposals or additional information, which might apply for IPR, as an example.

To be extremely blunt, we don't want anyone revealing new input material during the presentations in Orlando. These presentations is only intended to provide a summary of the most important aspects from the proponents side.

The RTCWEB WG chairs

Magnus Westerlund
Ted Hardie
Cullen Jennings

_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

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

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 02 Mar 2013 10:57:52 +0100

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

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

> 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.
> 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 gra…

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

---

From: Stefan Håkansson LK <[email-masked]>
Date: Sun, 3 Mar 2013 08:44:48 +0000

I can understand the logic behind not wanting any new input before the meeting, but at the same time we did postpone this discussion one meeting cycle on request by Serge [1]. In his request Serge stated that "Google understands that concerns have been raised within the IETF RTCWEB WG in regards to VP8 IPR." and "We hereby commit to addressing this by the next IETF meeting in Orlando. Our  proposal will address prevalent IPR issues."

I have seen no such input yet, and if no new input is allowed, it seems like we will have the same discussion we postponed last time (all inputs look more or less unchanged to me). Is this the plan? Have the chairs reached out to Google to check the status (perhaps the IPR related things did encounter some delay, but will be ready shortly after the meeting)?

Stefan

[1] http://www.ietf.org/mail-archive/web/rtcweb/current/msg05698.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: den 1 mars 2013 15:23
Cc: [email-masked]
Subject: [rtcweb] Input to Video Codec Selection

WG,

The RTCWEB WG chairs

Magnus Westerlund
Ted Hardie
Cullen Jennings

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 3 Mar 2013 09:38:25 -0600

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.

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.

Cullen 

On Mar 2, 2013, at 3:57 AM, Harald Alvestrand <[email-masked]> wrote:

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

---

From: Stephan Wenger <[email-masked]>
Date: Sun, 3 Mar 2013 16:38:58 +0000

Hi all,

On 3.3.2013 07:38 , "Cullen Jennings" <[email-masked]> wrote:

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

>>> 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:
>>> 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?
>>> 
>> Patent license 1: http://www.webmproject.org/license/bitstream/ -
>>covers any implementation that produces or consumes VP8 bitstreams.
>>> The additional IP grant is applied to a particular implementation
>>>(namely the WebM VP8 code) without modifications.
>>> 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.
>> - 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)
>>sell, import, transfer, and otherwise run, modify and       propagate
>>the contents of this implementation"
>> 
>>> 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?
>>> 
>>clarification of what was granted when discussing with     people used
>>to the MPEG language tradition.
>> 
>>> 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.  
>>> 
>> 
>>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.
>> 
>>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
>>

---

From: Stephan Wenger <[email-masked]>
Date: Sun, 3 Mar 2013 16:52:20 +0000

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

From: Harald Alvestrand <[email-masked]<mailto:[email-masked]>>
Date: Saturday, 2 March, 2013 01:57
To: Gaelle Martin-Cocher <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] Input to Video Codec Selection

Dear All,

Questions 1 & 2:

Yes, that is the intent.

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:

Question 4:

Question 5:

Question 6:

Hope that helps!

           Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 03 Mar 2013 18:20:05 +0100

> 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…

Cullen, in what way is the WEBM page grant not an RF grant (or more 
precisely: "under a royalty-free and otherwise reasonable and 
non-discriminatory license", which is the precise language used in RFC 
3979 section 6.5)?
I can't remember the last time I saw a royalty-free license commitment 
without a defensive suspension clause.

Re patent numbers:

I've heard Scott Bradner claim that a defensive-suspension filing is not 
covered by the "blanket license" rule in section 6.4.3 of RFC 3979, but 
the first time I heard that was at the RTCWEB meeting, and I objected to 
the claim - I was listening most carefully when we wrote RFC 3979 in the 
IPR working group; my belief at the time we filed this statement was 
that since it's a blanket RF license, it did not require listing 
specific patent numbers. (As you know, listing specific patent numbers 
can be a chore requiring a fair amount of human judgment = lawyer and 
engineer time.

I believe the IETF IPR rules were intended to be biased towards making 
life easy for people willing to do RF licenses; I'd certainly not want 
to make life for those people harder.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 04 Mar 2013 11:43:46 +0100

On 03/03/2013 05:52 PM, Stephan Wenger wrote:
> 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".
>
---- below here is StW ---
>
> 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
>

I don't know how much the blue survives, email formatting is still 
hit-and-miss, but I hope this makes sense still.... this is still from 
my IETF amateur lawyer perspective, and shouldn't be taken as a Google 
position in any way.

I've always worked on the assumption that the RFC 3979 disclosure rules 
applied only when I was part of the discussion - but that it applied to 
anything brought into the discussion, including RFCs that I had not 
heard about before.

Thus, I don't believe the submission, editing and publication of RFC 
6386 triggered a disclosure obligation on anyone except those involved 
in the submission and editing process - but I believe that the moment a 
submission was made to the RTCWEB working group saying "VP8 should be a 
mandatory to implement codec for RTCWEB", participants who "reasonably 
and personally" knew of "IPR that is owned directly or indirectly, by 
the individual or his/her employer or sponsor (if any) or that such 
persons otherwise have the right to license or assert" (3979 section 
6.6) were placed under the obligation of RFC 3979 section 6.1.2 (IPR in 
the contributions of others).

(In the same way, I believe the submission saying "H.264 should be a 
mandatory to implement codec for RTCWEB", detailed in 
draft-marjou-rtcweb-video-codec among others, triggered a requirement 
for similar disclosure of IPR in H.264 technology. I believe the chairs 
earlier stated which draft such IPR claims should be filed against, but 
I don't have that message in front of me at the moment.)

---

From: Gaelle Martin-Cocher <[email-masked]>
Date: Mon, 4 Mar 2013 18:01:41 +0000

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:[email-masked]]
Sent: Sunday, March 03, 2013 11:52 AM
To: Harald Alvestrand; Gaelle Martin-Cocher
Cc: [email-masked]
Subject: Re: [rtcweb] Input to Video Codec Selection

Hi Harald,

Dear All,

Questions 1 & 2:

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.

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:

Question 4:

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:

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:

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.

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

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 4 Mar 2013 20:34:57 +0000

Hi Harald,

First, let me remark that I believe you are avoiding a reply to my original comment, and instead open a somewhat new discussion.  My original comment was that asserting that there is no change in the disclosure situation between leaving VP8 as RFC 6386 "as is" versus discussion of VP8 in a WG does not change the obligations by policy.  I concurred, but stated that it will, in practice, swipe in additional contributors that have an obligation by policy to disclose.  I continue to believe that this is true, and have not seen any assertion to the contrary.

With respect to the new topic, disclosure obligation in the rtcweb WG--which merely discusses referencing the VP8 spec, rather than developing it or tinkering with it technically--please see inline.  I hope that my markings are acceptable.

Stephan

From: Harald Alvestrand <[email-masked]<mailto:[email-masked]>>
Date: Monday, 4 March, 2013 02:43
To: Stephan Wenger <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] Input to Video Codec Selection

---- below here is StW ---

I don't know how much the blue survives, email formatting is still hit-and-miss, but I hope this makes sense still.... this is still from my IETF amateur lawyer perspective, and shouldn't be taken as a Google position in any way.

I've always worked on the assumption that the RFC 3979 disclosure rules applied only when I was part of the discussion - but that it applied to anything brought into the discussion, including RFCs that I had not heard about before.

Up until here, I'm mostly with you.  I'm not sure I would need to disclose just because, during the discussion of draft "foo", someone brought in the idea that RFC "bar" has some relationship with the subject matter discussed.  I would probably see to what extent I need to comment on the *technical* features of "bar" before making a decision.  If I were not to comment on those technical features, I would not disclose; otherwise, I would.

Thus, I don't believe the submission, editing and publication of RFC 6386 triggered a disclosure obligation on anyone except those involved in the submission and editing process

Agreed.

- but I believe that the moment a submission was made to the RTCWEB working group saying "VP8 should be a mandatory to implement codec for RTCWEB", participants who "reasonably and personally" knew of "IPR that is owned directly or indirectly, by the individual or his/her employer or sponsor (if any) or that such persons otherwise have the right to license or assert" (3979 section 6.6) were placed under the obligation of RFC 3979 section 6.1.2 (IPR in the contributions of others).

Perhaps.
Just assuming that your interpretation would hold water in a court, I'm not sure that there would be that much practical difference in terms of numbers of patents that would be held unenforcible due to policy violations through non-disclosure.  The group of people who can competently discuss things like data channel setup or trickle ICE in context of O/A, and the group of people who not only read the VP8 spec (which, I understand, is no-go-territory for quite a few individuals) but also have an understanding of video coding and a fair knowledge of their employer's video coding related patent portfolio, is rather limited.  That is probably why we have not seen all that many IPR disclosures against RFC6386.  Not any perceived or real policy violations.

But also: Perhaps not.
The Contributions folks make in the context of the rtcweb codec selection discussion is targeted towards the rtcweb I-Ds.  There is no IETF precedence that I'm aware of where a disclosure has been made against a spec that merely references an encumbered technology specified in an RFC, like VP8.  To the contrary, AFAIK, WGs like RMT or FECFRAME have been careful to distinguish the encumbered redundancy coding schemes from the non-encubered base spec.  (And these are IETF technologies, not just ISE RFCs—something that ought to be closer to the typical IETF participant's heart than such ISE RFCSs—though I already agreed with you that from a policy viewpoint, RFC is RFC, no matter the stream). The same ought to apply here.  Insofar, a disclosure obligation would be triggered only against the VP8 spec itself.

With respect to that, I don't believe that mere mentioning of essentially political arguments (like performance, commercial environment considerations etc.) in conjunction with a spec triggers a disclosure obligation.  Again, I think I can support this with the common practice in WGs commonly dealing with encumbered technologies, like (previously) AVT (and now) PAYLOAD.  For example, I contributed to the development of the I-D for the VP8 payload spec, knowing that I incur a disclosure obligation against this spec, and honoring that obligation by arranging a disclosure.  I was never asked, nor did I ever have a sense in the room of an expectation, that I would need to disclose what I may know of the VP8 spec itself and/or the relationship of our patent portfolio to it.  Nor did that ever happen in the discussion of other payload specs; see also below.   And that despite of the fact that AVT and PAYLOAD, in the context of discussing the finer features of media codecs, necessarily have to dig deep into some technical features of these codecs, leading to quite technical discussions well beyond those IMO political noise and meta arguments that are visible in rtcweb with respect to codec selection.

(In the same way, I believe the submission saying "H.264 should be a mandatory to implement codec for RTCWEB", detailed in draft-marjou-rtcweb-video-codec among others, triggered a requirement for similar disclosure of IPR in H.264 technology. I believe the chairs earlier stated which draft such IPR claims should be filed against, but I don't have that message in front of me at the moment.)

Here I absolutely disagree.  It would be against the tradition of the IETF to comment about IPR included in specs of other organizations.  I have not seen a single IPR disclosure pertaining to a media codec in the IETF IPR database, although there are tons of references to known-as-encumbered media coding specs in, for example, RTP payload formats; and those specs extensively comment on the technical features of these non-IETF media codec specs.. This is a discussion that, in other fori, is known as the "normative reference discussion": is there a need for a disclosure of rights pertaining to subject matter against a referencing spec that includes the subject matter by reference only.  Very few, if any, SDOs require such disclosures, mostly for practical reasons.  The same reasons seem to apply here as well.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 5 Mar 2013 14:12:02 +0100

Stefan and WG,

We WG chairs can't forbid people to state new things. However, our
message was a public prodding of everyone, including Google, that please
ensure that you have provided material prior to the discussion. We think
that in the interest of fairness and openness that any significant
contribution should be made before the actual discussion in the WG.

I think the below is a vary valid observation and I hope someone from
Google, like Serge can comment if any additional material will be
forthcoming. And if it will, then I request that it is provided ASAP so
that people can analyze any such information.

Cheers

Magnus Westerlund
(As WG chair)

On 2013-03-03 09:44, Stefan Håkansson LK wrote:
> I can understand the logic behind not wanting any new input before
> the meeting, but at the same time we did postpone this discussion one
> meeting cycle on request by Serge [1]. In his request Serge stated
> that "Google understands that concerns have been raised within the
> IETF RTCWEB WG in regards to VP8 IPR." and "We hereby commit to
> addressing this by the next IETF meeting in Orlando. Our  proposal
> will address prevalent IPR issues."
> 
> I have seen no such input yet, and if no new input is allowed, it
> seems like we will have the same discussion we postponed last time
> (all inputs look more or less unchanged to me). Is this the plan?
> Have the chairs reached out to Google to check the status (perhaps
> the IPR related things did encounter some delay, but will be ready
> shortly after the meeting)?
> 
> Stefan
> 
> [1]
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg05698.html
> 
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Magnus Westerlund Sent:
> den 1 mars 2013 15:23 Cc: [email-masked] Subject: [rtcweb] Input to
> Video Codec Selection
> 
> WG,
> 
> they have into the Video Codec discussion and selection. It is
> important that everyone has the possibility to evaluate the input in
> good time prior to the meeting. It is especially important if one
> might require legal or other support when evaluating the proposals or
> additional information, which might apply for IPR, as an example.
> 
> To be extremely blunt, we don't want anyone revealing new input
> material during the presentations in Orlando. These presentations is
> only intended to provide a summary of the most important aspects from
> the proponents side.
> 
> 
> The RTCWEB WG chairs
> 
> Magnus Westerlund Ted Hardie Cullen Jennings
> 
> _______________________________________________ rtcweb mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Rob Glidden <[email-masked]>
Date: Tue, 05 Mar 2013 13:46:51 -0800

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

I agree this is the gist of the MPEG resolutions 14.1.1 to 14.1.5 on the 
VP8 proposal (M28182) sent to this list.

ISO procedures (section 2.14 etc.) document well the next steps that 
would be required and expected:

- providing required ISO/ITU/IEC IPR form,
- disclosure obligations,
- call for patents,
- etc.

I for one doubt the advisability of dropping the existing, vetted IVC 
test model as a condition for taking these steps as recommended in 
M28182. That wasn't done or even requested in the similar-yet-different 
case of WebVC (the ultimately stalled h.264 profile proposal to IVC).  
There are obviously better, and better sequenced, ways to proceed.

Rob

On 3/4/2013 10:01 AM, Gaelle Martin-Cocher wrote:
> *From:*Stephan Wenger [mailto:[email-masked]]
> *Sent:* Sunday, March 03, 2013 11:52 AM
> *To:* Harald Alvestrand; Gaelle Martin-Cocher
> *Cc:* [email-masked]
> *Subject:* Re: [rtcweb] Input to Video Codec Selection
>
> Hi Harald,
>
> *From: *Harald Alvestrand <[email-masked] 
> <mailto:[email-masked]>>
> *Date: *Saturday, 2 March, 2013 01:57
> *To: *Gaelle Martin-Cocher <[email-masked] 
> <mailto:[email-masked]>>
> *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> *Subject: *Re: [rtcweb] Input to Video Codec Selection
>
>
> [GMC] I see manyvalid 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 technicalviewpoint, 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 legalentities 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.
>
> 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.
>
> only the authors (and perhaps the IESG members---I'm not clear on this 
> The IPR disclosure was made on the draft 2 of draft-bankoski-vp8-bitstream-02" as perhttps://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=6386
> [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).
>
> 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).
>
> [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:
> [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.
>
>
> 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.
>
>   
>   
> 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.
> [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.
>
>