Re: [codec] Skype IPR disclosure

Rob Glidden <> Mon, 29 March 2010 17:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DD6D3A6B0A for <>; Mon, 29 Mar 2010 10:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.067
X-Spam-Level: **
X-Spam-Status: No, score=2.067 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_HTML_ONLY=1.457, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AKnA4EAZD0qr for <>; Mon, 29 Mar 2010 10:14:29 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 35D7D3A6A67 for <>; Mon, 29 Mar 2010 10:14:05 -0700 (PDT)
Received: (qmail 37352 invoked from network); 29 Mar 2010 17:14:31 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ZGFP8474jni29xgcj67QxnsYDyytwrh7KYkuhz62xD2DnulORYxHhX6TsDZV4VKqgOK8OoiIx4kXhRbZNKescw5mkdcyONZTu6/bpNtiu0cia01IJeJRP//8pMIWIzGCf5P7K2GuN+BJ1GCrYQN+dZBbD07L2+8vXVzl1RqE5QE= ;
Received: from (rob.glidden@ with plain) by with SMTP; 29 Mar 2010 10:14:30 -0700 PDT
X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I-
X-YMail-OSG: KdhnXYAVM1mjqWvpoao.GSPAuy227MoDgP0PY
X-Yahoo-Newman-Property: ymail-3
Message-ID: <>
Date: Mon, 29 Mar 2010 10:14:29 -0700
From: Rob Glidden <>
User-Agent: Thunderbird (Windows/20100228)
MIME-Version: 1.0
To: Stephan Wenger <>
References: <>
In-Reply-To: <>
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Codec WG <>
Subject: Re: [codec] Skype IPR disclosure
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Mar 2010 17:14:30 -0000

IPR disclosed in this forum as reading on the spec that is being charged for elsewhere is exactly the IPR to be disclosed, discussed and potentially removed under this working group charter.

BCP 79 rightly doesn't impose obligations on participants to deduce and operate under other partipants' presumed stay-dumb clauses (i.e. give people a chance stay ignorant), rather the opposite.


Stephan Wenger wrote:
Hi Marc, all,

The article you linked is IMO a useful thing to read for those who do not
know how to study patents.  But, please understand, it is really 101 level.
There are many, many subtleties when interpreting claim language, and this
is an ever-evolving field, just as technical codec design is,

The article is written from an US law perspective, but that's IMHO alright,
considering where the majority of the patent litigation is ongoing today.
The business situation addressed is clearly that of an open source
developer, not that of a multi-national corporation, but you indicated that
in your posting already.

Commenting on your own post, there are two key problems in your logic about
the non-issue of willful infringement (which many people inadequately
circumscribe as "triple damages"--triple damages are a consequence of
willful infringement, but not the root cause.)

The first flaw, as I perceive it, is that your (and your employer's)
exposure to the patent is not restricted to your work in this working group.
It may come haunt you on past and future projects, and on anything you are
doing in parallel with the work here, as well.  That may be a non-issue if
the work in the codec WG is a hobby of yours, but if you are a codec
professional, it is something to consider.

Second, there is also the issue of statuary rights under patent law.
Especially in the open source community, but also in other standardization
and implementation circles, individuals tend to worry mostly about patent
rights being violated by "implementing".  This corresponds to the "make"
category in patent law.  However, the (US-) patent law also allows to
exclude others from the "use" and "sell" of a patented invention (the
formulation in other jurisdictions vary, but are generally similarly wide as
in the US).  Arguably, if your employer (through your participation here)
learns of a patent today, and your employer is currently selling products
containing another codec that is encumbered by the patent right, and a bunch
of other conditions are met, then willful infringement may trigger.

The business decision to study patents is, of course, up to you (and
possibly to your employer).  If your goal is the design of a freely
practicable codec, it could be helpful to do so.  My guess is, though, that
the risk/benefit equation is very different between different employers,
even if they are of similar size.  That's why I'm arguing so strongly to
give people a chance stay ignorant and out of patent discussions.


On 3.28.2010 08:22 , "Marc Petit-Huguenin" <> wrote:

On 03/24/2010 06:58 PM, Stephan Wenger wrote:
 Hi Rob,

Wearing my ³technical advisor to the IESG on IPR matters² hat:

I¹m commenting in this email only on the ³third party disclosure²
subject.  I may comment on the other subject later, as, admittedly, they
are more murky.  Phrasing a reply certainly requires more undistracted
time than I have now (sitting in the IETF77 plenary).

I note that you have provided information of two patent applications
that have not been recited in Skype¹s declaration.  Specifically,
neither the GB application, nor the PCT application, have been disclosed
by Skype.  Nowhere in BCP 79 or in the IETF¹s current practice I find
language or common conduct indicating that, by disclosing one or more
patent family members, one has to infer that all patent family members
are disclosed.  If you are aware of such language, I would appreciate a

In this light, I continue to believe that you were not within the
language, nor the spirit, of BCP 79 when you cited these patent numbers.

Advisor hat off, private statement:

Rob, you are a lawyer, and are listed in the IP law section of the CA
bar association.  You are a professional in this field.  Most of the
subscribers of this *technical* working group list are not.  They may
not know what harm could befall them, and their employers, if they start
reading someone else¹s patents, and perhaps start commenting in public
on it." rel="nofollow">

The arguments presented were for FOSS, but I am thinking that one argument in
this presentation may apply to the CODEC work.

My thinking is this:  The goal of this WG, as described in the charter is to
produce a RF codec.  Producing a royalty-free codec means that each time a
technique is used in the codec, it should be either covered by an expired
patent; or have plenty of prior art anterior by at least one year to the
valid patent; or been so new that there is no patent; or been covered by a
patent with a royalte-free license that apply to this work.  If a non-expired
patent without an RF license is found for the technique, then there is only
way to fix this: remove the technique from the codec and find another way.  If
the goal of this WG is really to produce a RF codec, then it does not matter
we discuss patent and prior art and so on in this mailing-list, because
single or triple damages can apply, as any technique that could trigger either
of them will be removed.

Now finding a workaround for a technique that we cannot use is impossible
without discussing it.  If we want our best minds trying to find how to not
employ a specific technique, then we have to explain why this specific
cannot be used, and I do not see how to do this without discussing the patent
this mailing-list.  In fact I think that each single line of the codec
description should be annotated in some way with all the prior art, expired
patent and so on all the way to the Sumerians to prove to everybody that there
is no issue.  (I suspect that the triple damage thing is used to frighten the
very people that could really do harm a patent by finding a way to ignore it).

The only possible collateral damage would be if a developer is reading this
mailing-list and discover that a technique applies to its own code and thus
be eventually open to triple damages on its own code.  I think that somebody
like this should not be in this mailing-list in the first place.