Re: [codec] Skype IPR disclosure

[Stephan Wenger <[e-mail]>]

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.

Stephan
   
   


On 3.28.2010 08:22 , "Marc Petit-Huguenin" <[e-mail]> 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.  
> 
> http://news.swpat.org/2010/03/transcript-tridgell-patents/
> 
> 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.