Xref: utzoo comp.unix.questions:7676 comp.unix.wizards:9520
Path: utzoo!attcan!uunet!husc6!think!ames!amdahl!pyramid!prls!mips!dce
From: dce@mips.COM (David Elliott)
Newsgroups: comp.unix.questions,comp.unix.wizards
Subject: Re: Question about value of a source licence
Keywords: source licence, suns, money
Message-ID: <2439@quacky.mips.COM>
Date: 19 Jun 88 17:22:44 GMT
References: <229@dataspan.UUCP>
Reply-To: dce@quacky.UUCP (David Elliott)
Distribution: na
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 63

In article <229@dataspan.UUCP> kratz@dataspan.UUCP (Geoff Kratz) writes:
>What I need to know (from sites that have source licencing) is this: was
>the price of the source licence worth it?  I need to know if getting a
>source licence will actually pay for itself (ie: we got one and made
>$X millions :-) which paid for the licence in N months!) and any other
>advantages that having source will bring us, both short-term and long-term.

You really haven't provided a lot of background.

Mips has little choice in getting source licenses, since we are a Unix
systems developer selling Unix on our hardware.

If your company is developing software to run on Suns, you may want the
source for added documentation.  That is, if you see an interaction
that you are not sure of, or if you discover a case that isn't covered
by the standard system documentation, you can go and look at the
source.

If your company depends on the system to provide support for lots of
users, your systems programming staff may want the source in order to
provide fixes for problems, or to provide enhancements for the benefit
of your site.

If your company depends on the existence of the system to be assured,
source code may be a good idea.  That is, if you expect the systems
developer to go under next year (not likely in your case), you may want
the source so you can provide support to your present customer base.

So, a source license may be a good thing for your comapny.  On the
other hand, the presence of source code is kind of an "attractive
nuisance", and should be handled with care.  You need to understand
that Unix programmers love to hack the system.

If you find a bug, you may fix it locally, and your software may depend
on this fix.  Your customers, on the other hand, will still have the
bug and not be able to use the software product.

Local enhancements are a similar problem.  If your systems "hackers"
add a new option to grep and your software product contains a shell
script that uses this feature, it won't work outside of your system.

This is actually a more general problem.  Our first systems product had
a modified version of "install" that used a command called "printf",
which was not part of our product.  Since our systems administrator
dutifully "localized" every system shipped internally to the company,
every development machine had "printf" on it and worked just fine.
Luckily, later evaluation was done on virgin systems and caught the
problem.

The final problem is code stealing.  Programmers faced with
implementing something that already exists in Unix may grab a copy of
the source code and use it.  For example, if I needed a way to convert
an ASCII date to a Unix date, I might grab the set_date() and
year_size() routines from the date(1) source instead of writing the
code myself.  On the other hand, this means that I can never provide my
software source to anyone that doesn't have the same source licenses I
do.

All of these problems can be overcome by teaching the staff how to use
the source wisely.

-- 
David Elliott		dce@mips.com  or  {ames,prls,pyramid,decwrl}!mips!dce