I'll give you two examples that I have seen the code for.
1) Ed Snible's Make Zones Fast is a stand alone area editor that runs on Windows which reads and writes Diku, Merc, Envy and ROM zone and area files. It's licensed as a derivative work because it contains the same code those muds use to read and write their files.
2) Nick Gammon's Area Editor is also a stand alone editor that runs on Windows that can read and write Rom and Smaug files. It is not licensed as a derivative work because it contains no code from any of those muds.

I think both are licensed correctly.

I don't think it would be a violation. The payment model is irrelevant. If the software is licensed separately and it's valid licensing then obviously you can sell that software. I'm pretty sure diku license never mentions requiring you to allow connections from more than one client.

While I agree with Runter, at the time of releasing the client I thought it would violate "the spirit" of the DikuMUD license if I tried to push the client via the server in any way (conflict of interest). So there's never been any attempt to restrict what clients people use to play the game. The GUI app for iPhone sells only "perks" provided outside the realm of the DikuMUD code, i. e. eye candy and a touch UI that makes mobile play easier. It is clearly stated that the client connects to one server only and it is also clearly stated that the server can be accessed for free with multiple other clients. Because of the above, I don't see how my client is any different from a commercial MUD client for the desktop.

My protocol snippet is more like a specialised library, it should be usable by pretty much any mud written in C (although multithreaded muds would need to change the code to make it thread-safe).

It comes with four install files - Merc/GodWars, SMAUG, TBA and "generic". The first mud to test it for me was a GodWars mud, so I wrote the first set of instructions for them. I also pitched the snippet to Realms of Despair, and created the SMAUG instructions for them. A couple of TBA developers were very interested in my snippet and asked for some instructions for their codebase, so that's where the third set came from. The generic instructions explain in general terms what and where you need to change things, without making any assumptions about codebase.

I did try to persuade an LPmud owner to install the snippet, but he wasn't interested, and I'm not familiar enough with LPmud to attempt writing installation instructions myself. However Bryantos did write a patch for using the snippet in SocketMUD, so it's not just DikuMUDs that are using it.

Several of the other mud snippets I've written in the past are also codebase-independent - to the point that some of them can actually be compiled and executed as standalone programs.


It's somewhat grey. You're selling a perk that applies specifically and exclusively to your DikuMUD - on the other hand, your mud doesn't offer your client anything that it doesn't also offer to other clients. Someone could create exactly the same client themselves, without requiring any special support from your mud.


I would consider that a licence violation, yes. Players are required to pay $10/month to play your DikuMUD - the mud would actually be blocking people who don't pay you. The Diku team have said it's fine to sell things like mugs and t-shirts, but that doesn't mean you can automatically block players who don't buy a t-shirt after their first month of play.

I mean you could write a simple script that deletes every pfile at the end of the month, and then add a "save" button to your website that allows players to remove themselves from the current month's deletion list. That would be simple to do, and the script wouldn't be bound by the Diku licence - but if you started charging players a $10 "service fee" each time they pressed the button, you'd effectively have a monthly subscription payment model, and I would consider that a violation of the licence.

Or you could compare it with the debates in the past where someone points out that they own the copyright to the area files they create, which is fine up to that point…but then they further claim that because they created the Ubersword of Ultimate Power, they're allowed to sell in-game copies of it to their players for $100 each. While you certainly own the copyright to areas you create, the in-game representations of those areas still fall under Diku licence.

Does it read the DikuMUD file format? If so, then it's a derivative work, since if that file format were removed it wouldn't function.

The file format is outside the scope of the Diku licence.

Interoperability does not imply derivativeness.

If I state in my license that the end user must be openly christian you'd have to agree to that in order to use the software, and I'm sure some jesus freaks would tell you to cease and desist if you'd post somewhere confessing to be a Jew or Atheist.

The Diku authors stated you're not allowed to make money of any part of DikuMUD, which clearly is meant to include areas that go beyond the source code. But as I said, I personally couldn't care less.

I'm well aware that I can't sell my area editor - as in compiled and working application - since it's built on top of a Diku derivative, and this Diku derivative has a lot (around 30%) of Diku-licensed code in it.

But what about my area editor - the code I have written? The custom widget I needed and have written from scratch or the glade file that is an xml file keeping all information about windows, widgets, their attributes, placement and so on?

The code is in a separate folder and can be seen as a module like the modules that KaVir was talking about earlier. The code, I believe, doesn't have a single line of code that would be taken from the Diku code and it operates on structures of the Diku derivative, not the original Diku mobs, rooms, etc.

Doesn't matter, once a derivative, always a derivative, and all derivatives are still derivatives.

I think the more interesting point here is that you're merely interoperating with file formats, not that you're working on formats derived from some other format.

To get rid of any Diku licence while writing an editor, build your editor first that wont use any of diku structure (quite easy anyway) and only use a filter at the end to write the file.
Then only the filter will be a derivative work, and you can sell your editor since the filter by itself is totally useless. The filter though will be a derivative work, but hell if you care.

I don't see why. To me, the only interesting thing is the state of the code I have written. The whole folder of code. The separate module. The 5000 lines of C code with 0% Diku-licensed code in it. That's what I find interesting.

Rarva.Riendf, thank you for your suggestion, but as you can read above, I don't care about being able to sell anything. What I care about is the state of the work I have done. And no, 1) writing an editor from scratch is difficult 2) having an editor built on top of your MUD has the great advantage over standalone applications, because that way the editor is always up to date.

The only areas that the license can possibly cover are the files that come in a DikuMUD distribution. Any work that contains any part of those files is a candidate for derivative status. Any work that does not contain any of them, well, I don't see how that can be derivative regardless of its purpose.

The license does have specific terms of use, such as what to show under "credits", how to distribute derivative works, etc. The CircleMUD license also contains much-needed details about donations, in-game perks etc. Normally, as long as one is in compliance with those terms, one would be confident that they're good to go. However, the original Diku license also has that wonderful "no profit from any part in any way" line. At this point, you have to decide that "part" means the actual files in the distro, or else you'd have to enroll a legal expert (or an expert in metaphysics) to step in and rule on any cases not specifically addressed by the license. I have neither at hand so I will (sensibly) assume that the license applies to the files it comes bundled with, and not the "areas that go beyond."

Applying that to the clients case: Nowadays, if a program wants to limit interoperability (thanks, DH), it talks to the rest of the world using a limited API, which often carries its own terms of use. Obviously, the DikuMUD license makes no attempt to restrict client use, such as e. g. saying "You can only use free clients to connect to a DikuMUD server," nor does the code itself discriminate against clients. If it did, then there wouldn't be any commercial MUD clients, and I most likely would not have made two of them myself (I need a trickle of money to prove to my family that this is a hobby and not pure madness :).

While the world file formats are part of the distro, the license doesn't say anything about restricting interoperability of those formats with other products. So, Vigud's area editor is well in the clear, I think.

By the same token, the license doesn't say that any C code that will work together with the main DikuMUD code cannot be sold for profit by its author (even if it did say that, it would just be crazy). So, if KaViR wanted to charge for his GUI snippet, I believe he could.

The license specifically forbids redistribution of derivatives for a fee, which is well within its powers to do, since derivatives contain parts of the original distro.

You entered the world of viral licenses with Diku, it is kinda like the GPLv3:better not touching it even with a ten foot pole if you dont want to be assraped by Stallman like zealots hehe.
I differ with the point 2 though: an editor can be agnostic of the output file. If your mud need another option, you will put it in the editor anyway. So the graphical editor itself can be totally standalone and agnostic of the endfile, and all the specific work considering your mud can be in the output filter (it is a hard work yes) but that is why you always separate graphical input and data. Need another exit flag in the editor ? -> need to update both graphical editor to show it, and output filter to save it anyway. So they will stay up to date with your mud, standalone or not.

You predicated your statement on the notion that it's ok because you're working on structures of a derivative and not the original. But that is completely irrelevant when discussing licensing issues. What is relevant is that you are dealing with files you interoperate with, not how many degrees of derivation there are. The structures of the derivatives are covered in the same way (or potentially with additional licenses) as the original. In other words, they are at least as licensed.

I didn't. I pointed it out only because it's a fact and you used it as an excuse to ignore everything else what I said in that message. Please try to answer the rest and maybe you'll understand me better.

Actually this is completely irrelevant. The code that reads and saves files is not included in my editor. My editor doesn't know about file format, files, loading or saving. My code doesn't do any of those things, my code creates GUI, is responsible for the application's logic and operates on data structures that it sees as already loaded into memory.

Ditto. A file format cannot be copyrighted.

For somebody who basically told me I was being overly literal, you did a fine job yourself. :smile: Substitute on-disk file for in-memory file. The point is that you are interoperating. This is what is relevant. I guess you can state other true yet irrelevant facts if you like, but IMHO that's just confusing to the core issue here.

The license in fact says so, but only if you want to run a DikuMUD. The code won't be derived, but you have to abide by the rules of conduct. Someone who doesn't run a DikuMUD can indirectly make money off of it. It's somewhat silly.

If you're working with code that isn't covered by the license, then you do not have to follow the license. The license cannot restrict your activity on things it doesn't cover! (This is nearly tautological…)