Lothar Scholz wrote:

>Hello Bill,
>
>
>BK> I imagine the obfuscation would include translation of once-
>BK> meaningful identifiers (variable names, method names, ...)
>BK> into meaningless gibberish.  A lexer would not help much there.
>
>BK> Such an obfuscator sounds really tough to write for Ruby
>BK> though...  I presume the string form of eval() would have
>BK> to be disallowed from referring to any code subject to
>BK> obfuscation...
>
>BK> I would be very interested in a working Ruby code obfuscator,
>BK> even given certain restrictions like that.  I'm writing an
>BK> application in Ruby that will likely be heavily pirated, like
>BK> a video game, as soon as a cracked copy of it becomes 
>BK> available.  As with video games, which i used to do for about
>BK> 9 years professionally, we're just trying to delay the time it
>BK> takes for someone to produce a cracked version.  At least,
>BK> I'm presuming anyone needing a Ruby code obfuscator is probably
>BK> coming from the same situation.  That's why I'd like one anyway.
>BK> I'm developing in Ruby because I want to add features faster
>BK> than the competition.  (Not to mention how much fun programming
>BK> in Ruby is. :)  But I've gone into writing this app in Ruby
>BK> knowing I'm going to need *some* solution to delaying the
>BK> (inevitable) appearance of a cracked version of my app.  So I'm
>BK> very glad to hear Ken is working on such a technology, and
>BK> grateful he'd be willing to share it.
>
>
>I would also like to see something like this.
>But to be true, it wouldn't help very much. The only real protection
>system is to put the ruby source code under a BSD license so that you
>can change the code and add some private decryption code inside the
>"rb_compile_cstr" function. Of couse this can't be open source.
>Remember that even a bytecode wouldn't help that much, as you can see
>in decompiled Python/Java code. It's very readable.
>
>So my request is up going to matz directly if he want's to change
>the license for the ruby interpreter, allowing ruby to be more useable in
>some kind of commerical applications.
>
>
>Actually, here's a license that just might fit the bill - http://www.zesiger.com/license/ - It doesn't require the source to be opened until 2 years after the first commercial sale. It's better than just closing the source completely and forgetting about it. 
>
>
>  
>