Re: [codec] Skype IPR disclosure

[Marc Petit-Huguenin <[e-mail]>]

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


-- 
Marc Petit-Huguenin
Personal email: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org