more on Software Patent Institute by LPF

L. Detweiler ld231782 at longs.lance.colostate.edu
Wed Aug 11 22:22:42 PDT 1993


(Someone wondered whether this was relevant to the list. The software
patent issue goes back a long ways with the cypherpunks and is
pre-eminent in `our' role of software development and the use of PGP
and other cryptographic and general algorithms.)

With that aside, here is some more info that should help cypherpunks
decide whether SPI is friend or foe, and I'd like to see reactions. 
They are either an obstacle or a useful tool in the eradication of past
and future software patents.

I used the subject `birth of the SPI' in the first message because
(ahem) I'd never heard of this organization or seen it mentioned here,
which is somewhat surprising given its goal. They may be fairly new but
Richard Stallman of FSF (Free Software Foundation) has forwarded a
paper by LPF (League of Programming Freedom) as early as April, so
they've been around at least that long, at least in theory.

The LPF paper is a bit speculative and clearly doesn't know what to
make of SPI except taking a rather pessimistic view--it probably came
out around the time of its inception.  The SPI acc. to the statement is
going to be a professional, searchable database in the style of Westlaw
and Lexus with a charge for access, `which suggests that in practice it
may be available primarily to larger companies'. This is probably the
most damaging claim:

>The SPI is supported by large companies such as IBM, Apple and DEC
>that can expect to have many software patents, and by patent law
>firms.  It is not likely these sponsors would support the SPI if they
>expected it to prevent most software patents.

Here are the other assertions:

- the database will tend to help companies strengthen their future
patents by eliminating the weak aspects by searching through the
database of `prior art'

- the SPI `cannot prevent all patents that harm the software field but
prevent a certain kind of Patent Office mistake: overlooking prior art
whose prior publication can be proved', `only a fraction of the patents
that cause trouble for programmers'.

But the LPF paper is very unsatisfying. It closes by simply suggesting
not to bother with SPI but

>Instead,
>spend it telling our lawmakers that software patents are harmful and
>should be abolished.

Definitely a valid approach, but seemingly a bit innocuous and
ineffectual. *If* SPI is a professional organization, well-backed, and
dedicated to the goal of abolishing software patents, it would be a
much more influential and dynamical force in the cause than a
letter-writing campaign.

I just wrote a message to R. Stallman pointing out the potential
advantages of this database in the cause of eradicating software
patents, and am listening for more info on SPI. I pointed out:

- Ultimately, the goal of constraining software patents *seems* to be
common to both the SPI and LPF, we just have the case that LPF is a
little more extreme in asking for complete abolution. To address this,
consider that SPI would be a useful stepping stone to a world with no
software patents.

- The database has the support of very major companies such as Apple,
IBM and DEC. This is the kind of thing that gets press coverage and
public attention and *pressure*.

- The database could actually be used as a tool to thwart new patents.
Potentially programmers could send all techniques not covered by past
patents to the list to prevent future patents regarding the art,
accompanied by notices `releasing the technique to the public domain'. 
I don't know the legal force of this, but the patent office has been
tiptoeing on tenuous law for software patents in the first place, and
perhaps might be encouraged to tiptoe in the opposite direction.

In other words, while the current patent situation is like a bunch of
landmines strewn by lawyers for programmers & developers, the archive
could hold a bunch of landmines strewn by programmers for the lawyers.

Anyway, I hope to hear more about this agency. If all that LPF
advocates is `writing letters to congressmen' and demeaning more
organized efforts (note I'm definitely reserving judgement on whether
SPI is a cypherpunk ally, current signs are not promising) then I'd say
they aren't going to meet with a lot of success.

Here's the complete paper from LPF, feel free to frame it or cover the
bit bucket with it.  While we may not know what to make of SPI
currently, it is likely to play a very prominent future role in this
arena if not disbanded. I would really like to hear from
representatives of Apple, DEC, IBM, et. al. on how their participation
& support of the project should be construed.

===cut=here===

	What Can The Software Patent Institute Accomplish?
	   by the League for Programming Freedom (14 April 1993)

Software patents are patents which can apply to (and thus prohibit)
writing a program.  Any software patent can cause trouble for people
who want to develop software.

Some software patents are Patent Office mistakes which cover things
that are already known.  In some cases (but not all), these mistakes
can be proved based on published prior art.

Other software patents do not result from errors of the system, but
are still disadvantageous to software development.  How much trouble a
software patent causes is independent of whether it violates the
patent system's own rules.  And the sheer number of software patents
causes trouble regardless of their details.

The Software Patent Institute is a new organization that aims to
produce a data base of "prior art"--published and known software
ideas--to make it easier for the Patent Office and others to find out
which software techniques and features are already known and thus
supposed to be unpatentable.

The SPI cannot prevent all patents which harm the software field.  It
can only prevent a certain kind of Patent Office mistake: overlooking
prior art whose prior publication can be proved.  Thus, the SPI can
address only a fraction of the software patents that cause trouble for
programmers.

Even perfect knowledge of prior art would not prevent all absurd
software patents.  Some software patents cover such trivial matters
that a description of the idea would be reject by any professional
technical journal.  For example, patent number 5,049,881, issued in
1991, covers modifying the way a data compression program uses a hash
table to look up the strings that have assigned encodings:
specifically, when it has found the hash bucket for a string being
looked up, it considers only the first string in the bucket as a
possible match, rather than all of them.  Patent number 5,140,321,
issued in 1992, covers checking just the first N strings in the hash
bucket as possible matches.  (Both of these modifications apply to a
particular data compression algorithm, and similar modifications could
probably be patented for any other algorithm.)

To ask whether those particular variations were published before, is
to miss the point---it is a mistake for patent system decisions to
depend on such questions.  But those questions are the only ones that
the SPI can help answer.

No matter how well the published prior art is known, it cannot include
all variations, and under current policy, many of these can be
patented.  What's more, you cannot effectively challenge decisions
about obviousness in court, because the courts presume that the Patent
Office has exercised good judgement when deciding what is obvious.

But suppose that the Patent Office learns how to judge obviousness
better; then how much good can the SPI do?  Even if this prevents a
sizable fraction of future software patents, that will not appreciably
reduce the problem that software patents cause for programmers.

Even cutting the number of software patents in half (which would be
great success for the SPI!) will not cut the problem in half.  This is
because a large software system is likely in the future to infringe a
large number of patents--easily dozens.  Even if half of them were
eliminated, the remaining half could still create prohibitive
problems.

There is no official figure for the number of software patents we have
today, but 5000 or 6000 is a likely estimate given past numbers and
trends.  (To find them all would be a mammoth task.)  At the beginning
of 1992 there were 9000 pending patent applications in a category
which contains many software patents, which suggests there will be
many more software patents in the future.  To make software
development a safe activity again, we must do more than cut the number
of patents in half.  Eliminating 90% of the software patents that
exist today would just reach the level where further reduction starts
to help matters.  (See the LPF's position paper, "Against Software
Patents," for more explanation of why software patents in general
cause mainly trouble, even those that are not trivial.)

While the SPI may prevent some software patents from being issued,
ironically it may also make some patents more dangerous by helping the
patent applicant design the patent to withstand legal challenges.
Even the holders of existing patents can use this information to
rewrite the patents and make them harder to overturn.  For more
information, see the companion paper, "What Should You Do With Prior
Art?"

The SPI is supported by large companies such as IBM, Apple and DEC
that can expect to have many software patents, and by patent law
firms.  It is not likely these sponsors would support the SPI if they
expected it to prevent most software patents.

The interface proposed for the SPI's database will resemble those of
Westlaw and Lexis; it seems to be aimed at use by lawyers, not
software developers.  The SPI plans to raise revenue by charging for
access to the data base, which suggests that in practice it may
available primarily to larger companies.

The operation of the SPI will not alter the overall software patent
problem.  So wish the SPI good luck in preventing a few absurd
software patents; but don't spend your time on the SPI.  Instead,
spend it telling our lawmakers that software patents are harmful and
should be abolished.







More information about the cypherpunks-legacy mailing list