Letters to the editor

Irresponsible SCO

I haven't seen much discussion of this in the Linux
community, perhaps because the charges are so vague, but I
thought something meaningful could be said.

Andy


-------

http://www.oreillynet.com/pub/wlg/2889

Reference: http://news.com.com/2100-1016-991622.html

   A lot of brickbats are coming the way of SCO since it launched a
   lawsuit against IBM on the grounds of trade secrets. What's scandalous
   is not the choice to resort to a lawsuit--because companies have to
   defend these sorts of things in court in order to preserve their
   meaning--but the disregard for the needs of Linux users, developers,
   vendors, and watchers everywhere. SCO chose a low road indeed, trying
   to maximize its legal flexibility instead of acting like a member of a
   community.

   Linux supporters are worried about this for good reason. The lawsuit
   inevitably recalls the suit AT&T brought against the Berkeley
   developers of BSD in the 1980s. Then as now, the issue was that
   developers had access to UNIX during the time they developed their own
   code. The AT&T complaint involved copyright rather than trade secrets,
   but the parallels are unmistakable.

   Although my memory may deceive me, I believe AT&T never demonstrated
   that a single line of BSD code originated in UNIX (which officially
   should be written in all-caps). The lawsuit was resolved after many
   years, but a lot of people blame the confusing around the suit for the
   stagnation of BSD and its inability to take off at the crucial moment
   when people were looking for a free software operating system. (I
   doubt that suit was the problem, but it did waste time and make a mess
   of things.

   AT&T sold its rights to UNIX long ago, apparently recognizing that it
   was managing every aspect of that valuable technology with the same
   incompetence that it had conducted the BSD lawsuit. As intellectual
   property, UNIX bounced around for a while and ended up at SCO. It's
   probably no coincidence that SCO decides to act the heavy around this
   period when many observers believe UNIX is dying and that Linux will
   take over where it stood.

   But they know very well what problems and bad feelings the BSD lawsuit
   reached. They know how many people (roughly) depend on Linux day by
   day. What would a responsible company do to uphold its rights while
   allowing the world to continue?

   SCO could have examined Linux code and determined where their
   purported trade secrets lay. They would then have widely publicized
   the disputed code. They'd say, "Don't use JFS" (or whatever it
   happened to be); "we're litigating it." Whatever components were in
   dispute could quickly be pulled out of the kernel; users could depend
   on other components for whatever functionality they needed.

   Of course, SCO's lawyers wouldn't tell them to do this. I'm sure the
   lawyers want as wide a field to play on as they can get. And it is not
   they who will be appalled when play is done and they discover the
   whole field has been turned into a desert.

   SCO can still overrule its narrow-minded lawyers and take a high road.
   If they've got a claim, make it clearly. That is what the public
   deserves. Judging from the scattered news reports I've read, they
   refused to be specific even in the legal complaint they sent the
   court.

   And this hand-waving is a tell-tale sign of weakness. We are all
   justified in assuming, till we have evidence to the contrary, that
   SCO's lawsuit will go the way of the evidence the Bush administration
   waved about excitedly for months concerning aluminum tubes purchased
   by Iraq, now revealed by weapons inspectors on the ground to bear no
   relation to weapons of mass destruction. But millions of users around
   the world are in limbo until we know for sure, and there is no reason
   for that except malice or hamfistedness on the part of SCO.

Andy Oram

Comments (none posted)

In defence of RPM!

Hi,

I was reading the distrowatch artcile (Is RPM Doomed?
http://www.distrowatch.com/dwres.php?resource=article-rpm) which
contained was a long rant against the incompatabilities of binary RPM's
across distributions. Although the article did point out a few ways
things can be improved I feel as though I must jump in with a little
pro-RPM evengelism :-)

Firstly a quick question. Why is binary compatibility required?

The majority of applications your likely to look at are source based. If
the binary RPM exists then there should .src.rpm nearby. In my
experience 99% of dependancy problems are solved by simply building the
binary RPM yourself. I can't believe your suggesting moving over to a
source based distribution because:
    emerge application
saves a few lines over:
    rpm --rebuild application.src.rpm
    rpm -ivh ~/rpm/RPMS/applictaion.rpm

I'll grant that Gentoo's source based system offers a lot when it comes
to large multi-component builds. However if your really that up for the
bleeding edge you'll find living on Manrake Cooker (or Debian unstable)
costs you less time in the long run than constantly rebuilding common
components.

In fact I run Mandrake Cooker on my main desktop and I've had very few
problems with running a:
    urpmi.update -a
    urpmi --auto-select
every few days. I can leave the heavy lifting to the Cooker people and
concentrate on the apps I'm actually interested in.

But arguments about ease of building asside the biggest difference rpm 
makes to my life is knowing where all the files on my PC come from.
Having in the past lived/survived a windows environment where your never
quite sure if a DLL is left over detruitus or an essential system
component I find the ability to do a:
    rpm -qf /usr/bin/randomfile
a godsend. As a bonus I know if I un-install a package from my system
all its files go with it leaving nothing lying around.

As I have consistently found with open source tools its easy to get
frustrated at percieved inadaquacies at first but if you invest a little
time reading the documentation/playing with the app your experience is
drastically improved and you'll wonder how you got along without it.

Briefly returning to the problems of people who distribute binary only
rpm's (of which is concern mainly to the commercial software people)
there is a solution. Build your binary RPM's for the big 3 (RedHat,
Mandrake, UnitedLinux) and build a forth statically linked RPM for the
rest.

Regards,

-- 
Alex, homepage: http://www.bennee.com/~alex/

Everyone is a genius.  It's just that some people are too stupid to realize it.

Comments (1 posted)

Page editor: Jonathan Corbet