Return-Path: <stephen.botzko@gmail.com>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
 with ESMTP id 7D3133A6B44 for <codec@core3.amsl.com>;
 Wed, 24 Mar 2010 18:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.132
X-Spam-Level: 
X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[AWL=1.000,
 BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, GB_I_LETTER=-2, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6VtEobdV8J7 for
 <codec@core3.amsl.com>; Wed, 24 Mar 2010 18:02:10 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com
 [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 642A73A67D4 for
 <codec@ietf.org>; Wed, 24 Mar 2010 18:02:10 -0700 (PDT)
Received: by gwj23 with SMTP id 23so1420338gwj.31 for <codec@ietf.org>;
 Wed, 24 Mar 2010 18:02:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
 h=domainkey-signature:mime-version:received:in-reply-to:references
 :date:message-id:subject:from:to:cc:content-type;
 bh=7sgKTaN4C7hyPZdqFfhlLyoyAWugo5pTckk6EbS5LPE=;
 b=qzCGYMsTZGijX/2g6PkQWiDFFIXfBEhUM7U+UkQWxMA2tLMCC1DRgFRn39uMSKu5rg
 ARURFFs76mSkvi6/AMJgOJGPSVnstXBjfkTNJ88clUfboVy9+guA+2KDZSmUpnAfzA4L
 FGUC5fTyugvPfFo54hvqMg2T7mOVU5BN6kWqs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 b=mgtOEypxYz7+a4+6NIihlHxpAqREVAJy1N8s8Vz2Z9mvCG8ytNNGFXjlBzj66BFc7u
 /4eA9TLnGSfoTlZSj6ULOJmhQcTdmz+LX/aKrPJuylE9nGLC2KH51vjgwlhMH7nZ5noO
 X5mVun0uHuI3ZRys36l0BeNxxRx+1NYNobCZc=
MIME-Version: 1.0
Received: by 10.101.154.5 with SMTP id g5mr9514923ano.224.1269478945956;
 Wed,  24 Mar 2010 18:02:25 -0700 (PDT)
In-Reply-To: <4BAAB345.2070601@sbcglobal.net>
References: <C7CFE81B.206DE%stewe@stewe.org> <4BAAB345.2070601@sbcglobal.net>
Date: Wed, 24 Mar 2010 18:02:25 -0700
Message-ID: <6e9223711003241802m79b92cc2q37b13594fffd62e4@mail.gmail.com>
From: stephen botzko <stephen.botzko@gmail.com>
To: Rob Glidden <rob.glidden@sbcglobal.net>
Content-Type: multipart/alternative; boundary=0016e6d27d449fa29a048295991f
Cc: Codec WG <codec@ietf.org>
Subject: Re: [codec] Skype IPR disclosure
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codec>,
 <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>,
 <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Mar 2010 01:02:12 -0000

--0016e6d27d449fa29a048295991f
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I much prefer the tracker alone.  Individuals in the working group then can
review the patents as they wish, and come to their own conclusions.

Stephen Botzko

On Wed, Mar 24, 2010 at 5:50 PM, Rob Glidden <rob.glidden@sbcglobal.net>wro=
te:

>  Stephan:
>
> (apologies for long email)
>
> Thanks for the reminder.  I've re-read 3979 and 4879 (on third party
> disclosures), and you are wise to encourage care.
>
> However, in this case the IPR has already been responsibly disclosed by t=
he
> owner.  So this thread is not disclosing any IPR of a third party, for wh=
ich
> as you indicate sections 6.1.2 and 3 (on IPR of others) would be appropri=
ate
> -- by form or email.
>
> Rather, 3979 clearly expects working groups to use the disclosures, once
> made, in their evaluations and deliberations.
>
>    6.5 Since IPR disclosures will be used by IETF working groups during
>    their evaluation of alternative technical solutions, it is helpful if
>    an IPR disclosure includes information about licensing of the IPR in
>    case Implementing Technologies require a license.
>
> This includes the licensing information in the disclosures:
>
>    The inclusion of licensing information in IPR disclosures is not
>    mandatory but it is encouraged so that the working groups will have
>    as much information as they can during their deliberations.
>
> And in weighing alternatives:
>
> 8. IETF working groups have the discretion
>    to adopt technology with a commitment of fair and non-discriminatory
>    terms, or even with no licensing commitment, if they feel that this
>    technology is superior enough to alternatives with fewer IPR claims
>    or free licensing to outweigh the potential cost of the licenses.
>
> and even in developing broader IETF consensus:
>
> An IETF consensus
>    has developed that no mandatory-to-implement security technology can
>    be specified in an IETF specification unless it has no known IPR
>    claims against it or a royalty-free license is available to
>    implementers of the specification unless there is a very good reason
>    to do so.
>
>
> And you are also wise in reminding that the IETF will not make
> determinations for many excellent reasons, but
>
> Although the IETF can
>    make no actual determination of validity, enforceability or
>    applicability of any particular IPR claim, it is reasonable that a
>    working group will take into account on their own opinions of the
>    validity, enforceability or applicability of Intellectual Property
>    Rights in their evaluation of alternative technologies.
>
> So I'd suggest this dialog is both in scope and constructive, fully in
> spirit and letter of BCP 79, seeking to clarify the nature of a licensing
> disclosure and the specific value of a particular technique of noise leve=
l
> estimation and application of opposite non-linear functions.
>
> Rob
>
>
> Stephan Wenger wrote:
>
> Hi Rob, all,
>
> Wearing my =93technical advisor on IPR matters hat=94:
>
> Please let me remind you that the IETF takes no position on scope and
> validity of patent claims.  I don=92t believe that the use of an IETF mai=
ling
> list to collaboratively create such a position=97even it it were not mark=
ed as
> an IETF position=97is appropriate.  Please refrain from using this list f=
or
> such discussions.
>
> Further, I=92m also not sure that everyone here=97even a majority=97appre=
ciates
> being advised of patents through means other than the IETF=92s IPR tracki=
ng
> system.  It is certainly against language and spirit of BCP 79.  If you w=
ant
> to advise people of third party IPR henceforth, please use the tracker.
>  Feel free to contact me in private it you need logistic help with that.
>
> Thanks,
> Stephan
>
>
>
> On 3.24.2010 15:13 , "Rob Glidden" <rob.glidden@sbcglobal.net> wrote:
>
>  I would agree that the wording seems to go beyond a narrow non-assert
> into business strategy, and this is furthered by potentially ambiguous
> phrasings such as "royalty free, reasonable and non discriminatory terms"=
.
> "RF" and "RAND" might overlap in some definitions, but they are not the
> same.
>
> Also I would note the two statements (1297 and 1164) appear to be (only?)=
 a
> single patent application for a method of estimating noise levels with 3
> independent claims.  As further progress is made, it might be helpful to
> understand scope and prior art, and relationship to an entire contributio=
n,
> and the specific quantified value of the novelty identified in the
> international search opinion of applying opposite non-linear functions.
>
> Though not reflected in the disclosure, the US application claims priorit=
y
> to a Great Britain Application No. 0703275.8, filed Feb. 20, 2007.
>
>
> http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=3DPTO2&Sect2=3DHITOFF&p=
=3D1&u=3D%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=3D1&f=3DG&l=3D50&co1=3DAND&=
d=3DPG01&s1=3D12%2F006057&OS=3D12/006057&RS=3D12/006057
>
> The PCT is at:
>
> http://www.wipo.int/pctdb/en/wo.jsp?WO=3D2008102207
>
> Perhaps someone familiar with this application would correct any
> mis-impressions above?
>
> Rob
>
>
> Benjamin M. Schwartz wrote:
>
>
> stephen botzko wrote:
>
>
>
>
> I think it is unreasonable to require IPR holders to unconditionally
> promise
> to not assert their patents under any and all circumstances.
>
>
>
>
>
> I am not asking for such an unconditional promise.  I am just noting some
> restrictions that seem especially onerous to me.
>
>
>
>
>
> In practice the first clause does not immunize Skype from lawsuits.  Many
> companies have similar "defensive suspension" clauses, and they still get
> sued fairly regularly.
>
>
>
>
>
> There are different kinds of defensive suspension.  For example, the W3C
> allows defensive suspension, but only for lawsuits on patent infringement=
:
> """
> a W3C Royalty-Free license ... may be suspended with respect to any
> licensee when licensor is sued by licensee for infringement of claims
> essential to implement any W3C Recommendation ... [but] may not impose an=
y
> further conditions or restrictions
> """
> (http://www.w3.org/Consortium/Patent-Policy-20030520#sec-Requirements)
>
> That seems like a reasonable case for defensive suspension.  Skype's
> wording, by contrast, is totally unreasonable, as it extends the defensiv=
e
> suspension to _all_ lawsuits, no matter their object.  I expect most
> companies to use the IWAC, and maybe even most humans eventually.  The
> retroactive revocation means that these people can be deterred from suing
> Skype/Ebay even after the patents have all expired.
>
> It's absurd, not to mention legally questionable.
>
>
>
>
>
> The second clause ensures that someone outside the IETF cannot take the
> Skype technology, improve it, and offer a competitive proprietrary codec
> that uses Skype IPR. If you modify the codec, you should be doing it in t=
he
> context of the IETF standard.
>
>
>
>
>
> And once the standard is made?  Skype could effectively block the IETF
> from creating an improved version of its own codec, or any optional
> extensions (they're not "necessary").  I don't think that's reasonable at
> all.
>
> --Ben
>
>
>
>
> ------------------------------
>
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec
>
>
>
>
> ------------------------------
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec
>
>
>
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec
>
>

--0016e6d27d449fa29a048295991f
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I much prefer the tracker alone.=A0 Individuals in the working group then c=
an review the patents as they wish, and come to their own conclusions.<br><=
br>Stephen Botzko<br><br><div class=3D"gmail_quote">On Wed, Mar 24, 2010 at=
 5:50 PM, Rob Glidden <span dir=3D"ltr">&lt;<a href=3D"mailto:rob.glidden@s=
bcglobal.net">rob.glidden@sbcglobal.net</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


 =20

<div bgcolor=3D"#ffffff" text=3D"#000000">
Stephan:<br>
<br>
(apologies for long email)<br>
<br>
Thanks for the reminder.=A0 I&#39;ve re-read 3979 and 4879 (on third party
disclosures), and you are wise to encourage care.<br>
<br>
However, in this case the IPR has already been responsibly disclosed by
the owner.=A0 So this thread is not disclosing any IPR of a third party,
for which as you indicate sections 6.1.2 and 3 (on IPR of others) would
be appropriate -- by form or email.<br>
<br>
Rather, 3979 clearly expects working groups to use the disclosures,
once made, in their evaluations and deliberations.<br>
<br>
<pre>   6.5 Since IPR disclosures will be used by IETF working groups durin=
g
   their evaluation of alternative technical solutions, it is helpful if
   an IPR disclosure includes information about licensing of the IPR in
   case Implementing Technologies require a license.</pre>
This includes the licensing information in the disclosures:<br>
<br>
<pre>   The inclusion of licensing information in IPR disclosures is not
   mandatory but it is encouraged so that the working groups will have
   as much information as they can during their deliberations.</pre>
And in weighing alternatives:<br>
<br>
<pre>8. IETF working groups have the discretion
   to adopt technology with a commitment of fair and non-discriminatory
   terms, or even with no licensing commitment, if they feel that this
   technology is superior enough to alternatives with fewer IPR claims
   or free licensing to outweigh the potential cost of the licenses.
</pre>
and even in developing broader IETF consensus:<br>
<br>
<pre>An IETF consensus
   has developed that no mandatory-to-implement security technology can
   be specified in an IETF specification unless it has no known IPR
   claims against it or a royalty-free license is available to
   implementers of the specification unless there is a very good reason
   to do so.</pre>
<br>
And you are also wise in reminding that the IETF will not make
determinations for many excellent reasons, but<br>
<pre>Although the IETF can
   make no actual determination of validity, enforceability or
   applicability of any particular IPR claim, it is reasonable that a
   working group will take into account on their own opinions of the
   validity, enforceability or applicability of Intellectual Property
   Rights in their evaluation of alternative technologies.
</pre>
So I&#39;d suggest this dialog is both in scope and constructive, fully in
spirit and letter of BCP 79, seeking to clarify the nature of a
licensing disclosure and the specific value of a particular technique
of noise level estimation and application of opposite non-linear
functions.<br><font color=3D"#888888">
<br>
Rob</font><div><div></div><div class=3D"h5"><br>
<br>
Stephan Wenger wrote:
<blockquote type=3D"cite">
 =20
  <font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-siz=
e: 11pt;">Hi Rob, all,<br>
  <br>
Wearing my =93technical advisor on IPR matters hat=94:<br>
  <br>
Please let me remind you that the IETF takes no position on scope and
validity of patent claims. =A0I don=92t believe that the use of an IETF
mailing list to collaboratively create such a position=97even it it were
not marked as an IETF position=97is appropriate. =A0Please refrain from
using this list for such discussions. =A0=A0<br>
  <br>
Further, I=92m also not sure that everyone here=97even a
majority=97appreciates being advised of patents through means other than
the IETF=92s IPR tracking system. =A0It is certainly against language and
spirit of BCP 79. =A0If you want to advise people of third party IPR
henceforth, please use the tracker. =A0Feel free to contact me in private
it you need logistic help with that.<br>
  <br>
Thanks,<br>
Stephan<br>
  <br>
  <br>
  <br>
On 3.24.2010 15:13 , &quot;Rob Glidden&quot; &lt;<a href=3D"http://rob.glid=
den@sbcglobal.net" target=3D"_blank">rob.glidden@sbcglobal.net</a>&gt;
wrote:<br>
  <br>
  </span></font>
  <blockquote><font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=
=3D"font-size: 11pt;">I would agree that the wording seems to go
beyond a narrow non-assert into business strategy, and this is
furthered by potentially ambiguous phrasings such as &quot;royalty free,
reasonable and non discriminatory terms&quot;.=A0 &quot;RF&quot; and &quot;=
RAND&quot; might
overlap in some definitions, but they are not the same.<br>
    <br>
Also I would note the two statements (1297 and 1164) appear to be
(only?) a single patent application for a method of estimating noise
levels with 3 independent claims.=A0 As further progress is made, it
might be helpful to understand scope and prior art, and relationship to
an entire contribution, and the specific quantified value of the
novelty identified in the international search opinion of applying
opposite non-linear functions.<br>
    <br>
Though not reflected in the disclosure, the US application claims
priority to a Great Britain Application No. 0703275.8, filed Feb. 20,
2007.<br>
    <br>
    <a href=3D"http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=3DPTO2&amp;=
Sect2=3DHITOFF&amp;p=3D1&amp;u=3D%2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=
=3D1&amp;f=3DG&amp;l=3D50&amp;co1=3DAND&amp;d=3DPG01&amp;s1=3D12%2F006057&a=
mp;OS=3D12/006057&amp;RS=3D12/006057" target=3D"_blank">http://appft1.uspto=
.gov/netacgi/nph-Parser?Sect1=3DPTO2&amp;Sect2=3DHITOFF&amp;p=3D1&amp;u=3D%=
2Fnetahtml%2FPTO%2Fsearch-bool.html&amp;r=3D1&amp;f=3DG&amp;l=3D50&amp;co1=
=3DAND&amp;d=3DPG01&amp;s1=3D12%2F006057&amp;OS=3D12/006057&amp;RS=3D12/006=
057</a>
    <br>
    <br>
The PCT is at:<br>
    <br>
    <a href=3D"http://www.wipo.int/pctdb/en/wo.jsp?WO=3D2008102207" target=
=3D"_blank">http://www.wipo.int/pctdb/en/wo.jsp?WO=3D2008102207</a><br>
    <br>
Perhaps someone familiar with this application would correct any
mis-impressions above?<br>
    <br>
Rob<br>
    <br>
    <br>
Benjamin M. Schwartz wrote: <br>
    </span></font>
    <blockquote><font face=3D"Calibri, Verdana, Helvetica, Arial"><span sty=
le=3D"font-size: 11pt;"> <br>
stephen botzko wrote:<br>
=A0=A0<br>
=A0<br>
      </span></font>
      <blockquote><font face=3D"Calibri, Verdana, Helvetica, Arial"><span s=
tyle=3D"font-size: 11pt;"> <br>
I think it is unreasonable to require IPR holders to unconditionally
promise<br>
to not assert their patents under any and all circumstances. <br>
=A0=A0=A0=A0<br>
=A0<br>
        </span></font></blockquote>
      <font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font=
-size: 11pt;"> <br>
      <br>
I am not asking for such an unconditional promise. =A0I am just noting
some<br>
restrictions that seem especially onerous to me.<br>
      <br>
=A0=A0<br>
=A0<br>
      </span></font>
      <blockquote><font face=3D"Calibri, Verdana, Helvetica, Arial"><span s=
tyle=3D"font-size: 11pt;"> <br>
In practice the first clause does not immunize Skype from lawsuits.
=A0Many<br>
companies have similar &quot;defensive suspension&quot; clauses, and they s=
till
get<br>
sued fairly regularly. =A0<br>
=A0=A0=A0=A0<br>
=A0<br>
        </span></font></blockquote>
      <font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font=
-size: 11pt;"> <br>
      <br>
There are different kinds of defensive suspension. =A0For example, the W3C<=
br>
allows defensive suspension, but only for lawsuits on patent
infringement:<br>
&quot;&quot;&quot;<br>
a W3C Royalty-Free license ... may be suspended with respect to any<br>
licensee when licensor is sued by licensee for infringement of claims<br>
essential to implement any W3C Recommendation ... [but] may not impose
any<br>
further conditions or restrictions<br>
&quot;&quot;&quot;<br>
(<a href=3D"http://www.w3.org/Consortium/Patent-Policy-20030520#sec-Require=
ments" target=3D"_blank">http://www.w3.org/Consortium/Patent-Policy-2003052=
0#sec-Requirements</a>)<br>
      <br>
That seems like a reasonable case for defensive suspension. =A0Skype&#39;s<=
br>
wording, by contrast, is totally unreasonable, as it extends the
defensive<br>
suspension to _all_ lawsuits, no matter their object. =A0I expect most<br>
companies to use the IWAC, and maybe even most humans eventually. =A0The<br=
>
retroactive revocation means that these people can be deterred from
suing<br>
Skype/Ebay even after the patents have all expired.<br>
      <br>
It&#39;s absurd, not to mention legally questionable.<br>
      <br>
=A0=A0<br>
=A0<br>
      </span></font>
      <blockquote><font face=3D"Calibri, Verdana, Helvetica, Arial"><span s=
tyle=3D"font-size: 11pt;"> <br>
The second clause ensures that someone outside the IETF cannot take the<br>
Skype technology, improve it, and offer a competitive proprietrary codec<br=
>
that uses Skype IPR. If you modify the codec, you should be doing it in
the<br>
context of the IETF standard.<br>
=A0=A0=A0=A0<br>
=A0<br>
        </span></font></blockquote>
      <font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font=
-size: 11pt;"> <br>
      <br>
And once the standard is made? =A0Skype could effectively block the IETF<br=
>
from creating an improved version of its own codec, or any optional<br>
extensions (they&#39;re not &quot;necessary&quot;). =A0I don&#39;t think th=
at&#39;s reasonable
at all.<br>
      <br>
--Ben<br>
      <br>
=A0=A0<br>
=A0<br>
      <br>
      <hr align=3D"center" size=3D"4" width=3D"90%"><br>
_______________________________________________<br>
codec mailing list<br>
      <a href=3D"http://codec@ietf.org" target=3D"_blank">codec@ietf.org</a=
><br>
      <a href=3D"https://www.ietf.org/mailman/listinfo/codec" target=3D"_bl=
ank">https://www.ietf.org/mailman/listinfo/codec</a><br>
=A0=A0<br>
      </span></font></blockquote>
    <font face=3D"Calibri, Verdana, Helvetica, Arial"><span style=3D"font-s=
ize: 11pt;"><br>
    <br>
    <hr align=3D"center" size=3D"3" width=3D"95%"></span></font><font size=
=3D"2"><font face=3D"Consolas, Courier New, Courier"><span style=3D"font-si=
ze: 10pt;">_______________________________________________<br>
codec mailing list<br>
    <a href=3D"http://codec@ietf.org" target=3D"_blank">codec@ietf.org</a><=
br>
    <a href=3D"https://www.ietf.org/mailman/listinfo/codec" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/codec</a><br>
    </span></font></font></blockquote>
</blockquote>
<br>
</div></div></div>

<br>_______________________________________________<br>
codec mailing list<br>
<a href=3D"mailto:codec@ietf.org">codec@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/codec" target=3D"_blank">h=
ttps://www.ietf.org/mailman/listinfo/codec</a><br>
<br></blockquote></div><br>

--0016e6d27d449fa29a048295991f--
