05 Aug, 2009, KaVir wrote in the 1st comment:
Votes: 0
Many years ago, I installed a version of IMC into GodWars Deluxe. But then someone pointed out that IMC was licenced under the GPL, making it incompatible with the Diku licence, so I stripped it out again. I believe the issue was resolved a short while later, but I didn't get around to looking at IMC again.

Just now I downloaded a copy of the latest version of IMC2, thinking it might be fun to add it to GW2. However it now seems to have been released under the Diku licence, and I can't find the GPL'd version any more.

I've seen versions for LPC and Ruby, but is there anything for non-Diku muds written in C or C++? I'm not excited enough about the concept to write my own client from scratch.
05 Aug, 2009, ghasatta wrote in the 2nd comment:
Votes: 0
A few months ago I ran into the same problem you have, namely that the existing C client libraries available are very diku-specific. I have been working on a custom C++ IMC client recently with the intention of eventually releasing it publicly (perhaps the best term is a client 'stub'?).

It's not ready for primetime, but I have done a lot of the legwork already. Of course, since the client is intended to be incorporated into custom codes, there will necessarily be some extra work required on the part of any implementer in order to bridge the gap between the client and your mud. My goal is to make this 'bridging' straightforward and clear for anyone who would use my client.

If you are interested, and can wait a few days (I am on the road), I would be happy to share what I have so far.
05 Aug, 2009, KaVir wrote in the 3rd comment:
Votes: 0
There's no rush, and I'd certainly be interested to see what you've got. I've no problem with bridging the gap between the client and the mud, it's creating the entire client from scratch that I don't fancy doing.
05 Aug, 2009, Chris Bailey wrote in the 4th comment:
Votes: 0
KaVir - Plugging the ruby client into a C/C++ project isn't any harder than plugging it into a Ruby project. Check out Ruby.h, it will basically tell you how to do it. =)


EDIT - Sorry, also README.ext that comes with Ruby.
06 Aug, 2009, Guest wrote in the 5th comment:
Votes: 0
The only reason the Freedom client got released that way was a matter of convenience since it was written with Diku MUDs in mind and likely isn't independent enough as it stands to operate without one. Since it's our code though it could be relicensed in some other way so long as it remains legally compatible with Diku.
06 Aug, 2009, David Haley wrote in the 6th comment:
Votes: 0
You can release the same code under several licenses if you wanted to, though, right? So there's nothing to stop you from releasing one version as Diku-compatible, and another version as GPL/MIT/BSD/Apache/blablabla.
06 Aug, 2009, Guest wrote in the 7th comment:
Votes: 0
Except I don't want the GPL anywhere near the code. I don't particularly like the license and it causes too many problems with the kind of code people want to incorporate it into. Dual-licensing might be nice, but it's less confusing to have just one that's compatible. Last I checked the BSD license should be legally compatible so that's probably a good option.
06 Aug, 2009, Koron wrote in the 8th comment:
Votes: 0
KaVir said:
Many years ago, I installed a version of IMC into GodWars Deluxe. But then someone pointed out that IMC was licenced under the GPL, making it incompatible with the Diku licence, so I stripped it out again.

I think I'm missing something here. Why would GPL and Diku licenses be incompatible?
06 Aug, 2009, Davion wrote in the 9th comment:
Votes: 0
Koron said:
I think I'm missing something here. Why would GPL and Diku licenses be incompatible?


The GPL says you can make money in some ways, and the diku license says there's no way.
06 Aug, 2009, Guest wrote in the 10th comment:
Votes: 0
Koron said:
I think I'm missing something here. Why would GPL and Diku licenses be incompatible?


Because the Diku license places additional restrictions on your rights with the code that go against the GPL's explicit prohibition against imposing additional restrictions. So they're not legally compatible because of it. Mostly from the Diku no-profits clause.

Edit: Ninja'd!
06 Aug, 2009, KaVir wrote in the 11th comment:
Votes: 0
Chris Bailey said:
KaVir - Plugging the ruby client into a C/C++ project isn't any harder than plugging it into a Ruby project.

But it requires the Ruby interpreter to first be embedded into my mud, which isn't a trivial task. Searching around, I did find an article about it, as well as a few forum posts (usually with replies suggesting using LUA as an embedded scripting language instead). And of course I'd have to learn the language as well. All in all, it strikes me as even more work than just writing the client myself in C++.

Samson said:
The only reason the Freedom client got released that way was a matter of convenience since it was written with Diku MUDs in mind and likely isn't independent enough as it stands to operate without one.

That's fair enough - from looking through the code, I can already see I'd have to make quite a lot of changes. However I'm already familiar with Diku from my GW1 days, so I've no problem understanding the code, and it's written in C which means I could reuse the majority of it and just wrap it in a namespace.

Samson said:
Except I don't want the GPL anywhere near the code.

I'd rather avoid the GPL as well, but it would be preferable to binding myself to the Diku licence for the sake of a snippet (is the ICM2 client actually Diku derived code?).

Samson said:
Last I checked the BSD license should be legally compatible so that's probably a good option.

The BSD licence would be great, but it would require permission from all of the copyright holders. Are they still active?
0.0/11