Re: [codec] Skype IPR disclosure

[Rob Glidden <[e-mail]>]

This is an example of why attempting to impose a lets-talk-about-IPR-without-talking-about-IPR coded language is unwise and unwarranted.

When there is an IPR disclosure, by definition the patent holder will know anyway. (If the disclosure is by the patent holder, they will know because they made the disclosure.  If the disclosure is by a third party, the patent holder will know because they will be notified by IETF under BCP 4879).

So the idea that there is a need or benefit to talk about a patent holder's IPR without the patent holder knowing is wrong on several levels, and it isn't made right by characterizing certain patent holders as trolls with Google skills.

Trying to develop a coded language about patents that patent holders themselves could not decipher when they know it is going on would just create a situation where there are IETF IPR disclosures with no corresponding record the IPR was ever removed -- exactly the FUD-laden situation this working group was chartered to fix.  This is not a who-cares-if-the-design-motivation-gets-lost situation.

Rob

Stephan Wenger wrote:

Hi Marc,

It is not difficult to convey a patent-related motivation--even
information--without exposing other people and their employers in an obvious
way.  

Allow me to put exaggerated words into your mouth: "I believe our current
draft, especially algorithm T, is infringing on US 1,234,567, claim 8.  We
may be better off with T', because <non-infringement argument>"  (Believe it
or not, I have seen this type of language, and not from a plaintiff's
attorney in a closing argument--which is the only place where such words
ought to be uttered :-)  And here is what I would write: "In conjunction
with IPR disclosure #1234, I have studied certain documents.  It may be to
all (well, almost all) of our advantage if we were replacing algorithm T
with algorithm T'.  One advantage would be <non-infringement argument>"

The first alternative exposes all subscribers to a patent number, and would
show up with a simple google search of a patent numbers (even lawyers
representing trolls know google, unfortunately, and probably a bit better
than some of us...).  The second conveys information that an informed and
interested reader can probably quite easily use to end up with the same
factual information, but is not so obvious.

That's all what I ask for.

(That I, personally, like my hide enough not to discuss someone else's
patent is a different story.)

As for the documentation of motivations for historic reasons: motivations
for design choices get lost in standardization all the time.

Regards,
Stephan




On 3.28.2010 11:13 , "Marc Petit-Huguenin" <[e-mail]> wrote:

  

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/" rel="nofollow">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.