Closed source projects and scripting languages

Question

Hello, I've considered making a closed source project, but if I made it then I'd want to make it in Ruby. Ruby is interpreted though. Other similar languages to Ruby include Python and Perl. How would you best distribute your code without giving away all the logic(at least easily readable)? And what about meta programming? Do obfuscaters interfere with this commonly?

Clarification My project is a tool for managing databases. So if they have the internal logic then it's nothing bad(like it could be for games and such) but I do not want for the source code to be copyable into some other project or distributed external to me. I'm ok with if people were to buy it or whatever then they have the source. I trust that if someone buys it then they aren't going to try that.. My biggest problem though is how to provide a trial version of such a program. If I put a time bomb in it, they could just look at the logic and disable it. etc etc...

Answer 1

With Python at least you can distribute the compiled bytecode along with the appropriate interpreter and libraries.

Answer 2

First, why do you want to make it closed source? Do you want to collect revenue when you sell your software? If not, then why are you afraid of giving out the logic? If you really insist, then use a compiled language.

Answer 3

One possibility is for you to make your "logic" a compiled module and then wrap it with Python for the higher level stuff. Some games do this (engine is in C and levels are in Python/lua) although they do it for performance.

Answer 4

Along the lines of ghostdog74's answer, I would first ask what your objective is. You don't necessarily need to close source a program to make money off of it, or even to make money off of licensing it. A lot of companies have dual licensing models for their open source products, which means the source code is all out there (or at least 98% of it is), but they're still charging licensing fees for certain use cases (e.g. commercial uses, or commercial use in organizations with more than X number of users).

Also, most scripting-language-based products are web/intranet applications. And with a lot of web apps there just isn't any point in trying to hide the code, even if it is closed source. In most cases there's really nothing novel about the implementation of a particular product, and what you're selling to customers is just:

1. a pre-packaged solution that works and saves the customer the time/money it costs to develop their own in-house application
2. commercial support and quality guarantees
3. a feature set that sets this product apart from others on the market.

None of these selling points receive any sort of benefit or protection from concealing the source code. Number 2 is the same regardless of whether the source is open or closed. Selling points 1 and 3 can both be undermined by IP infringement, but source code availability is irrelevant in both cases. Someone can pirate your software just as easily if the source code were hidden or obfuscated, and your competitors don't need your source code to copy your feature set.

There are cases where one may want to protect a proprietary algorithm or formula (e.g. if you've not secured a patent on it yet or are seeking to achieve security through obscurity), but I'd wager to say that for most projects, obfuscating your source code is a moot point.

We have legislation in place to protect intellectual property. So, unless you're selling a product on the black market, concealment of source code would only serve to protect the parts of your source code that cannot be considered your intellectual property.

Edit: Obviously a lot of people don't feel this actually answers the question, and I can understand that sentiment. I do generally try to give direct answers to questions, except when there might be a better/simpler way to achieve the poster's goals than the approach taken by the question.

So, yes, you could conceal your code by compiling it into an intermediate language or using a code obfuscator, but there isn't any point IMO. If someone wants to see your original source code, they can just decompile it, and even commercial code obfuscators like RubyEncoder have proven easy to defeat.

I don't know enough about metaprogramming in Ruby to say with any confidence whether it will work for this application or not, but my gut tells me that the concept is likely as fundamentally flawed as DRM.

Answer 5

Obfuscation, on the surface, is a problem for metaprogramming. Consider the Rails framework. Ordinarily, a class named MissileLaunchCommand could just as well be named BananaEatingObject; the interpreter doesn't care. Rails, however, assumes suffixes like Controller and _mailer, so naïve obfuscation will yield a broken application.

Lacking bytecode, the most common ways to avoid exposing the source code basically revolve around providing services as opposed to standalone apps:

1. Offer a hosted version (e.g. github), making the source version much more expensive.

   These customers have no view at all of the logic behind the thing, and yet it works just fine. For those that have the cash, github::fi is a source distribution, but there are so few of them that the chance of leaking is minimal.

2. Develop your application as a native client to a "cloud" service (e.g. LitmusApp's Alkaline).

   Here you've transcended the abilities of your common web application, but your business logic remains protected on your own servers.

I am not aware of a shared practice for releasing a fully independent app in an interpreted language. Language-specific options (like RubyEncoder, mentioned by Lèse majesté) are out there.

Answer 6

There are 3 options of encrypting Perl code:

1. Use PAR to create executable file with PAR::Filter::Obfuscate or PAR::Filter::Crypto
2. Use Filter::Crypto::CryptFile (will require some modules installed on target OS)
3. Turn into module and encrypt into Module::Crypt.

Answer 7

Ruby might not be the way to go. You need to clarify what your project is going to do and what you want to accomplish.

Even compiled code can be reverse engineered, keep that in mind. Minifying/Obfuscating is primarily used to deter kiddie programmers - if someone wants to see/learn what you did, they'll take the time and walk through it.

There is no way to distribute the code w/o giving the logic. As an alternative, you can host the code from your servers and run the application locally, which doesn't sound like something you want. Otherwise, you're going to want to use a compiled language, such as C, which you will need to have different versions of based on the clients' environment.

Answer 8

Fully seconding the various "business model" observations made in other answers; if nevertheless you decide you really want to make it hard for users to read your sources, and that objective is worth the inconvenience, the first line of defense is to use a "packager into executable" that doesn't make it totally trivial to recover the bytecode -- for example, for Python for Unix systems, freeze.

Of course, even the best such tool won't make your executable any harder to disassemble and understand than any typical executable -- indeed, perhaps easier, since inevitably the code that the tool generates (typically C code that then gets compiled into machine code) is highly "stereotypical" compared to hand-written machine code... and even the code that's most craftily built to be hard to disassemble, understand and modify (especially popular video games) seems to be inevitably cracked very, very little time after release.

As I wrote back in 2006,

if you have secrets that are REALLY worth protecting, keep a tiny part of your app, embedding all worthwhile secrets, on YOUR well-secured server -- expose it as a webservice, or whatever, so the "fat client" (most of the app) can get at it. This truly gives you complete control: you don't care any more if anybody decompiles the part you distribute (which may be 90% or 99% of the app), indeed you can publish the webservice's specs or some API to encourage more and more people to write to it, and make your money by whatever business model you prefer (subscription, one-off sale, pay-per-use, your choice!). If you keep your client thin rather than fat, the advantages increase (your app can be used much more widely, etc), but you may need substantial amounts of servers and other resources to support widespread use.

When I started proposing this approach, years and years ago, the fact that your app can work only when connected to the net might be considered a real problem for many cases: but today, connectivity is SO pervasive, that all sort of apps require such connectivity anyway -- e.g, look at Google Earth for a "fat client", Google Maps for a "thin" one accessing a subset of roughly the same data but running (the client side) inside a browser (with more limited functionality, to be sure).

Answer 9

If you were doing this in Tcl, I'd recommend using the Tcl Dev Kit from ActiveState. It includes a "compiler" (really a bytecode saving engine; the compiler is the one built into Tcl itself) that lets you distribute code that can't be simply read, and a packaging system that lets you combine the saved bytecodes into a single executable file that most users can't defeat. It's not a perfect defense against the nefarious, but it does work well enough for most cases (especially where users aren't motivated too much to take things apart) and there aren't any pre-existing tools for doing that. I don't know whether there are other similar tools for other scripting languages.

If you only want to stop people from poking their fingers in, distributing some sort of packed archive form would perhaps do. For example, for most people a Java JAR file is just unreadable binary, despite being just a renamed ZIP (with a manifest inside). Moreover, that's about the limit of what I'd recommend for anyone doing this with open source software; you should not want to lock things down more tightly than that in that case!

Answer 10

For a Perl solution you can:

• Buy PerlApp from ActiveState and use it to package your apps as an executable bundle.
• Create a small C program that includes a Perl compiler and all your application source code. Unpack your Perl source in memory and then let the embedded compiler run the application. (Note: this is pretty much what PAR::Packer and PerlApp do).

A similar approach should be possible with any interpreter that is embeddable in a C application.

I have used both Par::Packer and PerlApp with great success.

If source code hiding is part of your goal, you will need to use one of the obfuscating filters for PAR. PAR packages are executable zip files, and are very easy to open up. PerlApp works pretty well to obfuscate code. I am 100% certain that a dedicated and skilled person could find a way to extract the code if it was worth their time. The good news is that there is a 99.99999999% certainty that it won't be.