I'm wondering if anyone's ever considered doing anything with the GPL for their MUD codebases. I'm seriously considering it for my current project, though with a couple of revisions:

-Plug the "server" loophole. That is, if it's open to the public to play, even if you aren't releasing an executable, source code must be available.

-Removing the "...or any later version" caveat that means RMS can sign over your life if he wishes.

I'll admit, I am not a great fan of the GPL (even modified as I just mentioned), even though I use Linux regularly. However, for MUDs, it seems to be a very good idea for technical improvement. On the other hand, a lot of folks are very protective of their code.

Maybe an optimum license for MUD codebase maintainers would be similar to the old Netscape Communicator license. "You can change our code however you want, but you have to send US the changes, and we reserve the right to fold them into the base codebase if we so choose."

Yes, this is a disorganized stream-of-consciousness post, but it came to mind and I was curious.

Don't forget, the GPL prevents you adding any further restrictions, so while you could make changes the resulting licence would no longer be the GPL.

Personally I find the GPL poorly suited to muds. While a lot of software can benefit from being similar to existing software, the opposite is typically true for muds, where originality is one of the main selling points.

I realize it's no longer the GPL when modified, but I still call it the GPL for convenience's sake--much like how Linus Torvalds still calls the Linux kernel license the GPL even though it isn't quite.

Originality as a selling point--I am rather ambivalent on this. Yes, originality is a selling point. I agree. However, there is also the bit about overbearing imms and the like who may have a great codebase, but horrible player relations and a lousy buildworld. In such a case, isn't it better for players to be able to fork it, so to speak, and do a better job?

Originality as a selling point--I am rather ambivalent on this. Yes, originality is a selling point. I agree. However, there is also the bit about overbearing imms and the like who may have a great codebase, but horrible player relations and a lousy buildworld. In such a case, isn't it better for players to be able to fork it, so to speak, and do a better job?

In theory, perhaps - but in practice you'll find that most players think they can do a better job. By forcing mud developers to release all of their changes (assuming such a clause is even legal) you end up in a situation whereby no mud can ever stand out from the rest, because they all offer the same features. This in turn is going to dilute the playerbases, because many players will simply migrate to the muds where they can have the most power and/or control (something which is often far more appealing than fair staff).

I'd say the situation is pretty dire even now, due to the huge number of stock muds out there. But take away the ability for people to make muds that stand out, and you'd likely destroy much of the motivation for mud development - what's the point in creating cool feature X if it becomes yet another stock feature the moment you've finished it?

Such an approach might work if restricted purely to the engine itself, but I can't see anyone chosing to use such a codebase if it required them to release content.

In theory, perhaps - but in practice you'll find that most players think they can do a better job. By forcing mud developers to release all of their changes (assuming such a clause is even legal) you end up in a situation whereby no mud can ever stand out from the rest, because they all offer the same features. This in turn is going to dilute the playerbases, because many players will simply migrate to the muds where they can have the most power and/or control (something which is often far more appealing than fair staff).

I'd say the situation is pretty dire even now, due to the huge number of stock muds out there. But take away the ability for people to make muds that stand out, and you'd likely destroy much of the motivation for mud development - what's the point in creating cool feature X if it becomes yet another stock feature the moment you've finished it?

Such an approach might work if restricted purely to the engine itself, but I can't see anyone chosing to use such a codebase if it required them to release content.

I don't know. It might work if there was some kind of time limitation on integrating the work back into the original code base. And FWIW, yes this kind of restriction is definitely legal; for example, the APSL requires it (see the definition of "Externally Deploy.") In general though, I don't think this is a very good idea. IMO, the supposed 'problem' with MUD authors not releasing their source code is not nearly as large as some perceive it to be, for a few reasons:

1. There have actually been quite a lot of releases of large chunks of MUD code lately. Just check TMC for announcements in the past year or 2 - they're everywhere.

2. A lot of the stuff in a running MUD is really game specific and doesn't necessarily make a whole lot of sense to release outside the context of that specific game in the first place.

3. For the most part, game specific features are more an exercise in design than coding, so I don't see a great deal of benefit to requiring that to be released. It's simply not that hard in the first place. Core engine infrastructure is much more interesting from a technical perspective, but we've got plenty of that already.

4. Cynically, the code in question is probably not designed to be released anyway. That's a kind way of stating that it's probably a total hack job that's completely dependent on that specific fork of the engine. Code that "won't ever be seen by anybody" is often written to a much lower standard. Are you sure you want it?

As for forking a specific game to improve it (as already happens frequently - disgruntled staff carrying off their poorly managed source code and tossing it up on some $10/mo shell - you know how it goes) ... well, I'm not sure that's a good idea. As KaVir alludes to, players = Satan. I'm really not sure such a thing would cause anything but trouble.

I'd say the situation is pretty dire even now, due to the huge number of stock muds out there. But take away the ability for people to make muds that stand out, and you'd likely destroy much of the motivation for mud development - what's the point in creating cool feature X if it becomes yet another stock feature the moment you've finished it?

It's a good argument. However, when someone speaks of a "Stock Mud", I usually think "Ah, Midgaard. How refreshing." There are two main things that set one mud apart from the other: The features in the codebase, and the world that the players play in. Arguably, players care more about the latter.

For example, consider the two games "Baldur's Gate II" and "Icewind Dale II". They are more or less the same game engine (ID2 is a little bit more advanced), but BG2 is by far the better game.

It could be the same with a common mud codebase, but only if there were never a stock world for it.

It's a good argument. However, when someone speaks of a "Stock Mud", I usually think "Ah, Midgaard. How refreshing." There are two main things that set one mud apart from the other: The features in the codebase, and the world that the players play in. Arguably, players care more about the latter.

I think it depends on the player. You'll see some people looking for specific themes, but most seem to be looking for features or styles of gameplay. I would also argue that a well designed mud should thoroughly integrate the world with the codebase.

Quote:

For example, consider the two games "Baldur's Gate II" and "Icewind Dale II". They are more or less the same game engine (ID2 is a little bit more advanced), but BG2 is by far the better game.

However there is still a huge demand for completely different types of game. It doesn't matter what sort of world you slap over the top of the Baldur's Gate engine, it's not going to appeal to a Diablo II fanatic, let alone a hardcore Unreal Tournament player.

Quote:

It could be the same with a common mud codebase, but only if there were never a stock world for it.

It doesn't matter how much you change the world, if you're running (say) a stock ROM codebase then the game itself is still going to feel like a ROM - and there are many players who wouldn't want to play as a result.