See also: last week's Back page page.

Linux links of the week

One of the more interesting weblog sites out there is Hack the Planet by Wesley Felter.

Section Editor: Jon Corbet

Letters to the editor

Date: Thu, 24 Feb 2000 09:39:35 -0700
From: Bruce Ide <nride@uswest.net>
To: editor@lwn.net
Subject: UCITA Woes

Unlike the majority of the readership, I _LIKE_ UCITA. Before you ask me
if I'm on crack, let me explain why.

UCITA will kill proprietary software dead. It gets rid of the "Who do
you sue" FUD that is one of the last remaining bastions of the MS FUD
slingers -- every shrinkwrap license I've ever read denies that the
software manufacturer is responsible for damages more than $5. The
warranty laws in some states have forbidden this in some cases but with
a newly implemented UCITA to back up the shrink wrapped, those warranty
laws may end up playing second fiddle (IANAL but I play one on TV.)

No businessman in his right mind would allow the various licenseing
agreements into his business. Especially in the software industry, where
Microsoft might decide one day that Borland is violating some little
clause in their license and recall their software (for example.) When
your company competes against everyone and also provides the majority of
the software required to run a computer, it's like shooting fish in a
barrel. Twice. In the head. With an elephant gun.

I predict that within 5 years of widespread acceptance of UCITA,
proprietary software and licenses will be dead (Or at least coughing up
blood.) Businessmen will insist on the GPL and openly documented file
formats and they won't play unless they get them. This is a good thing
(And I'll finally stop getting those !%!@#$ Word attachments in E-Mail.)

At the same time, developers will still be in demand. The software world
won't stop just because propretary software does. We'll still be able to
make a good living doing custom software, software to sell hardware,
etc.

I can only hope that proprietary software companies don't realize the
potential consequences of pushing this software until it's too late and
they're all closing their doors.

-----
Bruce Ide                 nride@uswest.net

SOMEONE had to put all that chaos there!

Date: Tue, 29 Feb 2000 18:28:21 -0800
From: Rick Moen <rick@linuxmafia.com>
To: letters@lwn.net
Subject: Tripwire: Open Source?

Dear Ms. Coolbaugh and Mr. Corbet:

I note with interest your 2000-02-29 news item, "Tripwire goes Open 
Source".

The company press release in question -- and their FAQ at
http://www.tripwire.org/faq.html -- claims an "open-source" version will
be available in Q3 2000, but conspicuously fails to state under what
licence.  I hope they will clarify their intentions, and have written
them to inquire.

The history of Tripwire is interesting.  Contrary to the lwn.net story's
claim, Tripwire did _not_ originate under an open source model:

It was written by Gene Kim and Gene Spafford at Purdue's COAST Lab, with
copyright held by Purdue Research Foundation, and was among the many 
proprietary security packages widely _assumed_ (in error) to be free
software (like SSH after v. 1.2.12, COPS, SATAN, and PGP), because of
source-code availability.  But, like the others, it had permitted-usage,
USA-export, and patent restrictions.  Kim and Spafford then developed 
the code through v. 1.2 at COAST, at which time the project stagnated --
perhaps because of its restrictive licencing.

In 1997, Purdue Reseach Foundation (the code's owner) licenced exclusive
commercial rights to Gene Kim's new company, initially named Visual
Computing Corporation, then Tripwire Security Systems, Inc., and finally
Tripwire, Inc.  That company has released versions 1.3 through 2.2.1 as
proprietary, binary-only software (while furnishing source in an
"Academic Source Release" (ASR) variant subject to certain proprietary
restrictions).

The point is that Tripwire, Inc. may still be unclear on open-source
licencing -- as Tripwire has never used it, over its entire eight-year
history.  E.g, wording like the FAQ's statement that "There are 
currently no plans to make open source any of the other UNIX
versions..." makes one wonder if the company is aware that OSD-compliant
licences (http://www.opensource.org/osd.html) permit anyone to freely
port the code to additional platforms.

Additionally, one wonders what latitude Tripwire, Inc. will have in
deciding its licence -- since to my knowledge Purdue Research Foundation
still owns the underlying copyright, and has _not_ open-sourced its
property.

Meanwhile, the leading GPLed replacement for the proprietary Tripwire 
package, Rami Lehti's AIDE (Advanced Intrusion Detection Environment, at
http://www.cs.tut.fi/~rammer/aide.html) has already advanced to exceed
Tripwire ASR's capabilities, and of course benefits from the accelerated
development cycle characteristic of genuine open-source licencing.

In that sense, it would make sense for Tripwire, Inc. to genuinely
open-source its product, as that might help it to compete.

-- 
Cheers,                        My pid is Inigo Montoya.  You kill -9    
Rick Moen                      my parent process.  Prepare to vi.
rick (at) linuxmafia.com 

Date: Fri, 25 Feb 2000 07:32:13 +1100
From: Matthew Geier <matthew@arts.usyd.edu.au>
To: letters@lwn.net
Subject: Linux on the IA64


 Linux of course has a 5 year head start on being '64bit clean' due to
the efforts of Digital Equipment Corp. and the Alpha Chip.

 It must be  5 years ago now since I first booted Linux on my 21066
based 'noname' and thus joined the 64bit world. (That system is still
running...)

 I've joined in the mailing lists since the early days when most of the
device drivers in the linux kernel would not work on the Alpha due to
the different native word size, I've first hand seen the effects  of
sloppy programming that assumes sizeof(int) == sizeof(*int)
and the like. 

 UltraLinux bought the 64bit environment to the SunSPARC architecture
quite some time ahead of Solaris being able to do so.

 The Trillian project has the advantage over the others by 'standing on
the shoulders of giants'. In particular many of the problems with
applications not being 64bit clean in the open source world have been
cleaned up over the years as people tried to run the applications on
their 64bit platforms (Digital Unix at first, then Linux/AXP,
Linux/Usparc), patched the source and submitted the changes to the
developers who in most cases don't have 64bit platforms. The commercial
closed source world is going to have to find these problems on their
own. We can't examine their source code.

 It is probably a bad sign for 64bit IA64 Windows NT that over 5 or more
years of Windows NT being supported on DEC Alpha platforms, it never
operated in 64bit mode, but remained a 32bit environment, while both
Linux and Digital Unix on the same platform ran in 64bit mode. (And
while DEC built different systems for NT and Digital Unix, Linux is more
at home on the systems that were built for NT, than the higher end
machines intended for DU, which your average Linux hacker couldn't
afford!).

Date: Tue, 29 Feb 2000 13:29:55 -0800
From: Dan Kegel <dank@alumni.caltech.edu>
To: humbubba@smart.net, letters@lwn.net
Subject: cLINeUXn: ignores the LSB?

Just read LWN's mention of cLINeUXn, and
ftp://linux01.gwdg.de/pub/cLIeNUX/A____start_here
which states
  "cLIeNUX has a very non-standard filename hierarchy."

This would seem to make it incompatible with the LSB,
which means it won't be able to use software packaged
in the future LSB binary package format, and may suffer
from other subtle portability problems, since a fair
amount of software assumes that files are as specified
by the LSB.

Perhaps I misread the announcement, but given that
'cat' lives in /command/unix in your distribution,
I don't have much hope of that.

Am I the only one worried by this?
- Dan