Restricting access to cgi source

pernod has asked for the wisdom of the Perl Monks concerning the following question:

I am working on a web application written in perl on Windows/IIS (ick!) with an Access database as a back end. I am a consultant, and we make money selling risk management services. The application is a tool to support the risk management process, and our take on this is quite novel.

One of our customers wants to install the application on one of their servers outside of our controlled network. The problem is that we can not (as stated by our customer!) trust the users on the server, and we do not want someone to just copy our hard work and sell it as their own.

We do of course have a license to protect ourselves, but we feel that we need a technical barrier too. This is the meat of the question, so please pardon the long-winded introduction.

We have thought about using a standard obfuscator to mangle the code, but this is not enough. We have also considered perlexe (the page is unresponsive at the moment) or somesuch, but we are not sure of the implications of using such a tool. Additionally, there is a chance that the application will be migrated to GNU/Linux with MySQL (yay!). Are there compilers that work consistenly across several platforms?

We have also thought about implementing a wrapper to the perl interpreter. The idea is to encrypt the sources and decrypt them on the fly before sending them to the interpreter. This of course, raises a lot of issues regarding efficiency, and some questions on how to transfer the cgi environment correctly from the wrapper to the perl interpreter. Lastly, the choice of cryptography is also an issue, as the country to which we want to export is not a covered by the Wassenaar Arrangement, that covers exports of strong cryptography.

I presume there are many more sides to this problem than I have presented here, and will greatly appreciate any tips, musings and comments.

I am also aware of the fact that many people will find our wish to close down our source to be Evil. I firmly believe in freedom of information, but the application in question is the result of hard work in an extremely competitive market, which means that we have to keep our cards close to our chests.

pernod
--
Mischief. Mayhem. Soap.

Comment on Restricting access to cgi source

Replies are listed 'Best First'.
Re: Restricting access to cgi source by derby (Abbot) on Jan 27, 2003 at 16:36 UTC
At the risk of offending the more chaste monks, why bother using perlexe (or any modified interpreter) to do this. Pay your dues and leave the open modules open ( CGI.pm - right? right!, DBD, DBI, whatever else). Take the subroutines that are your core algorithms and re-write them in C. You can then utilize XS or Inline to create platform dependent modules that can be delivered as thin wrappers around dynamic library(ies). There are some issues with this You would have to invest in a development environment per platform you support. The devel enviroment needs to match, exactly, the environment that built perl. Object code can be reversed engineered too. I think that's going to be your best approach. If you think you don't have the skills to do this "core" shared object approach, please feel free to contact myself or any of the other monks here - I'm sure any of us would be happy to help for a slice of the profits. -derby	[reply]
Re: Restricting access to cgi source by l2kashe (Deacon) on Jan 27, 2003 at 13:40 UTC
My 2 cents While I don't like the idea, you current market situation is understandable. So on that note On the whole compilation issue. I dont believe that you will be able to compile once and deploy. More than likely you will need to compile at least once for Windows platforms (possibly more, I don't devel on that platform so I couldn't tell you), and more than likely you will need to compile per Linux/Unix variant. Which leads to all sorts of other issues, but thats a different post. On the whole obfuscation, I think you are going to take a serious performance hit on munging/encrypting your code and demunging/decrypting during execution. (I think even if it is a persistant process, where you only decode once, and run forever, though that may lessen your hit). To the point that your product wont be near as responsive as it is now, and may infact end up worse than a competitors. This is something I have looked at and reviewed many times, as I was considering consulting and providing "glue services" for lack of a better term. I finally came to the point where I decided it is in the customers hands in my situation. I.e They hire me, I state they can A) purchase the code outright, with provisions for me to reuse the code, but never the exact tweaks I provided for them (this costs more for them), or B) They can simply use the code, but it belongs to me and I can reuse at any other site I see fit. This isn't exactly the situation you are in. If it is really important that others not get your code, then you need to think long and hard about who to give it to. If you need to jump through flaming hoops, in order to appease a small percentage of your client base / possible client base, and it detracts from the time you will spend inproving the product and adding features, then is it really worth it? Theoretically you could implement your own perl interpreter (see the panther book Advaced perl programming for a reasonable intro into how), and then add custom ops and checks into the interpreter itself. But thats more security through obscurity, which isn't usually good. So I guess I don't have alot to add aside from, I feel your pain, and maybe you should reconsider how much control you really want to relinquish to your client base. You should be in a position where you can say "Im sorry, but that is an unacceptable use of our software. If you would like we can add another server, but we must retain control of the code". On another note. You could allow the customer to install the code and CYA legally by requiring an NDA, but that just makes me shudder. It is an option though, and one which has had many legal precedents behind it. You could have it drafted up by a legal type and then provided all people who will be viewing the code have signed the NDA and also agreed to not distribute your code base not replicate, you could allow them to install it on whatever hardware they want. /* And the Creator, against his better judgement, wrote man.c */	[reply]
Re: Restricting access to cgi source by JamesNC (Chaplain) on Jan 27, 2003 at 15:43 UTC
How about including a statement in your code as Larry Wall suggests? Something like. `Perl is the copyright of Larry Wall. This program is the artistic work + of Mischief Mayhem and while Larry and the authors of all the other +modules that my application uses don't mind me making money from it, +I am scared of the idea that you will steal my work, so don't. Copyright "Some Scared Dude, Inc." 2003` [download] Or, you could just code like me... hell anyone that tries to use my stuff would just end up scratching his head anyhoo...	[reply] [d/l]
On open sourcing your applications by merlyn (Sage) on Jan 27, 2003 at 16:01 UTC
but we feel that we need a technical barrier too Just consider this: How much money would you be making on this contract if Perl was not open source? And you want to be so friggin arrogant as to lock up your source? You stand on the shoulders of giants and drool onto their face. Be gone, arrogant fool. It's not a matter of not making money. I want you to make money with Perl. Gawd knows, I certainly have. But what about the poor maintainence programmer who comes along after you've already gone off to better and bigger things? By locking up your source, you've effectively robbed him of a chance to help your current client. Who died and made you king of the world to be doing that? Again, especially with the fact that you're using open source software in the first place! Or are you claiming that your code will never require maintenance? Dude, I've never written a program that I didn't edit later. -- Randal L. Schwartz, Perl hacker Be sure to read my standard disclaimer if this is a reply.	[reply]
Re: On open sourcing your applications by l2kashe (Deacon) on Jan 27, 2003 at 16:24 UTC
I was thinking after my previous post, that irregardless of whether the source is open or closed, if the end product is good, or fills a niche, someone is either A) going to extend/refine it, or B) recreate it in some shape or fashion So given your feelings, how would you suggest they go about making money off their creation, without losing their edge over the competition. I personally am adamantly for open source, but alot of people out there aren't. You have been in this field a long time and more than likely have garnished a bit of wisdom over that time. Can you provide suggestions in regards to a (better\|different) way to handle this given scenario? /* And the Creator, against his better judgement, wrote man.c */	[reply]
•Re: Re: On open sourcing your applications by merlyn (Sage) on Jan 27, 2003 at 16:34 UTC
Yes. In very simple terms, be good to your customer, and they will pick you for the followup work. If you treat your customers like children, by locking up source, and nickeling them to death, they will rebel like children. -- Randal L. Schwartz, Perl hacker Be sure to read my standard disclaimer if this is a reply.	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.
Re: Restricting access to cgi source by mattr (Curate) on Jan 27, 2003 at 16:12 UTC
"an Access database as a back end" .. "we make money selling risk management services" .. "our take on this is quite novel". Heh. Sorry, had to! Presumably you just are wanting to obfuscate your perl in some way. Maybe Extutils::Embed or perlembed will help. Looks like line noise to me! (Caveat.. I never touch the stuff). You could also put it in an encrypted filesystem and decode it to ram but it all seems very iffy (experimental maybe not so secure) and maybe not legal. You can certainly decrypt things to evaluate into a standard perl program, but where do you put the key? Maybe if you hid half of it on your own server, and convinced them it has to contact you to run (once each time the mod_perl restarts). Maybe now is a good time to start a web app. service provider, or perhaps just a little SOAP::Lite? That way they think they're getting the code but the part that does the job (the code not just a key) stays safe with you at home.	[reply]
Re: Restricting access to cgi source by jacques (Priest) on Jan 27, 2003 at 13:40 UTC
Perl Encoder might help. Also take a look at: Acme::Bleach	[reply]
Re: Restricting access to cgi source by mattr (Curate) on Jan 28, 2003 at 14:33 UTC
A followup - Yes I do think it is easier to leave it open. For me, providing source code is a sales point. But, there is a mention about this actually on slashdot just now. Macrovision (the video tape copy protection people) apparently bought out this company that makes flexlm. I have no experience with it, the website is a little opaque and corporate speaking, it has been cracked (though the crackers have been sued out of this dimension), and someone on the thread said it was crappy. Buuut, it might do what you want. That said my guess is you still need to have a server somewhere else, and maybe compile the program into an obfuscated format which is probably a b*tch.	[reply]