Subject: [rtcweb] Opus RF status, was: Re: Codec Draft

From: Monty Montgomery <[email-masked]>
Date: Mon, 7 Nov 2011 14:02:44 -0500

> I find it strange that we consider making an declared-as-royalty-bearing audio codec mandatory,

Stephan,

You've asserted that Opus is 'declared as royalty bearing' several
times now. This is outright false.

The only IPR filing that doesn't include explicit RF terms is
Qualcomm's filing[1] which lists six patents.  Our analysis
indicates these patents have no chance of covering Opus. It
further suggests that Qualcomm did little or no analysis on
these patents beyond an automated search.

Xiph has presented the above summary directly to Qualcomm.  Qualcomm
declined to alter or amend the language in their IPR filing, replying
that the disclosure standard is merely "IPR the Contributor or other
IETF participant believes Covers or may ultimately Cover the
technology under discussion."[2].  Qualcomm explicitly added that they
had no obligation to make a stronger statement.

Thus, Qualcomm themselves confirm that they have made no definitive
suggestion or statement that Qualcomm IPR covers Opus.

Qualcomm has filed nearly identical IPR claims in several IETF working
groups working under RF terms.  Are you suggesting that WebRTC must
avoid SIP[3] or drop SDP because of similar Qualcomm IPR filings[4] that
differ only in the patent numbers?

Opus is not 'declared as royalty bearing' nor are there credible
royalty-bearing patent claims or assertions against Opus.  Anyone who
would like to assert otherwise can do so trivially by posting their
claims charts.

Monty
Xiph.Org

[1] https://datatracker.ietf.org/ipr/1520/
[2] https://www.ietf.org/rfc/rfc3979.txt sec 6.1.2(c)
[3] OK, sure, there are other reasons to avoid SIP :-)
[4] https://datatracker.ietf.org/ipr/1389/
    https://datatracker.ietf.org/ipr/1390/

---

From: <[email-masked]>
Date: Mon, 7 Nov 2011 19:41:28 +0000

Hi,

Monty Montgomery wrote:

>
>Qualcomm has filed nearly identical IPR claims in several IETF working groups
>working under RF terms.  Are you suggesting that WebRTC must avoid SIP[3]
>or drop SDP because of similar Qualcomm IPR filings[4] that differ only in the
>patent numbers?
>

Hmm... It's indeed interesting why there is such a fuss about royalty free codecs, but not so much on the other parts of the WebRTC framework. At least codecs are easily changeable, unlike some of the other components. (Not that I have done any research on how many known patent claims there are against the other components.)

Markus

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 07 Nov 2011 12:43:52 -0700

Hi Monty,
We disagree (as usual on these matters).
Please see inline.
Stephan

On 11.7.2011 12:02 , "Monty Montgomery" <[email-masked]> wrote:

>> I find it strange that we consider making an
>>declared-as-royalty-bearing audio codec mandatory,
>
>Stephan,
>

I disagree.  Please note that I DID NOT write something like Opus is
royalty-bearing".  I only wrote "is declared as".  In support of this
statement, please see section VI of QC's declaration, which can be found
at https://datatracker.ietf.org/ipr/1520/ (or your reference [2]) and
reads "Reasonable and Non-Discriminatory License to All Implementers *with
Possible Royalty/Fee.*"  (Emphasis added.)

If you are referring to the fact that "with Possible Royalty/Fee" also
includes an option, at the right holders discretion, to also offer an RF
license... that's true.  However, that's equally true for stuff like
H.264.  You only need to convince all right holders to extent such  free
license.  Which, incidentally, has happened in the past for a certain use
of H.264 and for those right holders that are part of the MPEG-LA pool.

This is all I am referring to in the context of this thread.

>suggestion or statement that Qualcomm IPR covers Opus.

This is an interesting set of statements and interpretations, as well as
an interesting data point I was not aware of.  It doesn't change anything
related to my statement.  It merely provides insight into your risk
assessment, which obviously can be (and probably should be) different than
mine.

There are a number of good reasons why most (if not all) IPR declaration
documents, whether templates or free form, avoid committing language with
respect to (alleged) infringement of a patent by a standards
implementation.  The details of these reasons are IMO beyond the scope of
this mailing list, so I'm not posting them here.

>groups working under RF terms.

With the possible exception of some technical fields (not WGs) in the
security field (only mandatory cyphers come to my mind right now), I'm not
aware that IETF WGs can work under "RF terms".  I don't think such a modus
operandi is supported by the IETF's patent policy.  We are not OASIS or
W3C here...

>Are you suggesting that WebRTC must

Quite to the contrary.  I'm not overly worried about RAND IPR claims
(which exist also in other fields closer to WebRTC's core mission; see for
example Ericsson's recent declaration filings on stuff related to RTP
multiplexing; RAND terms).  I'm worried about unfair treatment of
established technologies and codecs (H.264 and some audio codecs) over
unestablished ones, just because the latter are believed (by some) to be
unencumbered by potentially royalty-bearing patent claims.  That's
particularly unfair if there is already evidence to the contrary.  Which,
unfortunately, is the case with opus.

>
>Opus is not 'declared as royalty bearing'

As I explained above, I believe this is an incorrect statement.

>nor are there credible
>royalty-bearing patent claims or assertions against Opus.

And this is a subjective viewpoint of one proponent organization.

>Anyone who

Perhaps they could.  Should they?  Would it be to their advantage?  As I
mentioned a number of times before, there are certain risks involved in
publishing documents suggesting a detailed study of someone else's patent.
 Certainly a claim chart would fall into a category of documents where the
risk is a bit higher than the broad statements generally made on this (and
other IETF-) mailing list(s).

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