Subject: Re: Why software patents are bad
From: "Karsten M. Self" <kmself@ix.netcom.com>
Date: Thu, 23 Sep 1999 17:23:14 +0000

"Stephen J. Turnbull" wrote:
> 
> Addressee list trimmed.
> 
> >>>>> "kms" == Karsten M Self <kmself@ix.netcom.com> writes:
> 
>     kms> you've got a databank to refer to in trying to invalidate
>     kms> patents (cost: US$100k pretrial, US$1m trial).
> 
> I've seen this number several times now.  If Aharonian's research may
> be taken at face value, there must be large numbers of "sitting duck"
> patents out there.  They should be a lot easier to go after.  Doing so
> would up the ante for applications, especially if the law includes
> penalties for frivolous applications (ones which make claims on
> algorithms discussed in well-known textbooks, for example).
> 
> Furthermore, documenting a large database of patents filed on the
> basis of previous art, and also making a database of prior art
> available, should slow down the issuance process.  Throw sand in the
> gears!  Especially if it's sand that is _legally supposed_ to be there
> anyway.  :-)
> 
> I seem to recall that large numbers of patents are available in online
> databases; maybe we should have "tiger teams" attack them instead of
> RC5.

Someone's been reading my InfoWord Electric forum posts <g>

My response to the guy offering to set up a "bad patents" database (hey,
he's registered patentabuse.com and patentabuse.org....)

http://forums.infoworld.com/threads/get.cgi?136622

Quoting Self:

> The value-added would be to track attempts to enforce the patent 
> against OSS developers (incidents, parties, dates), and to use 
> these occasions to identify patent and non-patent prior art which 
> might be useful in invalidating the patent. 
> 
> The advantage of this approach is that you're not a priori deciding 
> that patents are or are not invalid, nor are you spending a lot 
> of time gathering information which won't be particularly useful. 
> But as patents are enforced against free software, they are 
> identified and possible weaknesses are cataloged. 


>     kms> Patent pools are one method, they require free
>     kms> software-friendly patents.  A copyright|license based
> 
> This requires either help from IBM or some entity like it, or far more
> work than the sand in the gears approach.

That's my general impression.
 
>     kms> poison-pill defense is another, it strikes me as much more
>     kms> usable and amenable to the situation of the free software
>     kms> community.  Using both methods is certainly possible.
> 
> Except that software covered by a "poison-pill" is not free any more.
> Double-plus-ungood.
> 
> For it to work, you _must_ shoot innocent bystanders:  programmers and
> users whose only sin is prior employment at a company whose legal
> department decides to take action against a covered project.  This is

I don't see that this is the case.
 
> If you don't turn up the heat on such unwitting "accomplices," then
> you're opening wide the "patent shark subsidiary" hole.  Arguably, you
> should go after the customers of the company, too, if any, who

The patent shark subsidiary problem exists equally for a patent pool as
for a poison pill.  However there's a potential strategy for dealing
with it in a patent pool, which I identified when considering the
concept.  It's what I called "asset contribution" -- essentially a pool
participant has to contribute assetts to the pool in proportion to their
size (revenues, market cap, whatever).  The assetts can be patents or
cash.  Our hypothetical Shark Co tries to pull a quick one on the pool
by establishing Shark Industries (sells product) and Shark Technologies
(holds patents).  If Shark Co is roughly equivalent to other companies
its size, it holds roughly the same number of patents as they do. 
Joining the pool will cost either patents or dough....

The poison pill situation is clearly different.  Several approaches
suggest themselves:

 - Piercing the corporate veil, as suggested previously.  Show that
Shark Industries and Shark Technologies are effectively one company.

 - Define "Affiliates" to be organizations held by, holding, co-held, or
otherwise obligated to one another, and require that a licensee and its
affiliates restrain themselves from patent infringement suites.

 - Hold software licensees responsible for the actions of major patent
licensors.  Something like "the friend of my enemy is my enemy" or
"gains by poisoned fruit shall poison".  I'm not sure this is necessary,
possible, or attractive.  I'm curious as to why Stephen suggests it.

-- 
Karsten M. Self (kmself@ix.netcom.com)
    What part of "Gestalt" don't you understand?

SAS for Linux: http://www.netcom.com/~kmself/SAS/SAS4Linux.html
Mailing list:  "subscribe sas-linux" to
mailto:majordomo@cranfield.ac.uk    
  1:38am  up  4:39,  0 users,  load average: 0.07, 0.09, 0.03