Subject: Re: [may be junkmail -pobox] Re: open source definition
From: kragen@pobox.com (Kragen)
Date: Wed, 22 Apr 1998 08:24:40 -0400 (EDT)

On Wed, 22 Apr 1998, Jonathan S. Shapiro wrote:
> The issue of source availability and support is not impeded by whether
> the original vendor makes a profit.  

I should point out that Cygnus, which has written much of the GNU
toolset, is making a handsome profit; RedHat, which has written and
GPLed a significant part of what's on the RedHat CDs, is profitable
(although I don't know how profitable; it doesn't appear to be publicly
held); Crynwr Software, which wrote and GPLed a number of packet
drivers a while back, made a nice profit on those -- I'm not sure what
their current status is; Cyclic Software, which includes some of the
most active developers of CVS, is quite profitable (and has their
yearly reports published on their web site).  Cobalt Microserver, which
employs one of the primary authors of the Linux TCP/IP code, looks
promising.

Your argument appears to be theoretically sound, but in the real world,
it doesn't seem to hold water.

> The second issue is profit making *on the software*.  On this issue it
> is my opinion that the current open source terms suffer from all the
> deficiencies of GPL.  The essential problem lies in the fact that I
> cannot charge you a royalty to redistribute my work.
> 
> It's instructive to ask who can and cannot make money using this
> model:
> 
> 	the publishers can make money
> 	the packagers can make money because the packaging is a
> 		difficult to reproduce tangible good
> 	the marketers and distributors can make money
> 
> In fact, the ONLY party in this scheme who can NOT make money is the
> party who makes the whole thing possible -- the original software
> author.  This is because the terms prevent the software author from
> getting royalties.

The software author can, in fact, make money; while theoretically, in a
friction-free economy, you may be correct that this should not happen
under GPL or other OSD-compliant licenses, the real world does not bear
this analysis out.

Also, it is not clear to me that the frictions that make it possible
for Cygnus and Cyclic to make their money will disappear with improved
technology.  I think they may actually be inherent to the nature of
software -- the people who write the software are in the best position
to provide support (especially including bugfixes).

I don't know about RedHat.

> Weirder still: under the current terms the software author can charge
> direct customers but not indirect customers for the code.  When you
> stop to think about it, this position is VERY odd, and flies in the
> face of the nature and structure of traditional distribution channels.

This has been commented on before.  Suffice it to say that traditional
distribution channels do not distribute "goods" that can be infinitely
reduplicated with nearly zero effort.

> As I have previously pointed out in this list, and everyone eventually
> agreed, this model precludes getting early-stage investment to build
> the initial product with.  

I don't think everyone eventually agreed.  I heard some rather heated
disagreement from Mike Tiemann at Cygnus, I believe, and I don't think
anyone actually said, "Yes, I think you're right, John."  Maybe you can
forward me some email I forgot.

> Here is an alternative model:
> [deleted]

Sounds interesting.  Reminds me of the way Unix was licensed in the
early '80s.  'Course, I wasn't around, so I might be wrong about that.

> Are you stuck if the vendor support is lousy but the product is not
> withdrawn?  No.  Everyone who owns the initial product can form a
> community and hack to their heart's content.

This may not be as true as you might think.  If you *do* include the
ability for licensees to exchange modified versions, modified versions
might become the standard version -- for example, a Netscape without
<blink> and without animated .gifs.  Otherwise, the inconvenience of
installing, patching, and building the source will likely restrict
modified version use to a minority of customers.

> > Publishing under a freely redistributable license does not
> > necessarily restrict the commercial success of your product, 
> > and can enhance that success.
> 
> This is a red herring, because you are talking about a different
> product.  You guys don't sell software.  You sell packaging and
> integration.

I would like to point out that this is true of all software companies;
in fact, it's almost an aphorism in the Silicon-Valley-pundit
industry.

> That's fine when someone else is giving the software away for you to
> package, but kindly be honest enough to admit that your scheme only
> works because you have thousands of unpaid laborers.

Two prongs:

One. Cygnus does the majority of development on the GNU toolchain.
RedHat has done the majority of development on major parts of Linux.
So it appears you are mistaken.

Two. It doesn't appear likely that the "thousands of unpaid laborers"
that built Linux are about to evaporate -- even without federal funding.

> > To be clear: while having access to the source is useful, it is the
> > complete control the user gets when the source code is combined with
> > a license that allows the user to do whatever he wants with the
> > software that creates the "benefit" our customers appreciate when
> > they chose Linux over the industry standard, but proprietary, OS.
> 
> I can get all that without paying anything to RedHat, using RedHat's
> own FTP site.  The right question is why do I pay for the RedHat
> releases? (Which, by the way, I do, though RH 5.0 nearly convinced me
> to stop).
> 
> Curiously, I usually buy the RedHat release *after* I download it and
> install it on a machine or two.  So why do I buy it at all?
> 
>     1. Payment for continuance of support.
> 
>     2. Continuability of installation - the upgrade issue.  I got
>        tired of re-installing Slackware.  [ This is where RH5.0 almost 
>        lost my future business. I lost several days to getting my
>        network services working again in a post-PAM world with no PAM
>        documentation worth mentioning. ]

You can do this with the ftpable RedHat release, too.

>     3. Convenience when non-networked machines are involved.  I work
>        in a lot of places connected only by modems, and downloading
>        the release in this circumstance is prohibitive.

You could burn your own CD, you know, or buy a $2 CheapBytes one
instead of a $40 Official RedHat one.

>     4. Continuing tool investment.  It's more than bug fixes; the
>        RedHat folks keep enhancing their tool base in ways that I
>        like.

They'll do that with someone else's money if you don't pay them, you
know, and the difference your monetary contribution makes is minuscule
-- perhaps half an hour of coding or debugging.

>     5. Somebody tested that release.  Mostly, they did a good job.

True also of the ftpable one.

>     6. Somebody architected the change decisions with an eye toward
>        upgrades that won't demolish my systems in place.

True also of the ftpable one.

> Basically, it's all futures.

It sounds like it's probably #1, if it's anything on your list.

Kragen