[MUD-Dev] Re: My vision for DevMUD
Jon Leonard
jleonard at divcom.slimy.com
Wed Nov 4 14:13:57 CET 1998
On Wed, Nov 04, 1998 at 03:59:13PM -0500, Darrin Hyrup wrote:
> At 07:16 AM 11/4/98 -0500, James Wilson wrote:
> >On Wed, 04 Nov 1998, ApplePiMan at aol.com wrote:
> >>PD assures availability and "free-ness" much more than LGPL or BSD. It
> >>removes all restrictions on usage, and in doing so *ensures* anyone,
> >
> >sorry, you're missing the point here. PD makes it possible for a commercial
> >entity to fork my code, by making some super modifications and not releasing
> >them in source form. Then the free version of my code is killed by the
> >commercial version. This is the central reason why people use Gnu-style
> >licenses.
I think there are a few scenarios that we might worry about.
1) Someone takes DevMUD code and builds a commercial service on top of it.
2) Someone starts selling MUD servers consisting of derivitive DevMUD code.
3) Someone branches the DevMUD project and becomes a better source for
free MUD server source code.
Have I missed any? These don't look like problems to me.
In case 1, it means that there is another commercial MUD, possibly an
improvement over existing ones. This sounds more like a benefit than
a bad scenario. Also, it would take an unacceptably strong license
(significantly stronger than GPL) to stop this.
Scenario 2 means that there will be a market for quality MUD servers, rather
than just a market for well run MUDs. Sounds unlikely to me, and I'm willing
to sacrifice a little code if it proves that there's real money to be had
for advancing the state of the art in MUDs.
Case 3 isn't very different than the current plan, with someone else as
coordinator. I think that anyone skilled and determined enough to do that
is probably on MUD-Dev already, and would have volunteered to lead. That,
and cooperation is more effective in open source anyway.
In any of these cases, we will _still have_ the original DevMUD sources to
play with. Nothing can be taken away from us here.
> I think we're missing the point a bit here... is the intent to create a
> MUD or to advance the state of mud technology and provide a map for others
> to follow to get there with us? If its just to create a MUD, there are
> plenty of tools out there one can use to do that, and compete with other
> commercial services doing the same thing. if its for education and
> exploration, then it is expected (and intended?) that others will use our
> code in their own future products.
That's my view. I'm even one of those who might build proprietary code
on top of the standard distribution, once we _have_ a standard distribution.
I think that running MUDs really should have some unreleased parts, too.
Starting with the really obvious things like password files, and extending
to things like code that would make quest solutions obvious: The sort of
stuff that helps give a MUD its unique character.
Trying to come up with a licence that requires release of this sort of
thing would be counterproductive.
> In any case, the license/release arrangements for the core and basic
> modules should not really be at issue here... anyone who uses this system
> will probably have to use them in one form or another anyway. Its the
> supplementary modules which you should be more concerned with, and as an
> author you could protect those in your own way, since they are not really
> part of the server core itself, but are one of many plug-ins for it.
> Someone who would be making a commercial version of our server is going to
> have to create a customized environment (mudlib/module suite) to be
> competitive, and if they chose to use your offerings of such components,
> then they would be required to abide by your restrictions.
> I think we are really only discussing the main core and low-level modules
> in terms of license/copyright... 3rd party modules and add ons will be a
> completely seperate issue, and that should be up to the implementor(s) to
> decide.
Is there anyone who can't live with this arrangement? If no one speaks up,
we should probably move on to more productive discussions soon.
> So, by keeping the core PD, we open the game up to a much larger potential
> audience... many of which are likely to contribute more back to the project
> as a whole.
That's my hope. Keep in mind that bug reports and feature requests can be
valuable contributions too. The largest possible audience is a benefit to us.
Jon Leonard
More information about the mud-dev-archive
mailing list