10 Jan, 2013, Telgar wrote in the 1st comment:
Votes: 0
So I'm working on a MUD project which involves porting a Circle / Diku derived codebase to a new language. I considered doing a clean room rewrite from scratch, but here's the thing… I actually like the spirit of the Diku license. So I'm abandoning any idea of trying to make a clean break from it and freely admitting that my project is going to be a derived work (despite the fact that I am actually doing a full manual rewrite of every single line of code in a way that could not even be considered alike - modular object oriented code the Circle MUD is not). I've copied the concepts and even if I don't need to, I desire to copy the spirit.

Now, the problem with that is that the Diku license has a number of impingements on the freedom of use of the software that don't exactly qualify as open source… such as not charging money, etc. While I personally like those things, I am worried that an open source hosting site (such as SourceForge) won't. And yet I cannot shirk the responsibility I have taken to the license. SO I'm worried I will be turned down for hosting on popular project sites as a result.

Anyone ever encounter this particular problem before?
10 Jan, 2013, Runter wrote in the 2nd comment:
Votes: 0
Answer is don't use the diku license. If you're not using derived work, then no problem. So the other part of the answer is no, it's not an open source license.
10 Jan, 2013, KaVir wrote in the 3rd comment:
Votes: 0
Telgar said:
So I'm working on a MUD project which involves porting a Circle / Diku derived codebase to a new language … Anyone ever encounter this particular problem before?

Yeah, it's been discussed quite a few times.

http://www.copyright.gov/title17/92chap1...

"A derivative work is a work based upon one or more preexisting works, such as a translation…"

http://digital-law-online.info/lpdi1.0/t...

"As an analogy, consider the translation of a novel to a different language, something that would clearly be a derivative work. It makes little difference that none of the original words remain, or that the translation was done a little at a time. The resulting translation is still an infringing derivative work.

Even if you completely replace the program with new code, nonliteral elements also protected by the original program's copyright are likely to remain and infringe - elements like the overall program structure or architecture and data structures that are not dictated by external or efficiency considerations. Although there is no case law on this point, it would seem that the only way to break the chain of infringing works is by some extraordinary act, such as a clean room implementation."


http://www.bitlaw.com/source/cases/copyr...

"Most courts confronted with the issue have determined that copyright protection extends not only to the literal elements of a program, i.e., its source code and object code, but also to its "nonliteral" elements, such as the program architecture, "structure, sequence and organization", operational modules, and computer-user interface. See, e.g., Computer Assocs. Int'l, Inc. v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992)"

http://www.benedict.com/Digital/Software...

"The court decided that the purpose or function of a utilitarian work, such as a computer program, is the work's idea, and that everything not necessary to that purpose or function is part of the expression of the idea. Where there are various means of achieving the purpose or function, the means chosen are not necessary and therefore constitute expression. With this rule, the court held that copyright in a computer program protects the non-literal structure, sequence and organization of that program. Consequently, copyright infringement could be found for these elements even in the absence of direct source code or object code copying."
10 Jan, 2013, Vigud wrote in the 4th comment:
Votes: 0
http://www.copyright.gov/title17/92chap1...
"U.S. Copyright Office is an office of public record for copyright registration and deposit of copyright material."

http://digital-law-online.info/lpdi1.0/t...
"ABKCO Music Inc. v. Harrisongs Music, Ltd.
U.S. Court of Appeals, Second Circuit"


http://www.bitlaw.com/source/cases/copyr...
"Appeals from the United States District Court"

http://www.benedict.com/Digital/Software...
"Whelan Associates Inc. v. Jaslow Dental Laboratory, Inc., et al
U.S. Court of Appeals, Third Circuit"
10 Jan, 2013, Kayle wrote in the 5th comment:
Votes: 0
Anyone else not see Vigud's point?
10 Jan, 2013, plamzi wrote in the 6th comment:
Votes: 0
Kayle said:
Anyone else not see Vigud's point?


I think he's trying to cure my insomnia. It works! :)
10 Jan, 2013, Ssolvarain wrote in the 7th comment:
Votes: 0
Sleepiest diku argument ever.

Only on mudbytes :P
10 Jan, 2013, Vigud wrote in the 8th comment:
Votes: 0
You wish it was an argument, but I'm not contradicting anything that was said in KaVir's post. I'm just pointing out that many of the arguments in cited sources are based on US law precedents which most likely are irrelevant outside the US.
10 Jan, 2013, Orrin wrote in the 9th comment:
Votes: 0
The diku license is not OSI approved and doesn't meet their open source definition. Sourceforge requires all projects use an OSI approved license so you wouldn't be allowed to host your project there if it was covered by the diku license.

The solution is to either use a different license or a different hosting site.

Oh yeah, or this.
10 Jan, 2013, Rarva.Riendf wrote in the 10th comment:
Votes: 0
Quote
So I'm working on a MUD project which involves porting a Circle / Diku derived codebase to a new language. I considered doing a clean room rewrite from scratch,


If you already looked at the code , you are probably polluted by it. You may use same common data structure methods name etc. That is why people wanting to male a clone force themselves to NOT look at original code source even if they can. Write your own code, without looking back, it is the only way to ba able to claim your own license. (and even then, better really be mostly original)
I also have rewrited most of the code, but even if you would rewrite 90% of it, you would still be forced to keep the license. That is why I find GPL or other weird license like Diku sucks; BSD or DWTFYW FTW.
11 Jan, 2013, Telgar wrote in the 11th comment:
Votes: 0
Rarva.Riendf said:
Quote
So I'm working on a MUD project which involves porting a Circle / Diku derived codebase to a new language. I considered doing a clean room rewrite from scratch,


If you already looked at the code , you are probably polluted by it. You may use same common data structure methods name etc. That is why people wanting to male a clone force themselves to NOT look at original code source even if they can. Write your own code, without looking back, it is the only way to ba able to claim your own license. (and even then, better really be mostly original)
I also have rewrited most of the code, but even if you would rewrite 90% of it, you would still be forced to keep the license. That is why I find GPL or other weird license like Diku sucks; BSD or DWTFYW FTW.


It's really hard to make the polluted argument in this case based, code, data structures, file organization or any measurable metric. I haven't copied a thing, nor even remotely emulated the circle mud data structures or GET_MACROIZATION(ch) to all hell (which isn't even possible in the Javascript toolchain I am using), nor do I want a bazillion global variables and functions in my top level namespace, nor do I have to deal with bitvectors when I can simply use string arrays, etc.. the works look nothing at all similar.

However, I copied the idea of using embedded color codes in game text files to do ANSI color encoding and therefore I claim I am a derivative work based on that.

It's also worth noting that the server code running the MUD in which the Javascript runtime is embedded is actually the Circle code, so I'm a derived work anyway, whether the port of the game mechanics to the language runtime is "clean" or not.

I suppose I'll have to find my own hosting for the project in that case rather than bumming some space on SourceForge. I actually like the Diku license restrictions on not selling in-game items or requiring a pay-for-play barrier to entry. In fact, given that I am already not OSI approved, I will probably extend the restrictions to require notification to myself if derivative works are made.
11 Jan, 2013, arendjr wrote in the 12th comment:
Votes: 0
GitHub is a pretty popular hosting service nowadays: https://github.com/

They're license-agnostic :)
11 Jan, 2013, quixadhal wrote in the 13th comment:
Votes: 0
It's chilly in here… FLAME ON!

Telgar said:
I actually like the Diku license restrictions on not selling in-game items or requiring a pay-for-play barrier to entry.


That's an incredibly outdated restriction, created back in the days when it was impractical for any ordinary user to have a machine capable of running a MUD with players on it, and impossible for a home user to have a connection that was always on, and fast enough to support more than a few players at a time.

Today, I could run the original DikuMUD on my router, and even with 50 players, I wouldn't notice any resource usage.

The original idea was almost certainly to keep some big company from stealing the work of the DikuMUD team, and turn it into a giant graphical MMO named Everquest, without reaching some kind of deal with them first.

In 2013, if you think you can provide a MUD that's competitive enough to get people to fork over money to play it, congrats! Maybe you'll make enough to hit McDonald's a couple times a week!

There, it just seems wrong to have a DikuMUD legal thread in here without a few flamethrowers.
11 Jan, 2013, mangan wrote in the 14th comment:
Votes: 0
Inspiration is not the same thing as being a derivative work. I'll avoid the in depth legal arguments, but if you are truly making a new MUD from scratch (without using Diku or its derivatives as a code reference) and you want others to use it, then I would highly suggest that you break free from the license. If it is indeed "a MUD project which involves porting a Circle / Diku derived codebase" then I retract my suggestion. I'm a bit confused as to what you're doing exactly (based on later posts), nor am I a legal advisor of any sort, but if you're actively looking at the derivative codebase's source code during any point in your own MUD project's development, then there are good grounds to consider it a derivative.

My reasoning behind avoid the Diku license, if it is proper to do so, is that it will restrict many possible developers from using it. Additionally, if you agree with the meaning behind the Diku license, but you are not actually a Diku derivative, then I would suggest using another [more common] license that is properly worded from a modern legal perspective, to help prevent future license violators that "do not agree with the intent" despite evidence shown.

Best of luck.
11 Jan, 2013, plamzi wrote in the 15th comment:
Votes: 0
confused.push('plamzi');
11 Jan, 2013, Ssolvarain wrote in the 16th comment:
Votes: 0
Didn't the diku team come up with a commercial codebase, as well?
12 Jan, 2013, Hades_Kane wrote in the 17th comment:
Votes: 0
If I recall right, they created Diku 2 which you could purchase to run games off. I could be remembering wrong, though.
12 Jan, 2013, Davion wrote in the 18th comment:
Votes: 0
12 Jan, 2013, Ssolvarain wrote in the 19th comment:
Votes: 0
I don't think I've ever seen a mud based on it.

Are there any notable ones?
19 Jan, 2013, Telgar wrote in the 20th comment:
Votes: 0
quixadhal said:
It's chilly in here… FLAME ON!

Telgar said:
I actually like the Diku license restrictions on not selling in-game items or requiring a pay-for-play barrier to entry.


That's an incredibly outdated restriction, created back in the days when it was impractical for any ordinary user to have a machine capable of running a MUD with players on it, and impossible for a home user to have a connection that was always on, and fast enough to support more than a few players at a time.

Today, I could run the original DikuMUD on my router, and even with 50 players, I wouldn't notice any resource usage.

The original idea was almost certainly to keep some big company from stealing the work of the DikuMUD team, and turn it into a giant graphical MMO named Everquest, without reaching some kind of deal with them first.

In 2013, if you think you can provide a MUD that's competitive enough to get people to fork over money to play it, congrats! Maybe you'll make enough to hit McDonald's a couple times a week!

There, it just seems wrong to have a DikuMUD legal thread in here without a few flamethrowers.


Flame accepted!!!

I actually only care about the "not selling in game items" part. I specifically don't want that to be possible with any works derived from my work on this project, as I think the "buy a top end kit" idea makes for crap gameplay and I would never want any of my code or any of my zones running on a server which allowed such a thing.

I certainly don't expect to generate that sort of interest in the MUD I am developing or anything, I just don't want anyone with more time / financial resources to burn^H^H^H^Hthrow away to ever take my code and effort and do it.
0.0/35