December 1999
- Neural Networks as the AI system for a MUD? PartyG2816@aol.com
- Neural Networks as the AI system for a MUD? claw@kanga.nu
- Neural Networks as the AI system for a MUD? Marc Bowden
- Neural Networks as the AI system for a MUD? Lo, Kam
- Neural Networks as the AI system for a MUD? Marc Hernandez
- Neural Networks as the AI system for a MUD? Kræn Munck
- Neural Networks as the AI system for a MUD? Hans-Henrik Staerfeldt
- Neural Networks as the AI system for a MUD? PartyG2816@aol.com
- Neural Networks as the AI system for a MUD? Hans-Henrik Staerfeldt
- Neural Networks as the AI system for a MUD? Andrew Norman
- Neural Networks as the AI system for a MUD? Mik Clarke
- New member IronWolf
- Scenarios Chris Lloyd
- ColdStore J C Lawrence
- New AI Engine released Fabian
- New AI Engine released Steve Houchard
- New AI Engine released Bruce Mitchener, Jr.
- New AI Engine released Elysium
- AI's in MUDS and Online Gaming IronWolf
- AI's in MUDS and Online Gaming Matthew Mihaly
- AI's in MUDS and Online Gaming IronWolf
- AI's in MUDS and Online Gaming Ryan P.
- Garbage Collection Miroslav Silovic
- Capture of players. (was: Fair/Unfair? Scenarios) Kræn Munck
- Capture of players. (was: Fair/Unfair? Scenarios) J C Lawrence
- Capture of players. (was: Fair/Unfair? Scenarios) Chris Lloyd
- Biosystems (was Fair/Unfair? Scenarios) Richard Ross
- Biosystems (was Fair/Unfair? Scenarios) Philip Loguinov -- Draymoor
- Biosystems (was Fair/Unfair? Scenarios) Mik Clarke
- Biosystems (was Fair/Unfair? Scenarios) J C Lawrence
- Biosystems (was Fair/Unfair? Scenarios) Greg Miller
- Biosystems (was Fair/Unfair? Scenarios) Dundee
- Biosystems (was Fair/Unfair? Scenarios) Travis S. Casey
- Biosystems (was Fair/Unfair? Scenarios) Douglas Couch
- Biosystems (was Fair/Unfair? Scenarios) Marc Hernandez
- Biosystems (was Fair/Unfair? Scenarios) J C Lawrence
- Biosystems (was Fair/Unfair? Scenarios) Mik Clarke
- Ideas for dynamic worlds Nolan Darilek
- Ideas for dynamic worlds Chimera
- Ideas for dynamic worlds Ilya, Game Commandos
- Ideas for dynamic worlds J C Lawrence
- Ideas for dynamic worlds Nolan Darilek
- Ideas for dynamic worlds Joe Kingry
- Ideas for dynamic worlds David Morgan
- The GTS Library J C Lawrence
- Combat systems Neil Edwards
- Combat systems Kylotan
- Combat systems Kylotan
- Combat systems Chris Lloyd
- Combat systems J C Lawrence
- Combat systems Marc Spoorendonk
- Combat Systems Ben
- Combat Systems Raph Koster
- Metakit J C Lawrence
- Commercial Online Roleplaying Games (fwd) J C Lawrence
- Mud-Dev FAQ Marian Griffith
- Mass bannings (was The grass is always greener in the other field) AR Schleicher
- Game Balance: Statistical Analysis in MPORPGs Lovecraft
- Game Balance: Statistical Analysis in MPORPGs Koster, Raph
- Biosystems & simulation [RAMBLE] Ben Greear
- Souveniers Douglas Couch
- Souveniers Lovecraft
- Souveniers J C Lawrence
- Souveniers Raph & Kristen Koster
- Souveniers J C Lawrence
- Souveniers Raph & Kristen Koster
- Ideas for dynamically generated worlds Cynbe ru Taren
- Ideas for dynamically generated worlds J C Lawrence
- Balancing between anxiety and boredom (was Fair/Unf air? Scenarios (fwd) ) Sellers, Michael
- Online Migration and population mobility in a virtual gaming setting - Ultima Online J C Lawrence
- lockpicking Matthew Mihaly
- Optimized Object Storage Ian Macintosh
- Optimized Object Storage Sellers, Michael
- Optimized Object Storage Matthew Mihaly
- Optimized Object Storage J C Lawrence
- Optimized Object Storage Ian Macintosh
- Optimized Object Storage Ian Macintosh
- Optimized Object Storage Sellers, Michael
- Optimized Object Storage Ian Macintosh
- The Habitat Papers are missing J C Lawrence
- Waving Hands -- Debian's Spellcast for Linux J C Lawrence
- Waving Hands -- Debian's Spellcast for Linux Dan Shiovitz
- Waving Hands -- Debian's Spellcast for Linux Travis Casey
- Waving Hands -- Debian's Spellcast for Linux J C Lawrence
- Upload to ftp.kanga.nu J C Lawrence
- Farewell again Ilya, GC
- Telnet Protocol and Winsocks method
- Telnet Protocol and Winsocks J C Lawrence
- Telnet Protocol and Winsocks cg@ami-cg.GraySage.Edmonton.AB.CA
- Telnet Protocol and Winsocks Ilya, GC
- Telnet Protocol and Winsocks J C Lawrence
- Proper liscense for MUD source? Perhaps not GPL... (fwd) J C Lawrence
- Proper liscense for MUD source? Perhaps not GPL... (fwd) J C Lawrence
- Proper liscense for MUD source? Perhaps not GPL... (fwd) Rahul Sinha
- Proper liscense for MUD source? Perhaps not GPL... (fwd) SodaPop
J C Lawrence <claw@cp.net> wrote:
>3) Apache is not under the GPL. It uses a BSD derived license.
My mistake, you are correct.
>The GPL is not even close to a silver bullet.
That is the reason I have been tossing this idea around. The GPL
does not do what I would have liked it to do.
>> Since binaries are the most widely used/distributed form, anyone
>> intending to sell anything would likely be selling the binaries.
>> The GPL guarantees that the source is available along with the
>> binaries.
>
>Ahem. The GPL is infectious on "transmission" be that of binaries
>__or__ source code. Its also probably worth specifically observing
>the exceptions made for tools such as Bison and Flex that the
>products of these tools are not under the license of the tools so
>you can (for instance) produce a non-GPL parser with GPL tools.
>
>You may also wish to examine the definitional basis on how we
>(Project Trillian -- I was the project Manager) were and are able to
>operate a multi-company multi-developer project to port Linux to
>IA64/Merced/Itanium under NDA with no public disclosure of source
>without invoking the GPL virus.
I am fully aware of all the above. I have worked on similar projects.
Additionally, the special exceptions made for bison/flex that you
mention here have implications later in this post.
>> The issue I see is that mud servers are not like this - binaries
>> for the server are not distributed or sold, so there is no need to
>> release any changes you might make to the server. Any additions
>> to the server source that are made may be kept private, and
>> withheld from the development community. As such, the GPL would
>> not work well on mud servers.
>
>> So what is distributed? The game itself, which people connect to.
>> I believe this should be the condition for releasing source, not
>> the distribution of binaries. (Yes, it's probably on questionable
>> legal grounds. No, for the sake of this discussion, I do not
>> care.)
>
>Translation: Enforced public speech. To an extent you are demanding
>that all efforts which touch this product are effectively done "in
>the public interest" or at least, "freely available to public
>scrutiny" at the source level.
No, you are perfectly free to take the code, make your own changes,
and play it all by yourself in your own home. You can make whatever
changes you like to it, so long as you dont release the game for
others to play. You open it for others? You release your changes.
(Note that a more solid definition of publicly available would have
to be made here, to allow teams of developers to develop in private,
and to prevent people from saying 'Its a private club, that means
not publicly available'.)
> If you do anything, and you let anyone else see it, you *HAVE* to
>let everyone see it.
>
>Outside of the fact that this violates the OpenSource definition (as
>does the GPL arguably enough), many will find it excessively
>invasive for development purposes, time-to-market, press control,
>etc.
Why would this liscense be invasive for any of the above reasons?
You don't need to release it until it's public, if its not public,
you can sit on it for all eternity if you like.
> The 6 month time lag doesn't fix this as it merely attempts to
>hide the problems by providing an alibi that most can escape under
>without addressing the central concern.
What is your central concern here? Or do you just hate the idea of
GPL style liscenses in general?
The six month time lag was intended to give those who add to the
base something a little like patent protection - you make the
modification, you get to use it exclusively for a short period of
time. I am not convinced the 6 month lag is a good idea for a
variety of reasons, but I felt it was appropriate to bring up.
>My view? I take the side of free speech. A pivotal quality of
>"free speech" is the freedom to communicate only when one wishes to.
>(FWLIW reading the supreme court's arguments on the State's right to
>mandate its citizen's speech is more than revealing) You are
>suggesting the removal of that freedom by mandating compulsive
>speech without giving anything back to me for the loss of that
>"right" -- something not even the State (in most of the Western
>World) does.
I am suggesting nothing of the sort. You have the perfect right to
sit on your changes for as long as you want. You additionally have
the right to write your own code base, or use one without this form
of liscensing.
However, if you make the game public, you make the source for that
game available. If your modifications went into the code base for
that game, those must be made available as well.
I really see this as being very similar to the GPL, with the only
real difference being the definition of distribution: in this case,
distribution also includes making the game publicly available.
> Contracts, and licenses, need to practice fair exchange -- to give
> as much as they take.
>
>My source is mine. Period. I choose the license I use for
>releases. (I presume that you've read Linus' statements on this
>area? If not see the Linux Kernel or BitKeeper License list
>archives) That license may be affected or even defined by the
>license on the code I started with, but whether or not I release,
>and when and how, are my decisions, and nobody elses.
If I release a code base under this liscense, it will be a very
long time before I get as much back as I put into the original
base. That is the fair exchange issue I was talking about.
And yes, you are perfectly welcome to take your changes and do
whatever you like with them. But if you make changes to a base
covered by this liscense, you are bound by that liscense. This
is no different from the GPL.
>> I'd like to forward the idea of a liscense where making the mud
>> publicly available for play requires the source code for the mud
>> to be available.
>
>For the purposes of this license, how do you distinguish between
>server source (say socket handling) and softcode (defines the game
>world)? How about the case where there is no soft code -- the
>entire MUD is written in the C/Java whatever and there is no
>LPC/ColdC/TinyCode equivalent? How about the other side, where the
>hard coded kernel is very small, offering some basic network socket
>handling and a soft-code langauge atop which everything else is
>built (ala CoolMUD. PerlMOO, etc)?
You distinguish the same way that bison/flex do. Data files created
independent of the code base are not covered by the liscense. Data
files created by the code base are also not covered. A small amount
of work could make proper definitions which would allow this.
>> Presumably a well designed code base would allow the bulk of the
>> game to reside in data files not covered by the liscense, which
>> would prevent people from copying and stealing entirely someone
>> else's game.
>
>This is not even close to a given.
Depends on the code base. Even on a diku, however, custom areas
can mean a lot.
>> This seems to me like an appropriate way to release source. It
>> allows people to collect money for the game, even make it
>> pay-for-play if they desire - but it forces anyone who does so to
>> give thier changes back to the community.
>
>How about non-OSD compliant licenses like the SCPL?
No, I fully believe in liscenses like the GPL, because if I want to
release something to the world, I don't want anyone to have the
right to take it away. If you want to use GPL code as a base, you
GPL your changes. If not, go elsewhere.
You claim that this is a free speech problem - well, I claim
otherwise. As a developer, if I have put a number of years into
a code base, I get to decide the liscensing. I get to declare what
is proper use of the code, and what is not - and I get to set said
restrictions on its use.
In this case I would attempt to set the restrictions such that the
code could never be taken away from the community, or blatantly
abused by someone who does not care about the community. A viral
liscense, like the GPL, does what I would want - but because of the
way mud servers are used, a few modifications would have to be made
concerning what constitutes distribution.
I sense a GPL/BSD holy war coming up, so let me attempt to head it
off at the pass: I don't care which is more or less free/open. I
do, however, care that certain things not happen to code I write,
and in this case a viral liscense is what I wish to discuss.
-dennis towne
- Proper liscense for MUD source? Perhaps not GPL... (fwd) Ben Greear
- Proper liscense for MUD source? Perhaps not GPL... (fwd) Christopher Allen
- Proper liscense for MUD source? Perhaps not GPL... (fwd) J C Lawrence
- Proper liscense for MUD source? Perhaps not GPL... (fwd) Christopher Allen
- MUD source licensing: beyond GPL? (fwd) J C Lawrence
- MUD source licensing: beyond GPL? (fwd) Matthew Mihaly
- Classes and Races and more (a BIG list) (fwd) J C Lawrence
- Originality/Points of Reference (was Classes and Races and more (a BIG list) (fwd)) Richard Ross
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Justin Rogers
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) Justin Rogers
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Christopher Kohnert
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Matthew Mihaly
- Collecting ideas for a MUD server... (fwd) Jon A. Lambert
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) Wesley W. Terpstra
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) Wesley W. Terpstra
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) Greg Miller
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Collecting ideas for a MUD server... (fwd) Rahul Sinha
- Collecting ideas for a MUD server... (fwd) J C Lawrence
- Originality/Points of Reference Ian Klimon, Esq.
- Job Openings - Mud Engineering Christopher Allen
- PGP player certificates (was: collecting ideas...) Wesley W. Terpstra
- PGP player certificates (was: collecting ideas...) David Bennett
- Re[4]: The grass is always greener in the other field Travis Casey
- Re[4]: The grass is always greener in the other field J C Lawrence
- Re[4]: The grass is always greener in the other field Adam Wiggins
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) Wesley W. Terpstra
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) J C Lawrence
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) Marc Bowden
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) Greg Miller
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) cg@ami-cg.GraySage.Edmonton.AB.CA
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) Hans-Henrik Staerfeldt
- Two threads forced to one CPU? (was: Collecting ideas for a MUD server...) cg@ami-cg.GraySage.Edmonton.AB.CA
- PGP confusions hopefully resolved (was: collecting ideas ...) Wesley W. Terpstra
- MUD-Dev digest, Vol 1 #237 - 9 msgs Dr. Cat
- MUD-Dev digest, Vol 1 #237 - 9 msgs J C Lawrence
- MUD relevant references (was: The grass is always greener...) Ola Fosheim Grøstad
- Re[6]: The grass is always greener in the other field Travis Casey
- Embedded languages, object persistance... ack. Joe Kingry
- Embedded languages, object persistance... ack. cg@ami-cg.GraySage.Edmonton.AB.CA
- Embedded languages, object persistance... ack. Laurent Bossavit
- Embedded languages, object persistance... ack. Kevin Littlejohn
- Embedded languages, object persistance... ack. J C Lawrence
- Embedded languages, object persistance... ack. J C Lawrence
- Embedded languages, object persistance... ack. Jay Carlson
- Embedded languages, object persistance... ack. Jay Carlson
- Embedded languages, object persistance... ack. J C Lawrence
- Embedded languages, object persistance... ack. icecube@ihug.co.nz
- Embedded languages, object persistance... ack. Kevin Littlejohn
- Storing tokens with flex & bison Christer Enfors
- Storing tokens with flex & bison Rahul Sinha
- Storing tokens with flex & bison J C Lawrence
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Christer Enfors
- Storing tokens with flex & bison Ola Fosheim Grøstad
- Storing tokens with flex & bison J C Lawrence
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Kevin Littlejohn
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Phillip Lenhardt
- Storing tokens with flex & bison Dominic J. Eidson
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Chris Jones
- Storing tokens with flex & bison J C Lawrence
- Storing tokens with flex & bison cg@ami-cg.GraySage.Edmonton.AB.CA
- Storing tokens with flex & bison Ola Fosheim Grøstad
- Storing tokens with flex & bison Per Vognsen
- Storing tokens with flex & bison Christer Enfors
- Storing tokens with flex & bison Chris Turner
- Storing tokens with flex & bison Christer Enfors
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison Christer Enfors
- Storing tokens with flex & bison Jon A. Lambert
- Storing tokens with flex & bison J C Lawrence
- Storing tokens with flex & bison Greg Miller
- Storing tokens with flex & bison J C Lawrence