[MUD-Dev] Source Code Release

[Travis Casey]

On Saturday, 14 February 98, Greg wrote:
> On Fri, 13 Feb 1998, Jon A. Lambert wrote:

>> I guess I would point to Sun's Java again.  Most everything you
>> describe is freely available on-line or downloadable with the exception of 
>> the source.  The VM source is obtained through a licensing fee.  (and there 
>> are many other examples - mostly from the Mac/Win/DOS/OS2 world) 

> What stops people who have obtained the source through a license, by 
> distributing the source to friends/associates, and through them, 
> propogated throughout the world?

Would you believe, honesty?  There are a few honest people left in the
world...  For the rest, fear of legal retribution.  Either of these
can work if you carefully pick those who you allow access to the source.
For example, Microsoft gave out access to large portions of the source
to Windows 3.1 to many companies, and shared the complete source with
IBM for some time.  You don't see it posted on FTP sites, but only
because MS was careful in who they allowed access.  Microsoft has
given AOL and other companies access to the source to Internet
Explorer so they can develop their own modified versions of it -- and
again, you don't see that source "propagated throughout the world."

Similarly, there are many other large software companies (such as Sun,
with Java) which have allowed others access to their source code.
When I worked with FSU's CS department, we had copies of the source
code to SunOS 4.1.3 and Solaris 2.5 that we had licensed from Sun.
These were very nice to have when software bugs and security holes came
up, since we could sometimes do our own temporary workaround or fix
until Sun came up with their own "official" one.

>> > I don't believe anyone would pay to register for a mud, when so many
>> > sources are widely available.
>> 
>> Forcing one to register the mud via a software key need not entail 
>> any demand for money.  

> What is the point of registration, then? 

Control.  If you can somehow "brand" the source with the software key,
you have a way of finding out where any "leaks" of the source to
non-registered folks came from.

Requiring a key to be able to use the source (via encryption,
perhaps?) could also allow you to put the source on an FTP site  You
can then let carefully selected people have the key, and still have a
convenient distribution mechanism.

> An additional point that I would like to make, is that binaries must have 
> access to the exact same libraries that were available when it was 
> compiled. This includes the same *version*, as well. (I have encountered 
> this probem before, on Linux. Perhaps I am doing something wrong 
> somewhere; releasing Linux binaries is not unknown, after all.)

Only if the binaries are dynamically linked.  A statically linked
binary will be larger, of course, but it will have the libraries it
needs already in it.  Alternatively, you can package the libraries
with the binary, and use filenames which include the revision -- thus,
your binary looks for lib.so.for.1.14 instead of just lib.so.for.

--
       |\      _,,,---,,_        Travis S. Casey  <efindel at io.com>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'   visit the rec.games.design FAQ:
     '---''(_/--'  `-'\_)       http://www.io.com/~efindel/design.html