Re: [codec] Skype IPR disclosure

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

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