On 10/04/2013 07:28 AM, David U. wrote:
It looks like I’ve been misunderstood. I don’t intend to annoy customers
or trying to protect code with DRM, serials or other obtrusive ways.
I’m trying to protect algorithms our code contains to prevent misuse by
other subject that would simply copy & paste from our sources and with
slight modifications would sell it as its own.
I don’t think you were misunderstood at all. According to the
documentation, RubyEncoder will do exactly what you want. It should be
invisible to your users, and will prevent trivial access to your
sources. It should also be more robust against reversal than a simple
obfuscation tool is likely to be.
It /is/ effectively DRM though, just like DVDs and Blu-rays, but that’s
what you want given your needs. Things just work for regular users
accessing the work via an authorized means (the RubyEncoder runtime in
this case), while unauthorized access is made more difficult.
Personally, I wouldn’t put much stock in such means of protection for
long. Someone can find a way to do something similar even without
access to your sources, especially once your product proves that such
features are possible and valuable. If /how/ your code works is the key
to the value proposition of using your software vs. an alternative,
you’ll be in trouble no matter how your competition arises. Plan to
offer something more than just code, support or installation services
for the product for example. 
You can raise an
objection there are laws & lawyers that can protect us however in our
country it’s a very long, complicated and expensive process with an
unclear result, during such period we would either lose incomes or even
bankrupt.
This is a valid point in just about any country. Copyright enforcement
can be expensive especially if you have to go to court, so you’re right
to not depend on it if you don’t have deep pockets.
You can admit we were chosen a wrong tool for our task (offline, localy
installed ruby application) but in our team we are most experienced with
rails and ruby and their standard libraries.
Honestly, this is a risk with any software you distribute, regardless of
the implementation language. Debuggers and decompilers exist even for
fully compiled languages, and if there is value in getting an
understanding of at least your algorithms, you can rest assured that
someone will use such tools on your product. Ruby makes the job of the
would-be hacker easier, but if your team is more productive using Ruby
than, say, C, it’s probably a reasonable trade off.
Something else to consider is writing your ultra secret stuff in C as a
Ruby extension. The bulk of your code is probably nothing special but
would be tedious to write in C for your team. There’s little need to
hide that stuff. The secret logic though is probably small enough to
write and maintain in C, and there are potential efficiency/performance
advantages to this approach as well. Again, it’s not a guarantee of
protection, but it’s probably the least involved method of hiding your
code and making reverse engineering of your algorithms difficult.
-Jeremy
