Letters to the editor

Vendor Lock-In Misplaced

Sir:
 
With regard to your 4 November 2004 article Enterprise Linux: is it
broken? I feel that the authors of the whitepaper and the article
itself miss the point when they say:
 
    But today's Enterprise Linux is a lock-in play, designed to draw
    the customer into expensive subscriptions and single-vendor service.
 
Customers, especially companies, purchase computers in order to
achieve something with them. The number of companies who purchase
Linux for the purpose of "running Linux" are few and far between.
For example, our customers purchase Linux computers in order to run
tools on them, tools which cost amounts of money so large that they
make even RedHat's Advanced Server annual support rates appear
inexpensive.
 
You see, RedHat is not the vendor we are locked in to. It is the
vendors of these tools. And these vendors have decided that they
want a stable, predictable, relatively customer-fiddling-resistant
platform on which to run their products.
 
Sun gets this. When Sun goes talking to tools vendors asking them to
port their tools to Solaris 10, the answer is that the vendors don't
want a pile of money and free hardware to do a port. What they want
is customers at the front door demanding Solaris 10. And until that
happens, Solaris 10 support won't happen. And so Sun's main effort
in this space has been to generate interest in Solaris 10 as a
platform for this kind of work. Once Solaris 10 arrives and Sun's
new hardware is exercised, they may get somewhere with this effort.
 
RedHat is providing a service to these tool vendors: a stable,
predictable, relatively customer-fiddling-resistant platform on which
to build and support complex tools. That the cost of such a platform
is borne directly by the customer (and not indirectly) is irrelevant
-- it is merely a cost of using this tool, and one which does not
significantly reduce the resulting value gained by using this tool
instead of an alternative.
 
 
--
 /\oo/\
/ /()\ \ David Mackintosh | Public Key:
         dave@xdroop.com | http://www.xdroop.com/dave/gpg.html
         $ gpg --recv-keys --keyserver subkeys.pgp.net 4C032504
 

Comments (1 posted)

licensing suggestion

In this article:
http://lwn.net/Articles/103694/
 
Larry McVoy wrote a comment taking suggestions for changes in licensing
his BK product:
 
[quote]
  Rather than respond to all of your comments, which would just fan the
flames, let's try this.
 
It's easy for you to tell us we have done the wrong thing and perhaps
that's all you wish to do. I tend it act in good faith so I tend to
believe that some of you are genuine in your dislike for our choices. OK,
fair enough. So what should we have done? GPLing it wasn't an answer, BK
would be no better than Arch because there is no way to pay for not fun
work. Patents probably would have been a better choice for protection but
remember that I had a goal of helping Linus, and there was little chance
that he would adopt a patented technology.
 
I tried for years to explain our choices and it always ended up in a flame
fest just like this. So you tell me what we should have done and for that
matter what we should do today. I'm really interested in seeing what you
suggest, believe it or not, all of this fuss is because this is the best
way I could find that met all the goals, including the goal of helping
Linus.
[end quote]
 
I have thought about this for some time (as you can tell by the age of the
article) and I have (finally) had a thought. As it may pertain to other
potential products, I wondered about submitting it as a letter to the
editor if you believe it has some value. However, I would only wish to
do so if I may as an "anonymous coward". Anyway, here goes.
 
There are, of course, many issues between a proprietary license and a free
one such as the GPL. In a perfect world, Larry would of course be able to
release his product under the GPL and still charge for it as he sees fit,
but unfortunately not everyone would pay his company for usage as he would
like. While this modest proposal would not address all issues with this
conflict, it does, I believe, address two. They are:
 
+ What does a software user do if her proprietary software product is
     no longer supported? (And what happens to her data?)
 
+ When does the software user gain any ownership in her purchase?
 
My suggestion would be to add a license clause to whatever current
proprietary license is in use. It might be something called "Dated-GPL".
One example might be 2014-GPL. By seeing this mark, the software user
would know that a complete copy of the source code for that product was on
retainer with a trusted third party (i.e. the FSF, or a bank) and that the
source code would be released under the GPL when:
 
+ The date for that version of the product was reached, in the above
example 01 January 2014
 
Or
 
+ The software product is no longer supported (i.e. Software product is
dropped, death of the developer)
 
This of course would not be a perfect balance, but perhaps a better one.
It would allow companies to license their product in such a way as to
maximize their earning potential for that software product, yet ensure
freedom for end users after a limited time or in extreme circumstances.
 

Comments (11 posted)

Page editor: Jonathan Corbet