Message from discussion Source code availability for freeware (was Re: cello)
From: hal...@dxal18.cern.ch (HALLAM-BAKER Phillip)
Subject: Re: Source code availability for freeware (was Re: cello)
Sender: hallam@dxal18 (HALLAM-BAKER Phillip)
References: <CArB8I.2HH@mentor.cc.purdue.edu> <1993Jul27.email@example.com> <MARCA.93Aug2201357@wintermu.ncsa.uiuc.edu>
Date: Tue, 3 Aug 1993 09:50:06 GMT
In article <MARCA.93Aug2201...@wintermu.ncsa.uiuc.edu>, ma...@ncsa.uiuc.edu (Marc Andreessen) writes:
|>In article <23kc38INN...@RA.DEPT.CS.YALE.EDU> griest-...@cs.yale.edu
|>(Tom Griest) writes:
|> There have been several legitimate needs mentioned for release of
|> the source, and if the burden of questions related to the source is
|> believed to be too high, then I think most asking for the source
|> would accept it with a no-questions asked policy. If need be,
|> there could be a network-based support group for those using the
|> source and wishing to share problems/solutions. Any "source-code
|> question" mail directed to NCSA could have a standard reply to
|> rtfm. As long as it is CLEARLY stated up front that there is no
|> support for source code problems, people will understand.
|>Some will. Many won't.
|>Releasing source is, practically speaking, equivalent to saying "We'll
|>support it, answer your questions, hold your hand while you try to
|>compile it, merge in any fixes or changes you send us, whatever"; if
|>we don't follow through, people will get upset. I am not
|>hypothesizing here. As for a generic warning label, people will read
|>it and then figure it doesn't apply to them and get upset anyway.
|>This is not as simple a situation as you may believe it to be. Please
|>be patient and understanding; we're working on it.
I really can't see why people are so keen to hassle Marc over the source
issue. There are often very good resons why source cannot be released.
In the case of BILBO, a system I built the sources cannot be released because
they are not in a conventional language, they are all written in languages
designed on a one off basis. Unless you have the synthesizer you simply
cannot compile them. Since the synth is currently only supported running on
VMS using a large number of pretty expensive software products there is
no way that real source can be released unless the synths are as well. Since
I am currently trying to sell one of them there are good resons why the
source is not likely to arrive either.
I could of course release the intermediate code which is ANSI C. However
from these it is quite easy to reverse engineer the synth which is a
valuable property. Also there is the danger that people will patch the
source to extend the functionality which then means that all the benefits
of using the synth (maintainability, validation) are lost.
Regardless of what NCSA do there will certainly be at least one Windows
browser in the public domain with source avaliable. Browsers are like busses,
you don't see any at all for weeks then five come at once. For quite a while
we had browsers for almost everything except for X-Windows. Then we got
Tk-WWW, Cello and Mosaic amongst others.
If people are good enough to let others use their code then those that
benefit from it should recognise that they are being done a favour. There
are problems arround viruses etc that exist with binary only distribution,
however these can be overcome. If people desperately need a browser that
they have full control over then the easiest solution is to take the common
code and write one. It really is not a big job. Most of the work is done
for you in libwww. Even the extensions in Mosaic such as images can be accesed
if you take the X-11 mosaic dist, one day they should be in the CERN dist.
The hard part is understanding the common code - I wrote a browser specifically
to do that, its almost certainly the easiest way at the moment (this will