Re: [codec] Skype IPR disclosure

Marc Petit-Huguenin <> Sun, 28 March 2010 18:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CA7963A68DF for <>; Sun, 28 Mar 2010 11:13:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -98.999
X-Spam-Status: No, score=-98.999 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gk3OKtqOID8c for <>; Sun, 28 Mar 2010 11:13:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6BC593A68D5 for <>; Sun, 28 Mar 2010 11:13:15 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 124676C984E8; Sun, 28 Mar 2010 18:13:42 +0000 (UTC)
Received: from [] ( []) by (Postfix) with ESMTPA id 0E9416C984E2; Sun, 28 Mar 2010 18:13:41 +0000 (UTC)
Message-ID: <>
Date: Sun, 28 Mar 2010 11:13:40 -0700
From: Marc Petit-Huguenin <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100307 Iceowl/1.0b1 Icedove/3.0.3
MIME-Version: 1.0
To: Stephan Wenger <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
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: Sun, 28 Mar 2010 18:13:17 -0000

On 03/28/2010 10:13 AM, 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.

Well, this is not new for professional developers.  E.g. as a former Java
Licensee, I cannot contribute to the Apache Harmony project.  C'est la vie.

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

I think that there is a problem here.  Let's say that the CODEC's codec
algorithm uses a specific technique, let's call it "T".  I then discover that T
is patented.  I can (and will) fill a third party IPR disclosure.  People in the
mailing-list will know about this but cannot discuss it, according to what you
are saying.  OK, then I propose a modification to the specification to replace T
by T'.  According to you I still cannot discuss why T' is better than T, because
it is not a technical argument.  Let's say that people got a clue and decide to
put T' in the specification instead of T.  According to you we still cannot say
in the specification that T' is here because even if T seems obvious (a common
characteristic of all things patented) we cannot use it.  Now 5 years from now,
someone wanting to implement the specification has no idea why it is so complex,
because the reason is not in the spec and not in the mailing-list archives.

How is that not fundamentally broken?

> Stephan
> 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
>>> pointer.
>>> 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.  
>> 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
>> oldest
>> 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
>> one
>> 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
>> if
>> we discuss patent and prior art and so on in this mailing-list, because
>> neither
>> 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
>> technique
>> cannot be used, and I do not see how to do this without discussing the patent
>> in
>> 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
>> will
>> 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.
>> And, BTW, IANAL.

Marc Petit-Huguenin
Personal email:
Professional email: