12 Oct, 2009, Confuto wrote in the 1st comment:
Votes: 0
If I were to port a Diku codebase into another programming language, would it count as a derivative?
12 Oct, 2009, Dean wrote in the 2nd comment:
Votes: 0
My guess would be yes, it'd still be a derivative.
12 Oct, 2009, Skol wrote in the 3rd comment:
Votes: 0
Yes it would, just as a language translation of a book into another language is still that same book.
12 Oct, 2009, Runter wrote in the 4th comment:
Votes: 0
Confuto said:
If I were to port a Diku codebase into another programming language, would it count as a derivative?


It's a hard question to answer since individually the techniques used aren't protected. That is to say, regardless of the project or the context, if you decide to write a game using a technique you learned while working on a diku codebase you're not violating anything. For example, the common practice of logically separating objects from templates–Or any of the countless dikuisms.

It's really hard to say at what point it would become like translating a book to another language. Especially if there is no intellectual property copied. (Which the entire book actually would be.) Standard packaged zones, descriptions, etc, could be a different story.
12 Oct, 2009, KaVir wrote in the 5th comment:
Votes: 0
Runter said:
Confuto said:
If I were to port a Diku codebase into another programming language, would it count as a derivative?

It's a hard question to answer since individually the techniques used aren't protected. That is to say, regardless of the project or the context, if you decide to write a game using a technique you learned while working on a diku codebase you're not violating anything.


He's not talking about just using the same programming techniques though, he's talking about porting the entire codebase to another programming language. That is pretty much a translation, which is indeed a type of derivative work.
12 Oct, 2009, Orrin wrote in the 6th comment:
Votes: 0
I guess it depends on what you mean exactly by porting it to another language. If you were to go through the original codebase line by line and translate it into a different language then I think that would definitely be considered a derivative work. If you're talking about organising your code in the same way as DIKU or using the same techniques or approaches to solving the problem of a MUD server then as Runter says it would be more difficult to determine.
12 Oct, 2009, Runter wrote in the 7th comment:
Votes: 0
KaVir said:
Runter said:
Confuto said:
If I were to port a Diku codebase into another programming language, would it count as a derivative?

It's a hard question to answer since individually the techniques used aren't protected. That is to say, regardless of the project or the context, if you decide to write a game using a technique you learned while working on a diku codebase you're not violating anything.


He's not talking about just using the same programming techniques though, he's talking about porting the entire codebase to another programming language. That is pretty much a translation, which is indeed a type of derivative work.


Perhaps, but it's still difficult to answer since A) writing a mud from scratch that plays like a diku isn't a violation. B) Writing a mud that uses every technique in a diku isn't a violation. And A+B) Writing a mud from scratch that plays like a diku and uses every technique they use also isn't a violation.

I don't think it's a clear case even as a clone. It really depends on the specific code in question to generate the so-called derivative work in my opinion.
12 Oct, 2009, Dean wrote in the 8th comment:
Votes: 0
Well, a certain person who shall remain unnamed did what Kavir described I believe with his codebase. Just saying.
12 Oct, 2009, Runter wrote in the 9th comment:
Votes: 0
Dean said:
Well, a certain person who shall remain unnamed did what Kavir described I believe with his codebase. Just saying.


Well, make no mistake, regardless of the legality I think you can safely call it unseemly without proper credit and only with permission.
12 Oct, 2009, KaVir wrote in the 10th comment:
Votes: 0
Runter said:
Perhaps, but it's still difficult to answer since A) writing a mud from scratch that plays like a diku isn't a violation. B) Writing a mud that uses every technique in a diku isn't a violation. And A+B) Writing a mud from scratch that plays like a diku and uses every technique they use also isn't a violation.

Sure, but those aren't porting (which is what the OP was asking about), at least not by any definition I've ever heard of.

http://en.wikipedia.org/wiki/Porting

"In computer science, porting is the process of adapting software so that an executable program can be created for a computing environment that is different from the one for which it was originally designed (e.g. different CPU, operating system, or third party library). The term is also used in a general way to refer to the changing of software/hardware to make them usable in different environments. Software is portable when the cost of porting it to a new platform is less than the cost of writing it from scratch. The lower the cost of porting software, relative to its implementation cost, the more portable it is said to be."

http://www.computer-dictionary-online.or...

"Translating software to run on a different computer and/or operating system."

http://www.webopedia.com/TERM/P/port.htm...

"(v.) To move a program from one type of computer to another. To port an application, you need to rewrite sections that are machine dependent, and then recompile the program on the new computer. Programs that can be ported easily are said to be portable."

http://searchnetworking.techtarget.com/s...

"In programming, to port (verb) is to move an application program from an operating system environment in which it was developed to another operating system environment so it can be run there. Porting implies some work, but not nearly as much as redeveloping the program in the new environment."

http://www.yourdictionary.com/computer/p...

"To convert software to run in a different computer environment. For example, the phrase "to port the application to Unix," means to make the necessary changes in the program to enable it to run under Unix."

Etc.

EDIT: Although to be fair, I've never heard "porting" used to refer to convertion into another programming language, either, so it would probably be a good idea for the OP to clarify exactly what it is he wants to do.


Dean said:
Well, a certain person who shall remain unnamed did what Kavir described I believe with his codebase. Just saying.

Would this be the same person who went on to claim that, since he had converted Merc 1.0 (which is written in C) to C++, it was no longer a derivative?
12 Oct, 2009, Dean wrote in the 11th comment:
Votes: 0
KaVir said:
Would this be the same person who went on to claim that, since he had converted Merc 1.0 (which is written in C) to C++, it was no longer a derivative?


Well, I do say that this person I was eluding shares something with the Knights who say Ni.
12 Oct, 2009, Runter wrote in the 12th comment:
Votes: 0
KaVir said:
Runter said:
Perhaps, but it's still difficult to answer since A) writing a mud from scratch that plays like a diku isn't a violation. B) Writing a mud that uses every technique in a diku isn't a violation. And A+B) Writing a mud from scratch that plays like a diku and uses every technique they use also isn't a violation.

Sure, but those aren't porting (which is what the OP was asking about), at least not by any definition I've ever heard of.


Yes, which is another reason it's hard to get a straight answer for. I think we're on the same page though.
12 Oct, 2009, David Haley wrote in the 13th comment:
Votes: 0
I think that a gross stab at an answer is that if you were to go through it, deliberately rewriting things line by line, it would probably count as a derivative. If you were to build something in a different language that played the same way, and was even compatible with the file formats, you could argue it's not a derivative, although you would have to argue that you didn't just do a line-by-line translation.
12 Oct, 2009, KaVir wrote in the 14th comment:
Votes: 0
I think the whole programming language thing is muddying the water - it's not relevant. Translations are derivative works, so if you want to create something that isn't a derivative, changing the programming language won't help. Copying ideas, techniques, playing style and even file formats is (probably) fine, but that's true even if you use the same language as the game you're copying.

So to the OP I'd suggest you pick a programming language based on other criteria, such as your familiarity with it, how well suited it is to the style of mud you wish to create, etc.
12 Oct, 2009, David Haley wrote in the 15th comment:
Votes: 0
Yes, I think KaVir is right; much the same issues would appear if you were going from C to C++, or even C to C for that matter.
The main difference changing languages makes is that it would (probably) be easier to claim original code. There are constructs used in C that you simply wouldn't use in other languages (like Ruby, Python, Lua, …), so you'd have to rewrite stuff anyhow.
12 Oct, 2009, Tyche wrote in the 16th comment:
Votes: 0
Porting/translating are processes that create derivative works. Take a look a CoffeeMud (Java), ScryMud (C++) or Mud++ (C++). These are muds that implement many of the features and gameplay of DikuMuds but are neither translations or ports; original works in their own right though quite definitely inspired from DikuMuds.

You were asking elsewhere about RocketMud. RocketMud while in Ruby is clearly a derivative of SocketMud written in C.
If you were to use the same process with DikuMud that I used with SocketMud you'd also be creating a derivative.

OTOH, TeensyMud almost contains a convincing implementation of TinyMud. A few more commands, fields and flags and it would implement all the features. However, it's not a derivative since I never used any code from Tiny.
12 Oct, 2009, JohnnyStarr wrote in the 17th comment:
Votes: 0
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. If so, it's hard to say where you would draw the line.
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? Most commands are still very ROM to me, but without seeing the source code, I can only guess around.
12 Oct, 2009, KaVir wrote in the 18th comment:
Votes: 0
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?
12 Oct, 2009, Orrin wrote in the 19th comment:
Votes: 0
staryavsky said:
Most commands are still very ROM to me, but without seeing the source code, I can only guess around.

When we first started Maiden Desmodus someone accused us of using the RPI Engine codebase because of how similar some of the output looked. I think now I'd be more inclined to blow it off, but back then I was quite upset about it. The irony is that the guy who made the accusations is apparently now working on his own game using Nakedmud. Anyway, just a brief derail but I guess I'm making the point that if you wanted to design something which looked completely like another server it's easy enough to do without ever having looked at a single line of the original code.
12 Oct, 2009, KaVir wrote in the 20th comment:
Votes: 0
I always expected someone to accuse me of basing GW2 on GW1, but they never have. Scandum once said GW2 looked like ROM, and Sandi said it reminded her of TinyMUD (or was it MUSH?), but that's about it.
0.0/38