Bug#1883: compress" missing?
Bruce Perens wrote:
> Unfortunately, "compress" infringes the Unisys - Terry Welch patent.
Hmm. Tell Unisys that Slackware and FreeBSD violate their patent, they
will sue Walnut Creek and win. There will be no Slackware and FreeBSD
any more, and everyone will switch to Debian GNU/Linux soon. Sounds like
a great way to eliminate the competition :-).
Seriously, appended you will find some documentation from the FreeBSD
compress source. I hope this will clear up some confusion.
Not everyone lives in the US (really :-) so it would be real nice to have
a "non-free-in-the-US" directory with things like compress, anything that
handles the GIF format, maybe pgp-i, ssh (it uses RSA) etc. US is probably
the only country with such bogus patents...
BTW, there is some BSD-derived PPP compression code in recent 1.3.xx kernels
(it is a loadable kernel module, probably to avoid conflicts with the GPL).
I hope the 1.4 kernel will not be in non-free for this reason...
Thanks,
Marek
-----
From: James A. Woods <jaw@eos.arc.nasa.gov>
>From vn Fri Dec 2 18:05:27 1988
Subject: Re: Looking for C source for RSA
Newsgroups: sci.crypt
# Illegitimi noncarborundum
Patents are a tar pit.
A good case can be made that most are just a license to sue, and nothing
is illegal until a patent is upheld in court.
For example, if you receive netnews by means other than 'nntp',
these very words are being modulated by 'compress',
a variation on the patented Lempel-Ziv-Welch algorithm.
Original Ziv-Lempel is patent number 4,464,650, and the more powerful
LZW method is #4,558,302. Yet despite any similarities between 'compress'
and LZW (the public-domain 'compress' code was designed and given to the
world before the ink on the Welch patent was dry), no attorneys from Sperry
(the assignee) have asked you to unplug your Usenet connection.
Why? I can't speak for them, but it is possible the claims are too broad,
or, just as bad, not broad enough. ('compress' does things not mentioned
in the Welch patent.) Maybe they realize that they can commercialize
LZW better by selling hardware implementations rather than by licensing
software. Again, the LZW software delineated in the patent is *not*
the same as that of 'compress'.
At any rate, court-tested software patents are a different animal;
corporate patents in a portfolio are usually traded like baseball cards
to shut out small fry rather than actually be defended before
non-technical juries. Perhaps RSA will undergo this test successfully,
although the grant to "exclude others from making, using, or selling"
the invention would then only apply to the U.S. (witness the
Genentech patent of the TPA molecule in the U.S. but struck down
in Great Britain as too broad.)
The concept is still exotic for those who learned in school the rule of thumb
that one may patent "apparatus" but not an "idea".
Apparently this all changed in Diamond v. Diehr (1981) when the U. S. Supreme
Court reversed itself.
Scholars should consult the excellent article in the Washington and Lee
Law Review (fall 1984, vol. 41, no. 4) by Anthony and Colwell for a
comprehensive survey of an area which will remain murky for some time.
Until the dust clears, how you approach ideas which are patented depends
on how paranoid you are of a legal onslaught. Arbitrary? Yes. But
the patent bar the the CCPA (Court of Customs and Patent Appeals)
thanks you for any uncertainty as they, at least, stand to gain
from any trouble.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
From: James A. Woods <jaw@eos.arc.nasa.gov>
Subject: Re: Looking for C source for RSA (actually 'compress' patents)
In article <2042@eos.UUCP> you write:
>The concept is still exotic for those who learned in school the rule of thumb
>that one may patent "apparatus" but not an "idea".
A rule of thumb that has never been completely valid, as any chemical
engineer can tell you. (Chemical processes were among the earliest patents,
as I recall.)
ah yes -- i date myself when relaying out-of-date advice from elderly
attorneys who don't even specialize in patents. one other interesting
class of patents include the output of optical lens design programs,
which yield formulae which can then fairly directly can be molded
into glass. although there are restrictions on patenting equations,
the "embedded systems" seem to fly past the legal gauntlets.
anyway, i'm still learning about intellectual property law after
several conversations from a unisys (nee sperry) lawyer re 'compress'.
it's more complicated than this, but they're letting (oral
communication only) software versions of 'compress' slide
as far as licensing fees go. this includes 'arc', 'stuffit',
and other commercial wrappers for 'compress'. yet they are
signing up licensees for hardware chips. hewlett-packard
supposedly has an active vlsi project, and unisys has
board-level lzw-based tape controllers. (to build lzw into
a disk controller would be strange, as you'd have to build
in a filesystem too!)
it's byzantine
that unisys is in a tiff with hp regarding the patents,
after discovering some sort of "compress" button on some
hp terminal product. why? well, professor abraham lempel jumped
from being department chairman of computer science at technion in
israel to sperry (where he got the first patent), but then to work
at hewlett-packard on sabbatical. the second welch patent
is only weakly derivative of the first, so they want chip
licenses and hp relented. however, everyone agrees something
like the current unix implementation is the way to go with
software, so hp (and ucb) long ago asked spencer thomas and i to sign
off on copyright permission (although they didn't need to, it being pd).
lempel, hp, and unisys grumbles they can't make money off the
software since a good free implementation (not the best --
i have more ideas!) escaped via usenet. (lempel's own pascal
code was apparently horribly slow.)
i don't follow the ibm 'arc' legal bickering; my impression
is that the pc folks are making money off the archiver/wrapper
look/feel of the thing [if ms-dos can be said to have a look and feel].
now where is telebit with the compress firmware? in a limbo
netherworld, probably, with sperry still welcoming outfits
to sign patent licenses, a common tactic to bring other small fry
into the fold. the guy who crammed 12-bit compess into the modem
there left. also what is transpiring with 'compress' and sys 5 rel 4?
beats me, but if sperry got a hold of them on these issues,
at&t would likely re-implement another algorithm if they
thought 'compress' infringes. needful to say, i don't think
it does after the abovementioned legal conversation.
my own beliefs on whether algorithms should be patentable at all
change with the weather. if the courts finally nail down
From <@mongo.pixar.com:debian-devel-request@Pixar.com> Wed Nov 22 07:19:04 1995
Received: from mongo.pixar.com (mongo.pixar.com [138.72.50.60]) by bugs.cps.cmich.edu (8.6.12/8.6.9) with ESMTP id HAA05993 for <jdassen@bugs.cps.cmich.edu>; Wed, 22 Nov 1995 07:19:03 -0500
Received: by mongo.pixar.com (8.7.1) id EAA12128; Wed, 22 Nov 1995 04:18:22 -0800 (PST)
Old-Return-Path: <iwj10@cus.cam.ac.uk>
Subject: Bug#1656: etc/ntp.drift should be somewhere in /var (FSSTND)
Reply-To: Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl>,
debian-bugs@Pixar.com
Resent-From: Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl>
Resent-To: debian-devel@Pixar.com
Resent-Date: Wed, 22 Nov 1995 12:18:04 GMT
Resent-Message-Id: <debian-bugs-handler.1656.B11221213270@pixar.com>
X-Debian-Pr-Package: xntp
From: Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl>
Message-Id: <199511221209.NAA01095@i17linuxb.ists.pwr.wroc.pl>
To: andrew@kryten.it.com.au (Andrew Howell)
Date: Wed, 22 Nov 1995 13:09:38 +0100 (MET)
Cc: debian-bugs@Pixar.com
In-Reply-To: <m0tI45O-000AZZC@kryten.it.com.au> from "Andrew Howell" at Nov 22, 95 09:34:53 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
X-Mailing-List: <debian-devel@Pixar.com> archive/latest/7612
X-Loop: debian-devel@Pixar.com
Precedence: list
Resent-Sender: debian-devel-request@Pixar.com
Andrew Howell:
> There is already a /var/log/ntpstats directory, but I don't think it's
> really the right place for it, it's not really a log file. Unless someone
> really objects I think I'll just leave it in /etc
According to fsstnd-1.2, "application state information" (I think ntp.drift
is such a file) belongs in /var/lib. So I suggest /var/lib/ntp/ntp.drift
or something like this. I don't really object to /etc but we are supposed
to conform to fsstnd...
Regards,
Marek
Reply to: