See also: last week's Back page page.

Linux Links of the Week

If you're not in the Bay area, or are stuck at home, the Linuxcare product comparisons page can be a good place to look to find some fun new software to play with instead. The breadth of the coverage is growing; this page is turning into a useful resource.

Section Editor: Jon Corbet

This week in history

Two years ago (October 8, 1998 LWN): We asked "what will happen to the Linux VARs?" With companies like Dell making noises about getting into Linux, it looked like life could get harder for companies that sold Linux-installed computers. Two years later, most of those companies are still around and doing better than ever. But people still wonder what will happen when the Dells of the world get serious...

A new Linux news site called LinuxToday was launched by Dave Whitinger and Dwight Johnson.

Nice thought of the week:

The arguments are both noble and naïve. Linux has a cult-like following, matched only by that of the Macintosh OS and OS/2. It's a modern Unix! It's stable, superior, enriching! It's gonna get creamed. -- Richard Brandt, Upside.

Upside has since changed its tune on Linux, to say the least.

Oracle8 for Linux went up for free download. For a long time Linux supporters had heard people say that "when Oracle is available for Linux" they'll know it's serious. It was serious.

One year ago (October 7, 1999 LWN): Sun announce the release of the Solaris source code - under the Sun Community Source License. One year later, that source release has yet to make much of a splash.

Microsoft came out swinging with its Linux Myths page:

Linux is a higher risk option than Windows NT. For example how many certified engineers are there for Linux? How easy is it to find skilled development and support people for Linux? Who performs end-to-end testing for Linux-based solutions? These factors and more need to be taken into account when choosing a platform for your business.

Meanwhile, some people figured out that ssh 1.2.12 had been published under a free software license. People grabbed hold of it, and the OpenSSH project was born. OpenSSH is now the standard version for Linux systems.

Red Hat 6.1 hit the FTP servers, though the boxed version wasn't due out until October 18.

Letters to the editor

Date: Thu, 28 Sep 2000 12:01:03 -0700 (PDT)
From: Jonathan Walther <krooger@debian.org>
To: Dave Peacock <davep@netscape.com>
Subject: Re: Outrage at Debian dropping security for 2.1


If you want us to support security, perhaps you
could propose some incentive?  We are all volunteers
here at Debian, interested in putting out a quality
distribution.  Your time is limited, otherwise I'm sure
you too would love to fix and upgrade your distribution
from source.  But our time is also limited, and we want
the most bang for buck out of it.  That means not fighting
the current of progress, and keeping up with new versions
of software.

If security updates are of concern to you, perhaps you
could get your company to pay some Debian maintainers to
work on the old distribution.  If you have the time,
perhaps you would like to volunteer to do some of that
maintainership yours.

The distribution we've just released is the culmination
of 2 years of hard work for us.  Try it.  You'll like it.
Unlike many other distributions which require a reinstall
from scratch, Debian guarantees a reliable upgrade path.

Sincerely,

Jonathan Walther
Debian GNU/Linux Developer

Date: Fri, 29 Sep 2000 14:22:22 -0700 (PDT)
From: Seth Cohn <scohn@clipper.net>
To: debian-devel@lists.debian.org
Subject: Re: Outrage at Debian dropping security for 2.1

Branden Robinson:

> Does Mr. Peacock expect Debian to provide security updates for Debian 2.0,
> 1.3, 1.2, or 1.1?  Does he expect, say, Red Hat, to provide security
> updates for 6.0?  How about 5.0?  4.2?  1.0?

> If someone is willing to maintain reliable, net-accessible slink, hamm, bo,
> rex, and buzz boxen for all architectures supported by those releases, then
> perhaps we can do what Mr. Peacock expects.  Otherwise...

A few of us discussed this last night at our LUG meeting, and the obvious
answer is that since the security fixes tend include source changes,
someone can always grab the source for the 'security' fix from the later
version and rebuild the package.  Yes, some libraries etc might need to be
changed, and this isn't 100% but anyone who is sticking with Slink for
production purposes should be able to use Potato fixes in many cases.

In the rare cases where things don't work, I'd bet if someone posted a
request for a Slink package version of a new security fix, saying clearly 
that the existing Potato package didn't work, someone would repackage it
to fit.

In another vein, this clearly could be support revenue for someone
interested.  Supporting older Debian releases could be very lucrative for
the right person(s).  Maybe Debian's normal volunteer security team isn't
interested, but someone might be if the price was right.

Seth Cohn

Date: Thu, 28 Sep 2000 23:36:37 -0500
From: Branden Robinson <branden@debian.org>
To: Dave Peacock <davep@netscape.com>, letters@lwn.net,
Subject: Re: Outrage at Debian dropping security for 2.1

It was pointed out to me today that perhaps Mr. Peacock did not release
that Debian 2.1, a.k.a "slink", is *not* the currently released version of
the Debian system.

The current version is Debian 2.2, a.k.a. "potato", which was released in
July, and we certainly take security updates very, very seriously for this
release (as well as other issues, such as usability, that merit an update
to the released distribution).

Perusal of the past several weeks' worth of Linux Weekly News will reveal
that Debian is quite timely with security updates to our released current
distribution.  (The distribution currently in development, codenamed
"woody", sees updates literally every day.)

Does Mr. Peacock expect Debian to provide security updates for Debian 2.0,
1.3, 1.2, or 1.1?  Does he expect, say, Red Hat, to provide security
updates for 6.0?  How about 5.0?  4.2?  1.0?

Does Netscape continue to support Navigator 3.0?  2.0?  1.1?

--
G. Branden Robinson             |      One man's "magic" is another man's
Debian GNU/Linux                |      engineering.  "Supernatural" is a
branden@debian.org              |      null word.
http://www.debian.org/~branden/ |      -- Robert Heinlein

Date: Wed, 4 Oct 2000 17:12:50 -0700
To: letters@lwn.net
Subject: Security updates for Debian 2.1 "slink"
From: Rick Moen <rick@linuxmafia.com>

Dear Ms. Coolbaugh and Mr. Corbet:

Last week's letter from Dave Peacock raises the interesting question 
of whether the Debian Project erred in discontinuing (effective Oct. 30)
security updates for the former Debian-stable branch, 2.1/"slink", 
which was obsoleted by the new Debian-stable, 2.2/"potato", on Aug. 15.

At first glance, Deve's outrage seems justified.  His 2.1 machines
appear destined to be left in the lurch.  But this is a mirage, as can
be best seen by an example:

On August 1, Dave hasn't installed updates (including those for
security) in a while.  So, as root on each machine, he executes the
following commands:

apt-get update   #Gets new available-package lists from a Debian mirror
apt-get dist-upgrade #Upgrades all installed packages to current revs.
apt-get clean  #rm's package master files from /var/cache/apt/archives/

The packages retrieved are from the 2.1/slink branch, because on Aug. 1,
2.1 still bore the "stable" designation.  Any security fixes will be
among them, since they are merged into the mirror collections as the
Debian Security Team releases them.[1]

Let us say that, on August 16, Dave runs the standard update command
sequence again.  Because the Debian Project switched the "stable" tag 
from 2.1 to 2.2, the previous day, Dave's systems now receive a few more
package updates than usual, but not many.  He may not even realise that 
he has auto-upgraded to 2.2 -- the upgrader tools' default configuration
in /etc/apt/sources.list says "track stable", not "track 2.1".  Because
of Debian-stable's enforced package policy and emphasis on incremental
upgrading without downtime, this late-2.1-to-2.2 upgrade is
undisruptive, like prior ones within 2.1.

So, on Sept. 21, when he writes his LWN letter expressing outrage that
security updates for his 2.1 boxes wil cease in 1 1/2 months, those
machines have already been 2.2 for more than a month.

There _is_ ongoing security maintenance support for 2.1, you see:
It's called "Keep using the routine Debian update mechanism to continue
following 'stable', which recently moved past 2.1."

It's possible that Dave was unaware of Debian's maintenance tools, and 
has been retrieving security updates by hand.  (It is difficult
otherwise to understand his machines remaining on 2.1.)  If so, he'll be
pleased to hear about those tools, as they require less effort and
possibly even less bandwidth -- and yield markedly better results, e.g.,
minimising security-exposure windows by automatically implementing
even security updates whose alert bulletins you haven't seen.
I'll be glad to assist him (in e-mail) with any questions.

[1] For pre-release access, add this line to sources.list:
deb http://security.debian.org/ stable/updates main contrib non-free

-- 
Cheers,                   "Teach a man to make fire, and he will be warm 
Rick Moen                 for a day.  Set a man on fire, and he will be warm
rick@linuxmafia.com       for the rest of his life."   -- John A. Hrastar

Date: Thu, 28 Sep 2000 12:34:56 +0100
From: franck@nenie.org
To: letters@lwn.net
Subject: GPL/BSD: alternative prisonners' dilemma

The leading article on BSD/GPL in this week's LWN is not entirely fair.

You focus on the release/ not release decision _once_ the choice of using a
piece of open source software has been made, and changes have been
developed.

But will you reach the point where the decision you focus on has to be
taken? A more interesting decision game is when the commercial company
decides to use free software or not.

We have two players: the open source Developer and the commercial Company,
who cannot communicate with each other in the spirit of the prisonner's
dilemma game -- and practically because these decisions are taken at
different points in time by disjoint groups and are normally unrelated.

Thus, the Developer has two choices for their release: (1) use BSD, (2) use
GPL. Because the Developer has read your article (or does what the
mainstream open source movement does) they rationally choose the GPL.

The commercial Company has two choices, (1) exclude GPL software (prefer
BSD or commercial or internally developed software instead of GPLed) or (2)
also use GPL software. Because they know that the requirement to release
_may_ put their competitive advantage at risk, they rationally decide not
to use GPL software. They do that even if they are ready to release most
code they do, because it usually has nothing to do with their competitive
advantage, but they do not want to lose their future freedom to keep even a
single line of their own code private, and lose that freedom forever.

The outcome of the game is thus that the Company does not use the software
of the Developer so the open source community loses all the possible
non-competitive enhancements and the Company has extra effort to do if the
GPL software is better than alternatively licensed.  They both lose out in
a classic example of the prisonner's dilemma, a situation created solely by
the GPL.

The game works as well if the Company is replaced by someone who values the
freedom of everybody to do what their want with open code more highly than
the narrow definition of freedom in the GPL, or people who simply oppose
the GPL for ethical reasons -- be it the misanthropic nature of the GPL, or
whatever.

Of course, this game is as true as the one with the opposite result at the
later stage. The results of the sum of these games seem hard enough to
evaluate that they do not contribute much to the purely strategic question:
does the GPL produce more or better open source code than alternative
licences? Maybe we can keep on opposing or supporting the GPL on ethical
grounds.
 
-- 
Franck Arnaud ~ email: franck@nenie.org

Date: Thu, 28 Sep 2000 13:17:51 -0700
From: Marc Matteo <mmatteo@sacbee.com>
To: lwn@lwn.net
Subject: Your One Big Assumption  (GLP less business-friendly friendly)

In your editorial this week you make one *huge* assumption when you
write:

> A company that releases code under the GPL need not fear
> what its competitors will do - the risk of competing against proprietary
> enhancements is gone.

This assumes that all parties are playing by the rules.  The company
that releases code under the GPL still needs to fear that their
competitors will happily violate the GPL and take their GPLed code and
make it proprietary.  How would anyone know?  How would you check?

Cheers,
Marc
--
Marc Matteo
Online Technology Leader, sacbee.com
http://www.sacbee.com

Date: Sun, 01 Oct 2000 15:50:13 +1000
To: lwn@lwn.net
From: Dark Fiber <dfiber@mega-tokyo.com>
Subject: this weeks 'Is the GPL really less business-friendly' editorial

your a pro linux site, and thus pro gpl. why even bother
with the useless editorial of the gpl vs bsd license
stuck on the front page?

dont you think you are preaching to the converted?

an editorial is an opinion. i know exactly what i do
and dont expect from a linux news site. but i have to
wonder what you hoped to achieve with your editorial...

especially running it as item #1.


-Stuart George




-df

[ Dark Fiber <dfiber@mega-tokyo.com> Running FreeBSD 4.1 ]
[FAQ] Write Your Own OS
         http://www.mega-tokyo.com/os/
3x3 Eyes Fan Fiction Archive
         http://www.mega-tokyo.com/pai/
Sarien Sierra Emulator
         http://www.mega-tokyo.com/sarien/

From: "Mark Christensen" <Mchristensen@htec.com>
To: <corbet@lwn.net>
Subject: RE: "Is the GPL more business friendly than BSD style licenses?" 
Date: Tue, 3 Oct 2000 16:52:11 -0400

Though I agree this issue is enormously important as more and more people
depend on the production and maintenance of free software for their
livelihood, I don't think you have framed the question properly.

I doubt that the question you asked has a single answer. Different business
objectives lend themselves to different licenses.

As you mentioned one feature of the GPL is that it protects a company's
intellectual product from being incorporated wholesale into a competitor's
proprietary product, but this is not always an advantage.

I reciently had a conversation with a couple developers at SGI, and they
mentioned that as one of SGI's chief reasons for releasing a significant
amount of code under the GPL.

They believed that if they released their code under a LGPL, or Open BSD
license, competitors like Sun Microsystems, and to a lesser extent
Microsoft, would "steal the SGI crown jewels."

Obviously SGI's objective was not merely to keep Sun from using their
technology. They also want to support Linux as a competitor to Solaris, and
promote integration between Linux and Irix.  In this case, if SGI wants
their code integrated into the Linux kernel, the GPL is the only choice. On
the other hand, for stand alone software SGI's desire to support an
alternitive to Solaris would be served either a BSD or GPL license.

So, for SGI the choice of the GPL is the clear result of strategic decisions
about how to achieve several significant business objectives.  But for a
different company under different circumstances the same kind of strategic
thinking would lead to the choice of a BSD style license.

For this example, let's take a look at a fictitious network security firm.
They are primarily a professional services firm that audits the security of
large heterogeneous networks. They have created several security tools to
automate some of the work involved in large-scale security auditing on Unix
an NT boxes.

For our hypothetical security company these tools are not a primary source
of income, in fact they only sell their software to current clients as part
of a larger contract.  Nor are they worried about their software being
incorporated into proprietary products, because the software without the
services is not particularly valuable to a highly security conscious
company.

All in all, they would much rather have long standing audit/monitoring
contracts with fortune 500 companies, than sell a couple of hundred software
licenses.

In fact, they would see it as a great boon if their tools were included in
distributions of Solaris, Irix, Free BSD, and Linux, since this would be a
tremendous PR tool, as will as an easy path to a very tightly integrated
security contract with a wide variety of Unix vendors.

For this company, the use of a BSD style license is almost a forgone
conclusion.  And I expect that the ease of implementation across a variety
of platforms motivated the use of the BSD style license used for the
standard implementation of the Kerberos protocol.

In the past I’ve heard, and even repeated the argument that the GPL would
have protected the protocol from any attempt to co-opt the standard.  And in
one sense they would be right --the GPL would have set the bar higher.

But Microsoft’s “clean room” re-implementation standard would have negated
any of the obligations that come with re-use of GPLed code.  So, GPLing the
code would not have helped fight Microsoft (who had the resources to
re-implement) but it would have slowed the acceptance of the protocol by
smaller companies (who might clearly do not have the same kind of resources
as Microsoft).

My point in all of this is that the choice of licenses is very complex, and
a wide variety of issues need to be weighed very carefully.


And that, unfortunately, is why major license decisions need to be made with
input from lawyers, PR people, marketing departments, in addition to
programmers, and project managers.

From: <greyfox@paratheoanametamystikhood.net>
Date: Thu, 28 Sep 2000 01:33:07 -0600
To: letters@lwn.net
Subject: Privacy Foundation on :CueCat

The privacy foundation said:

    ... the :CueCat software attaches a unique user ID to each
    scanned bar code. This unique ID number, along with the bar
    code, is then sent back to Digital:Convergence Corp. computer
    servers. This feature could potentially allow the company to
    track the :CueCat scans of every consumer who registers for
    the service. 

To which Digital Convergence Replied:

    Yes, it's true, and I would have gotten away with it, too
    if it hadn't been for THOSE DARN KIDS!

Scoobie Doo references aside (The French demographic is probably
thoroughly confused by now) this is another damn good reason (As if we
needed another one) why it is not in our best interests to allow our
rights to reverse engineer a product to be infringed. This sort of
thing is already commonplace and will become more so if companies can
arbitrairly hide behind arbitrairly restrictive hardware and software
license agreements. As if being able to use a device that you
purchased in the fashion you choose with your hardware wasn't already
enough...

If you're one of the people talking to Al Gore or George Bush on MTV,
be sure to grill them thoroughly on this issue.

-- 
Bruce Ide                   greyfox@paratheoanametamystikhood.net
http://www.paratheoanametamystikhood.net

Date: Thu, 28 Sep 2000 14:41:37 -0400
From: Derek Glidden <dglidden@illusionary.com>
To: letters@lwn.net
Subject: IBM _really_ into Linux?


>From your "Linux and Business" page of Sept 28:

"Other companies announcing support for Red Hat Linux 7 and Red Hat
Network include Computer Associates, IBM Corporation, Lotus, Novell and
Tivoli."

Or if you want to be more literal:

"Other companies announcing support for Red Hat Linux 7 and Red Hat
Network include Computer Associates, IBM Corporation, IBM Corporation,
Novell and IBM Corporation."

I guess IBM really likes Red Hat Linux 7.  :)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
With Microsoft products, failure is not           Derek Glidden
an option - it's a standard component.      http://3dlinux.org/
Choose your life.  Choose your            http://www.tbcpc.org/
future.  Choose Linux.              http://www.illusionary.com/