[KaVir]

Originally Posted by From a legal sense, you draw the line at verifying that you have the right to use anything you're using, if you're the type of person who cares

But logic dictates you have to take it on trust to a certain extent; you can't prove a negative. When you used the Avalon codebase, for example, you did so via a licence - but how could you be sure they hadn't included small amounts of material copyrighted to someone else? When other people worked on your Rapture engine, how could you be sure they didn't borrow a few little bits and pieces from elsewhere?

You can't - but there's no reason to believe that either of the above were the case. If a licence states it gives you permission to use X, and you have no reason to believe it doesn't, then I don't really see what else you can do - unless you write everything yourself.

Originally Posted by You know, that brings something else up I think: People are all over Medievia about plagiarism, but reading over the DIKU license, it strikes me if other people did in fact contribute to DIKU, the DIKU guys themselves are plagiarizing by claiming the work as theirs and not crediting the creators of it.

It's not plagiarism though, it's a contribution explicitly given to the Diku team for the purposes of being added to DikuMUD - and the contributors also get a mention in the credits.

[Anitra]

Originally Posted by We settled all of this by stripping out the stock areas, having all our areas written for us, and having all of our authors agree in writing to some standard boilerplate that grants us our needed rights as administrators. But we had the time and human resources to do so. What's the best way for a new MUD to handle this?

Most muds with any degree of quality have done the same. But it _is_ a very time consuming process, since good areas take a long time to produce.

For a new mud that still wanted to use a Diku derivate as codebase, I'd say there are three ways to go:

1. Don't open the mud for players until you have a unique world that is large enough to sustain a reasonable amount of gameplay. (The drawback to this is of course that it's more fun to work in a mud with players, and that it might be hard to attract competent help to a mud that is not open).

2. Start out with a selection of stock areas that fit your chosen theme, but gradually replace those with original areas. (As Valg already pointed out, there are some advantages to this, mainly that some players actually prefer stock, because they know their way around those areas. Also not all stock areas are crap, it's just that you have seen them too many times).

3. Use some kind of wilderness grid to get a fair size to start out with. These are quick to produce, the room descs can be set automatically by the code, and all you need to do is to add mobs and objects. Later the 'real' areas can be just connected to the grid gradually, as they get finished. (This is the solution I'd chose myself).

[the_logos]

Kavir wrote:

Originally Posted by But logic dictates you have to take it on trust to a certain extent; you can't prove a negative. When you used the Avalon codebase, for example, you did so via a licence - but how could you be sure they hadn't included small amounts of material copyrighted to someone else? When other people worked on your Rapture engine, how could you be sure they didn't borrow a few little bits and pieces from elsewhere?

This is typically covered by boilerplate warrants/representation clauses and indemnification clauses.

--matt