12 Oct, 2009, JohnnyStarr wrote in the 21st comment:
Votes: 0
KaVir said:
staryavsky said:
Aardwolf comes to mind; it claims to no longer be a Diku based mud, if so, how much did they have to cut from the original ROM code?

I know they were talking about rewriting the mud - I didn't know they'd already done it though. Was there some sort of announcement?


Interesting, they say V3 is not yet live.
However this is news to me, I could have swarn a year ago
They already claimed to no longer be Diku based. Infact, when
You typed 'help diku' the help file also made that claim.

Well, either they changed their story, or I am crazy.
Which normally I wouldnt doubt.
12 Oct, 2009, Tyche wrote in the 22nd comment:
Votes: 0
staryavsky said:
It seems like more of an ethical question than a legal question.
Not that it was stated otherwise, but I get the feeling that, that is what
is in question.


Well it may be either ethical or legal, although I'm not sure why the question is so important. The Diku license certainly allows one to create derivatives, so there's really no ethical or legal obstacle at all in translating/porting it to other machines and languages.

The two main reasons I've seen the question is raised is that (a) they want to start a commercial mud or (b) they don't want the Diku team appearing in the login sequence. The latter seems to be an ego issue. ;-)
12 Oct, 2009, Tyche wrote in the 23rd comment:
Votes: 0
It's my personal opinion that Aardwolf violates the ROM license. I stopped contributing to the TMS site when the former owner started taking money from Medievia, and when the site stopped doing that and was sold to Lasher of Aardwolf, I still saw no reason to support one license violator over another.
12 Oct, 2009, Confuto wrote in the 24th comment:
Votes: 0
KaVir said:
I think the whole programming language thing is muddying the water - it's not relevant.

I disagree with this. Let me compare the translation of a computer program from one language to another to the translation of a novel.

A novel is broadly comprised of two parts: the story (characters, plot, setting, etc) and the style. In the case of a novel, reproducing a particular author's style is not violation of their copyright, but reproducing their story is. In general, a good translation of a novel is one that most accurately reproduces the story and style of the original author in another language. We might say that a bad translation is one which reproduces the story but loses the original author's unique style, although such a work may well have other value.

A computer program is also comprised of two parts: the application (or the story) and the code (or the style). In the case of a program, however, reproducing a particular programmer's application is not necessarily a violation of their copyright - two people can write a calculator that functions in the exact same way, for instance. Reproducing their code, however, is a violation - if one person uses another's calculator code in their own project, they are violating the other's copyright (even if their project is not a calculator).

In the case of Diku, then, a "good" translation (or port) using the novel definition would be a line-by-line reproduction in another language. A "bad" port would be one that accurately reproduces the Diku application but has nothing in common with the original code. The port we're calling bad, though, may actually be the one that makes best use of the new language.

I guess I agree with what a few others have said: while a line-by-line translation qualifies as a derivative, the same may not necessarily be true if the new code simply uses the same general techniques as Diku. Perhaps the latter doesn't qualify as a "port" of Diku, though.

Please know that I don't have any nefarious purpose here, I just find this stuff interesting.
12 Oct, 2009, JohnnyStarr wrote in the 25th comment:
Votes: 0
This makes me curious of something, (not to go too off subject):

Obviously ROM came from Merc, which came from Diku. Now, what if someone decided to remake ROM into
their own new codebase, how much freedom would they have? As in, if you are going to use "blah blah codebase", you need to have a section dedicated to let's say "biscuits", could this be done? Or, as a more practical example, could a derivative make it's own license more powerful than the Diku license, saying something like, "You may only use this code if you don't make derivatives of your own." So, if you wanted to cut them off at your base, could this happen? Of course, I don't see why anyone would benefit from this, but I was curious.
12 Oct, 2009, Sandi wrote in the 26th comment:
Votes: 0
Tyche said:
The two main reasons I've seen the question is raised is that (a) they want to start a commercial mud or (b) they don't want the Diku team appearing in the login sequence. The latter seems to be an ego issue. ;-)

I'm feeling slightly self-defensive as I write this, but while I think in general you are correct, I believe for myself the greatest concern is one of aesthetics. Since MUSHes require no credits at login, I'm used to having a "blank screen" to work with, and trying to work a block of text into the design has always been a pain when working with Dikurivatives.
12 Oct, 2009, KaVir wrote in the 27th comment:
Votes: 0
Confuto said:
In the case of Diku, then, a "good" translation (or port) using the novel definition would be a line-by-line reproduction in another language. A "bad" port would be one that accurately reproduces the Diku application but has nothing in common with the original code.

Don't forget, copyright also protects non-literal elements.

staryavsky said:
Obviously ROM came from Merc, which came from Diku. Now, what if someone decided to remake ROM into their own new codebase, how much freedom would they have?

They could impose any restrictions they wished, but they (and whoever used their codebase) would also be bound by the Diku, Merc and ROM licences. So in answer to your other question, yes, you could prevent people creating derivatives of your codebase.
12 Oct, 2009, Orrin wrote in the 28th comment:
Votes: 0
Sandi said:
Since MUSHes require no credits at login, I'm used to having a "blank screen" to work with, and trying to work a block of text into the design has always been a pain when working with Dikurivatives.

I have seen a few MUDs where the credits are placed first and then blank lines used before the mud logo so they scroll off the screen almost instantly. I know the ROM license specifically forbids this but I think it's ok for other DIKU derivatives. I don't know if it's strictly ethical but it would allow you to design your login ASCII or whatever without the credits getting in the way. There are also a lot of MUDs that put the credits later on in the login sequence before the MOTD for example. Again I think this may not be allowed with ROM but I don't know about the rest.
13 Oct, 2009, Tyche wrote in the 29th comment:
Votes: 0
staryavsky said:
This makes me curious of something, (not to go too off subject):

Obviously ROM came from Merc, which came from Diku. Now, what if someone decided to remake ROM into
their own new codebase, how much freedom would they have? As in, if you are going to use "blah blah codebase", you need to have a section dedicated to let's say "biscuits", could this be done? Or, as a more practical example, could a derivative make it's own license more powerful than the Diku license, saying something like, "You may only use this code if you don't make derivatives of your own." So, if you wanted to cut them off at your base, could this happen? Of course, I don't see why anyone would benefit from this, but I was curious.


The authors of (ROM specifically) derivatives are free to add more restrictions on the resulting work (and have), but they cannot remove restrictions.
Some authors have released derivatives of ROM that prevent people from releasing further works based on that derivative; DoT or Dawn of Time was one.

::Edited to add "(ROM specifically)" as some licenses like GPL don't allow restricitons to be added.
13 Oct, 2009, bbailey wrote in the 30th comment:
Votes: 0
Tyche said:
The authors of derivatives are free to add more restrictions on the resulting work (and have), but they cannot remove restrictions.
Some authors have released derivatives of ROM that prevent people from releasing further works based on that derivative; DoT or Dawn of Time was one.


For another example, AFKMud is a SMAUG derivative that also restricted derivative works.
13 Oct, 2009, Omega wrote in the 31st comment:
Votes: 0
On the topid of aardwolf:

http://www.aardwolf.com/v3.html

And for the commentary on Diku…

http://www.aardwolf.com/v3/v3diku.html
13 Oct, 2009, KaVir wrote in the 32nd comment:
Votes: 0
Orrin said:
There are also a lot of MUDs that put the credits later on in the login sequence before the MOTD for example. Again I think this may not be allowed with ROM but I don't know about the rest.

It's fine for Diku, and Merc doesn't require any login credits at all, but (as you mentioned) you can't do that for ROM. Still, you could in theory put the brief ROM credits on the first screen, then list the Diku ones later on. Or you could use one of the many other Diku derivatives that don't require the credits to be placed on the initial screen.


Darien said:
On the topid of aardwolf:

http://www.aardwolf.com/v3.html

And for the commentary on Diku…

http://www.aardwolf.com/v3/v3diku.html

Interesting, thanks for the links. It's a shame they didn't make the changelogs public.
13 Oct, 2009, Sandi wrote in the 33rd comment:
Votes: 0
KaVir said:
It's fine for Diku, and Merc doesn't require any login credits at all, but (as you mentioned) you can't do that for ROM. Still, you could in theory put the brief ROM credits on the first screen, then list the Diku ones later on.

I did exactly that for quite a while, reducing the log-in screen credits to just one line. After looking at it long enough, it bothered me that only Russ's name was on the front page and I went back to listing everybody.

What really chaffs me is these guys that write a mere snippet and think they deserve log-in screen credits. Now there's someone with an ego problem.
13 Oct, 2009, KaVir wrote in the 34th comment:
Votes: 0
Sandi said:
What really chaffs me is these guys that write a mere snippet and think they deserve log-in screen credits. Now there's someone with an ego problem.

Interestingly enough I can think of two individuals who have done that - both of whom also stripped the Diku credits from their own games (which I guess goes back to Tyche's comment about people who strip credits for ego reasons).
13 Oct, 2009, Cratylus wrote in the 35th comment:
Votes: 0
Is an area a derivative work?

For example, if I were to port an .are into a Coffeemud,
would that Coffeemud then have to display the Diku dev
names at login?

-Crat
http://lpmuds.net
13 Oct, 2009, bbailey wrote in the 36th comment:
Votes: 0
Cratylus said:
Is an area a derivative work?

For example, if I were to port an .are into a Coffeemud,
would that Coffeemud then have to display the Diku dev
names at login?

-Crat
http://lpmuds.net


IIRC, areas (especially on muds with world files that are distinct from code, as Diku's are) are treated more or less as independent works, such that crediting the author (or whatever other licensing terms are attached specifically to the areas) is 'enough'. I'd have to say though that this is more of a community convention rather than any legal interpretation.
13 Oct, 2009, KaVir wrote in the 37th comment:
Votes: 0
bbailey said:
IIRC, areas (especially on muds with world files that are distinct from code, as Diku's are) are treated more or less as independent works, such that crediting the author (or whatever other licensing terms are attached specifically to the areas) is 'enough'.

I agree with them being independent works, however you'd still need permission to use them, and very few areas come with an explicit licence. If the area is bundled with a Diku distribution then I think it's probably reasonable to assume you can use them within the terms of the Diku licence. If you're using them in a different codebase it's a bit more fuzzy - I doubt many people would mind them being used in a truly-free LPMud as long as the builders were given the usual credit, but (for example) I don't think it's appropriate to port the areas to a pay-to-play mud without first securing permission from the author/s.
13 Oct, 2009, bbailey wrote in the 38th comment:
Votes: 0
KaVir said:
I agree with them being independent works, however you'd still need permission to use them, and very few areas come with an explicit licence. If the area is bundled with a Diku distribution then I think it's probably reasonable to assume you can use them within the terms of the Diku licence. If you're using them in a different codebase it's a bit more fuzzy - I doubt many people would mind them being used in a truly-free LPMud as long as the builders were given the usual credit, but (for example) I don't think it's appropriate to port the areas to a pay-to-play mud without first securing permission from the author/s.


Yeah. In the absence of an explicit license, I'd fall back on the license of the overall distribution. Most of my 'use it but credit them' thinking, with regard to Diku areas specifically, comes from vague recollections of many of the authors being tracked down and asked about independent distribution back in the heyday of Romlama, the smaug area exchange, and other area collections.

Edit: fixed quoting
20.0/38