The way that you protect your Ruby code is usually by not giving it to anyone. If you provide software as a service, and you keep the secret sauce on your server, that's the ticket. If you want to sell the source code to your customers, guess what -- they can read it, because it's not a compiled language.
Walter
Don't dismiss the contractual agreement - pushes the problem to your legal people.
Another idea is providing the software on a virtual machine image. It has the benefit of being a packaging mechanism too.
Peter
I believe the best method is to use Jruby and to produce a compiled WAR file, combined with some sort of external encrypted licence file..
--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-talk/-/yqiGqNuSLwQJ.
To post to this group, send email to rubyonra...@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-ta...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Sorry, no -- WAR files are not "compiled", and they're nearly always
expanded at deployment anyway, so that's pointless.
--
Hassan Schroeder ------------------------ hassan.s...@gmail.com
http://about.me/hassanschroeder
twitter: @hassan
"success" at what? Yes, you can certainly run JRuby/Rails from a
WAR file. I'm maintaining one such application now.
This does *nothing* to prevent access to your app's source code, as
the OP is seeking to do.
> I remember reading a long time ago that Thoughtworks have devised a method
> of code protection for their Mingle product, using JRuby. I don't know how
> its done though.
There appears to be a free download -- you could take a look and
report back :-)
(I would but I'm about to shut down to head to the airport.)
> But there's gotta be a way, no? As I understand it, although the WAR file
> code can be viewed it can't be changed.
Sorry, that's not true. A WAR file is just a packaged (equivalent to tar)
directory structure that's usually un-WAR'd on deployment. And you
can do anything you want with the contents at that point.
Sorry, that's not true. A WAR file is just a packaged (equivalent to tar)
directory structure that's usually un-WAR'd on deployment. And you
can do anything you want with the contents at that point.
> Could you give me a reference to building and deploying a WAR for a ruby web
> app? thanks.
Are you familiar with the Servlet Spec? If not, I'd strongly recommend
reading it to understand how a Java web app (and hence a WAR file)
is structured.
http://rubygems.org/gems/warbler provides the building part, at least
for a basic app.
The deployment part somewhat depends on what servlet container
you're using, so check the relevant docs. Alternatively you can use
something like capistrano with custom recipes.
HTH,
> JRuby has the ability to *actually compile* your ruby code into
> java .class files.
Which, it should be pointed out, can be easily de-compiled to reveal
a pretty decent representation of your source code :-)
The OP should note that pretty much all companies distributing their
software to end users use licensing agreements to protect proprietary
IP, not just obfuscation (via e.g. compilation).
FWIW,
Which, it should be pointed out, can be easily de-compiled to reveal
> JRuby has the ability to *actually compile* your ruby code into
> java .class files.
a pretty decent representation of your source code :-)
The OP should note that pretty much all companies distributing their
software to end users use licensing agreements to protect proprietary
IP, not just obfuscation (via e.g. compilation).
FWIW,
--
Hassan Schroeder ------------------------ hassan.s...@gmail.com
http://about.me/hassanschroeder
twitter: @hassan
Its no different than what you do with a regular Java app now ...or
Flash, or C, or Objective-C, etc.
There are things you can do to obfuscate your compiled code but that
too *can* be reversed.
Nothing is fool proof, but providing compiled .class files beats they
hell out of handing them your source code in clear text.
On Oct 12, 2011, at 9:18 AM, Hassan Schroeder
<hassan.s...@gmail.com> wrote:
On Oct 12, 2011, at 10:35 AM, Brandon Black wrote:
> On Oct 12, 2011, at 9:18 AM, Hassan Schroeder
> <hassan.s...@gmail.com> wrote:
>
>> On Wed, Oct 12, 2011 at 1:45 AM, Brandon Black <brando...@gmail.com> wrote:
>>
>>> JRuby has the ability to *actually compile* your ruby code into
>>> java .class files.
>>
>> Which, it should be pointed out, can be easily de-compiled to reveal
>> a pretty decent representation of your source code :-)
>>
>> The OP should note that pretty much all companies distributing their
>> software to end users use licensing agreements to protect proprietary
>> IP, not just obfuscation (via e.g. compilation).
>>
>> FWIW,
> That's totally correct, but true with anything you compile and release.
>
> Its no different than what you do with a regular Java app now ...or
> Flash, or C, or Objective-C, etc.
>
> There are things you can do to obfuscate your compiled code but that
> too *can* be reversed.
>
> Nothing is fool proof, but providing compiled .class files beats they
> hell out of handing them your source code in clear text.
----
Perhaps it is just my commitment to open source but if nothing else, providing the complete unaltered and unobfuscated source code adds substantial value and I suspect that if you have priced your efforts appropriately and demonstrated your value sufficiently, that there really isn't any need to obfuscate at all in most instances.
Craig
Totally. Theres huge value in that and if the situation permits I'm of
the same opinion.
When I buy products for my current company I prefer to buy ones that
also deliver source code so I can tinker at will.
However, doing so you do obviously open yourself up to having a
competitor buy your code, sometimes indirectly, and groking from it.
I wouldn't trust the patent system to protect you these days. So, if
you're going to release source with your product, make sure your
licensing and price model reflect that risk.
I think the OP was asking the question though with the intent of not
giving out the source.