[DGD] Idea for copyrighted yet publicly usable mudlibs

[Sampsa Ranta]

Byte code can be reverse compiled back to source if someone really sees 
it worthwile to create such tool. Such tools exist for Java, by 
analyzing the DGD compiler this could be done. Also for x86 compiled 
code, altought that would require extra effort. But in DGD the set of 
instructions is quite limited so it might well generate quite readable 
output.

If one ends up with good idea how to make code unhackable I guess media 
industry might be very interested on such.

- Sampsa

Noah Gibbs wrote:
>   This is fundamentally just a closed-source but publicly usable lib.  Which is
> fine, but it's basically just that you're compiling it for DGD rather than,
> say, x86.  Your suggestion of making it partially closed-source has also been
> done.
> 
>   That's not saying it's a bad idea.  It could be a good idea for the right
> people.  But yeah, this is a lot like the 'security' of releasing your MUDlib
> precompiled to x86, and has a lot of the same pitfalls.
> 
> --- Steve Wooster <s.f.m.wooster+dgd at gmail.com> wrote:
> 
> 
>>    You know how the people who wrote the DIKU code had a ton of people 
>>use their mudlib but not give credit for it? It occurred to me that 
>>releasing a mudlib via DGD statedumps maybe provide a reasonable 
>>solution for that, allowing you to make it difficult for the average joe 
>>to alter core sections of your mudlib. You could make something like the 
>>kernal-lib where there's a certain core/kernal that can't be touched by 
>>normal code, and make it so that upon connection, some message like 
>>"FoobarLIB v1.23 created by John Smith." is displayed to the user 
>>regardless of what the mudlib code says.
>>
>>Some possible pitfalls:
>>
>>This assumes that connections would be opened via telnet... a copyright 
>>message could screw up other protocols, preventing your mudlib from 
>>using them.
>>
>>Nobody's perfect, so your mudlib would need updates/patches. You could 
>>make it so that the core code can load patch files and alter its own 
>>code. To prevent people from using the patching ability to alter core 
>>code, you could make your code check digital signatures for any patches.
>>
>>Somebody who knows what they're doing could still bypass all your 
>>"security". Perhaps they could alter the mud's config-file to use 
>>different driver/auto objects. Or they could recompile DGD to add a copy 
>>of find_object() under a new name. Or if they really wanted to get 
>>technical, they could alter the statedump. Still, I imagine the sorts of 
>>people who know how to do that could write their own mudlib just fine... 
>>though I guess they could release a "cracked" version of the mudlib to 
>>the general public.
>>
>>Heh, I guess it's probably more work than it's worth, and easier just to 
>>release the mudlib as public domain. Still, for credit-seeking people, 
>>this might be viable.
>>
>>-Steve Wooster
>>
>>__________________________________________
>>http://mail.dworkin.nl/mailman/listinfo/dgd
>>
> 
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> __________________________________________
> http://mail.dworkin.nl/mailman/listinfo/dgd