Re: [codec] Skype IPR disclosure

[stephen botzko <[e-mail]>]

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

Note well the emphasized clause.
> 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.

Stephen Botzko



On Sun, Mar 28, 2010 at 2:13 PM, 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/
> >>
> >> 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
> _______________________________________________
> codec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec
>