[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: libdts patent issue?



On 7/19/05, Nathanael Nerode <neroden@twcny.rr.com> wrote:
> Arnoud Engelfriet wrote:
> >I agree with you that the distinction may seem artificial. But it
> >does seem logical to me to say "you can't patent A XOR B but you can
> >patent a computer program that does that."
> If you can patent the class of computer programs which do A XOR B,
> you have patented the abstract operator which does that.

Arnoud said that computer programs as such are not patentable subject
matter under the EPC, and as I read it that's also true in the US
under Alappat's "useful, concrete, tangible result" test.  You can
patent a computer program that does A XOR B in its character as a
solution to the problem of encrypting messages encoded as digital
data, but that same program used to achieve some unrelated tangible
result isn't covered by the patent.  Arnoud, am I getting your
argument straight?

> >Then the formula remains
> >public domain; you just can't make, use or sell a program that
> >implements the formula. Were the formula patented, then you couldn't
> >even publish a textbook.
> Unfortunately, that's a distinction without a difference.  If you're
> prohibited from making a computer program implementing the algorithm, you're
> prohibited from writing a formal description of the algorithm, which is a
> standard textbook technique.  (A computer program *is* a formal description
> of an algorithm.)  If you're prohibited from selling such a program, you're
> prohibited from selling such a textbook.

Patent is not copyright; you don't obtain a monopoly on describing
your method, you obtain a monopoly on its commercial application.  No
patent prohibits you from making a computer program implementing any
algorithm you like; but if you sell it as a solution to the problem
addressed in the patent, without authorization from the patent holder,
you are infringing.  The same goes for selling its output, if that's
covered by the patent -- compare against the enforcement of chemical
process patents.

So I think Arnoud's point is that, if a formula or other abstract idea
were patentable without any indication of the result being achieved,
then a textbook would be just as much an infringement of this
counterfactual patent as a computer program or a machine that embodies
it.  His "make, use, or sell" language is a little bit over-broad, but
essentially accurate insofar as the maker may be liable for infringing
use of the program by third parties even if he cannot be demonstrated
to have made infringing use of it himself or to have profited from its
sale.

> The use prohibition is at least different: if only the use prohibition were
> present, you could indeed publish a textbook, but nobody would be allowed to
> use its techniques without a license.

If people bought the textbook principally so they could copy down
sections that amounted to an implementation of the patented invention,
and proceeded to use them in an infringing way, then AIUI you could be
liable for contributory infringement.  Don't cry First Amendment,
either -- it's not the writing and publishing that are getting you in
trouble, it's the collusion in tortious and/or criminal activity, and
freedom of speech/press doesn't cover that any more that it exonerates
a mafia don who orders a hit with a little help from a printing press.

> According to this "distinction", we could distribute Debian
> as a "computing textbook" rather than as a "system", and we would then be
> exempt from these patent considerations.

Doesn't make a bit of difference what you call it.  What matters is
what it is and what people use it for.

> (The current US rule is that that every such patent is for a "program plus a
> generic computer", so this should actually work.  Only the silly people who
> use Debian on their computers who are violating the patent, although Debian
> might be in trouble for encouraging them.  Actually, the users might be fine
> too, because they're not using the process on an industrial scale.  Hey --
> there's a solid line of argument: the program itself doesn't violate
> anything, only the program plus a computer, and it's only combined with the
> computer at the end-user's house.  This is silliness, of course, but that's
> what you get for making a distinction without a difference.)

That is not the current US rule as I understand it.  Despite the
patent-attorney-encouraged "computing means" shibboleths of the 80's
and 90's, applications of software techniques to practical problems
are just as patentable when stated using "process" lingo as when using
"machine" lingo, certainly now (per AT&T v. Excel) but AFAICT all
along.  The only appellate precedent I have ever seen alluded to which
suggests otherwise is an administrative appeal regarding "the Koo
patent"; I'll track it down when I have time.

As for the "personal use" exemption:  thread at
http://lists.debian.org/debian-legal/2005/07/msg00267.html .  My own
opinion (IANAL, TINLA) is that the statutory exemption wouldn't
protect Debian but that Thomson's declaration that they have no
objection to personal use of LAME might, especially if Thomson and
Debian can discuss the matter directly and find enough common ground.

[snip stuff which doesn't need to be archived on the web forever once,
let alone twice]

I am glad that I do not live in the dystopic fantasy world you
describe, with incompetent judges obsessed by sophomoric deductions
from Plato and easily led by the nose.  Most judges are not software
engineers but few are utter fools, and to argue otherwise you're going
to need to adduce real evidence.

Cheers,
- Michael



Reply to: