Article View: gnu.misc.discuss
Article #72781Re: Too Good to be True?
From: Kee Hinckley
Date: Sun, 12 Jan 1992 23:28
Date: Sun, 12 Jan 1992 23:28
119 lines
7900 bytes
7900 bytes
In article <kmqrhmINN7s4@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>In article <iRNaeB6w164w@mantis.co.uk> mathew@mantis.co.uk (en font terrible) writes:
>>If you link your programs with a library under the GLPL, you have to supply
>>object code for your programs.
>
>So what's the problem with this? How do you lose by allowing your
>customers to relink your program with a new version of a new or modified
>version of a GNU library?
First of all, I'm sure not all these costs apply to all companies, although
some do, but you asked, so I'll give you a real-life example.
First we have two options. We can either include the linkable versions
in all distributions, or we can provide it upon request.
a) Provide with standard distribution
This doubles our distribution size. In the case of floppy
distributions that means we need to include twice as many
floppies. We also have to expand the documentation and explain
how to link (if they want to). On Sun platforms we link with
the 1.0.3 library, but the compiler includes some symbols that
are only resolved by the 1.1 library, so we'd have to figure out
how to include a piece of the Sun library in linkable form without
upsetting Sun. The increase in the size of the floppies will affect
our SCO distribution since we are already at the max for the size
of the box, so we'll have to have the box inset redesigned and
trash the ones we have in stock. All of that costs a fair amount
of money. None of which is reimbursable.
b) Provide on request
This could be a freebie - most of our customers don't even have
a *linker*, let alone want the binaries. But we need to be prepared
to handle calls requesting it, we need to have tapes, disk space to
hold the distribution for each platform and we need to allocate time
to do the duplication. If the volume of requests is really significant
we'll have to pay our manufacturing company to do the work. On the
bright side, we can charge for all of this. On the downside, it takes
a time to set this all up, and we're currently in a position where time
is far more valuable to us than money.
Now in both cases there are some other costs. Not the least of which is support.
It's all very fine to give a customer some stuff and a readme file, but it's
rarely that easy. If they get it from you they want support. Furthermore now
we have a significant problem with support. When a customer calls and has
a problem we have to ask whether they've relinked with a new version of of
whatever GNU utility. If they have then we have no way of knowing what one
or what version or how good it is. We don't know if they introduced a bug
themselves are they're dealing with one of ours. If they send us a core dump
we can't use it. But none of this has ever deterred a customer from complaining.
Furthermore, if the sysadmin relinks the stuff and it gets bugs, the end-users
won't know this, they'll just think it's our shitty product. So there are a
lot of risks there.
Now I get more specific to our case. When we started out we got initial financing
from several companies in return to source rights and reduced royalties. Those
companies have the right to source to new versions of our product. We cannot
give them source which restricts their use of our product. Using the LGPL would
do exactly that. We could of course attempt to renegotiate, but that would
involve considerable legal expense and is not likely to succeed. So we're stuck.
The real bummer here is that I really would like to use a particular piece of
GNU code, in particular I've been looking at different versions of malloc. But
there's no way I can justify going through all of that mess just to get a new
version of malloc. Because the cost above is static, no matter what I use.
So you asked. And mind you, I don't even think the LGPL is that onerous, but
that's the state of things.
Now let me back off a second. If we could assume that we didn't have the
legal problem, here's an alternative which I *think* many people currently
using the GPL would find acceptable (tell me if I'm right, tell me if I'm
wrong). What if there were a license which specified that any changes to
the code covered by the license must be fed back to the original author.
There's stuff to be ironed out of course. And there are potential loopholes,
but I think the basic concept is a lot more friendly to all involved. I have
two goals here. One is to get the best software available to the customer.
The second is to continue to enhance the state of software development by
feeding back and enhancing the reusuable components. GPL does the second but
I don't believe it does the first.
>Not everyone. The customers of developers who use GNU software would lose,
>because they wouldn't get sources. In the case of developers who use GNU
In my experience customers don't want source, they want working software.
The market is changing, Unix customers are no longer as technical as they
used to be. There's a reason that Unix providers are unbundling the compiler
tools, and it's not because they've just all randomly gone mad. Yes the
source can be useful to some, it's insurance. But for the most time it's
insurance that people dont' care about.
>Well, the assumption underlying the argument is that developers are willing
>to use the GNU software. All you have to do is adopt their philosophy of
>code sharing and a large body of software becomes available to you, with
>full sources and copying privileges.
>
>Remember, one purpose of the Free Software Foundation and the GNU project
>is to get people to adopt this philosophy. Software development is a means
>to this end.
Funny, I just had a large argument with someone who was using GPL over
this philosophy, and he claimed that it was a strawman and hardly anyone
shared it. No two people...
>If the purpose of charging for each copy is to recoup your costs, what
>happens if you sell more copies than you expected; do you stop charging or
I'm not sure where you get this idea. Capitalism isn't based on logic, it's
based on what the consumer will pay. But in any case, no, you continue
to charge in order to finance further work to enhance the product and
build new ones. If you believe that's wrong, and that software should be
free and we should all follow Cygnus's example, then as I say, go for it
with GPL. I even think it's a nice ideal, but I wouldn't apply it just
to software. It's even better if applied to basics like food, clothing
and heat. But practically speaking we haven't figured out yet how to
make that kind of society function. When someone comes up with something
that sounds viable I'd be delighted to hear it. Until then I'll continue
to work inside the existing system.
--
Alfalfa Software, Inc. | Poste: The EMail for Unix
nazgul@alfalfa.com | Send Anything... Anywhere
617/497-2922 | info@alfalfa.com
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
Technical Details
Message-ID:
<1992Jan12.232801.5330@alphalpha.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!sun-barr!cs.utexas.edu!sdd.hp.com!think.com!spdcc!tauxersvilli!alphalpha!nazgulReferences:
<iRNaeB6w164w@mantis.co.uk> <kmqrhmINN7s4@early-bird.think.com>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1025b4,e71af1b1f401c58d X-Google-Attributes: gid1025b4,public X-Google-ArrivalTime: 1992-01-12 23:08:18 PST Path: arc1-ca.pugleaf.net!sparky!uunet!sun-barr!cs.utexas.edu!sdd.hp.com!think.com!spdcc!tauxersvilli!alphalpha!nazgul From: nazgul@alphalpha.com (Kee Hinckley) Newsgroups: gnu.misc.discuss Subject: Re: Too Good to be True? Message-ID: <1992Jan12.232801.5330@alphalpha.com> Date: 12 Jan 92 23:28:01 GMT References: <iRNaeB6w164w@mantis.co.uk> <kmqrhmINN7s4@early-bird.think.com> Organization: asi Lines: 119