We desire the ability to hide source code from prospective clients when doing demonstrations on their machines. We are interested in feedback / alternatives / criticism of the approach outlined below:
Split the application into two compiled installer packages, one with all of the open code. Second with stored macros which are actually large chunks of SQL and procedural code stored in compiled form in a catalog as stored macros.
Package one we give to our prospective client. Package two we retain physical control of, run the compile on their machine and delete the source.
The runtime log will show the macro calls rather than the code that is being executed. Voila - code is at least protected from source copying.
We have no solution to prevent copying of the compiled macros yet - would love to hear suggestions. At least they are platform specific and of course everything we do is under NDA anyway....
Very interested in comments from gurus or the curious.
Tying the package to the machine seems to be the best way to achieve copy-resistance, bearing in mind that any level of security or prevention you apply can be overcome by dedication, experience and time. A major issue will arise when a machine is replaced and another machine has to take over the process. If this occurs 1 hour before a mission critical batch process you'll have a very short time to meet the requirements of the client to maintain their system. This could prove to be very expensive for you.
Reconstruction of code within compiled macros is at least partially possible with options like MPrint and MLogic.
SAS/SCL is the only path that I have seen where code might be adequately protected, and some methodology employed to tie the compiled catalog to a machine.
I am really surprised that this capability - to protect own code from copying - is something that is not as developed in SAS as it is in Microsoft Access, where you can pretty much solve this problem without the expense of special add-ons.
Frankly this is a deficiency for anyone interested in developing commercial code using SAS as a base delivery platform. I am surprised how little objection is voiced by SAS programmers... and SAS marketing !
SAS/SCL is not a special add-on. It is a functional component of SAS which you can licence. It is a different language, if you like it is a different IDE and I can think of any number of applications and packages that provide a selection of IDEs and interfaces in exchange for a licensing fee.
SAS was developed to a different paradigm, it isn't like Delphi or Oracle where the main drive is for application writing, but was built for data analysis.
I didn't think the M$Access solutions could be tied to a specific machine, or copy protected, and I also don't think its functionality comes anywhere near SAS in terms of reliability, data handling and functionality.
I also realise I had forgotten that early on in the data step, the capability to compile a data step was added. If you look up the SAS documentation it should assist you.
Thanks for this advice. I may be a bit simple but an additional component is an add-on to me. At least it means additional cost which is what I really meant. Sorry if I was unclear.
All I want is a simple way of copy protecting my proprietary source code and re-engineering my work. I am much less concerned with people copying my compiled code because it is strictly a B2B product and a straight bootleg copy is unlikely to be acceptable to my customers (banks).
My question was whether or not compiled Macros would help meet my needs. I think the answer is emerging as "sort of". I think there is an opportunity for product improvement here. If no-one else develops on Base SAS for commercial purposes I am wrong... though it seems unlikely this could be so to me.
There are quite a few commercial products that were/have been/are built on Base SAS. One is MICS; another is MXG -- both computer performance software packages. MICS was purchased by CA, but originally written by Morino Associates -- originally built on SAS macros. (I don't know whether CA has changed it.) I vaguely remember being able to see the source code of the macros -- and thinking "worth every penny." It NEVER would have crossed my mind to try to duplicate their effort.
Ditto for MXG -- all written in SAS macro. Open code -- all of it -- and on their web page, they have a "thank you" page for the code sharks that have found places in the code that could be improved -- whether it's a typo in a comment or a real code change.
The only thing about stored compiled macros is that you'll have to recompile them on every system -- they are not portable across varying platforms.
Thanks Cynthia. Sure wish everyone was as ethical as you. I appreciate the information - I should probably contact them to see if they would be willing to discuss their experience with this issue directly. Good tip, thanks !
PS the lack of portability is actually a good compromise for us - hinders portability between clients but portable enough if a client is just swapping out machines. We'll be doing the initial installs so they will have locally compiled macros sans source on their machines. I hope this approach proves to be manageable.
Update: At last with V9.2 there is a function that will enable security over stored macro code...the SECURE function is supposed to address the need by using an encryption process presumeably unique to SAS.
Unfortunately this feature does not enable integration of stored macros with licensing software / hardware packages that track and enable usage within specified paramteters such as to-from dates, number of users, number of uses etc.
Until this is addressed it will remain difficult to consider SAS a meaningful software platform for commercial application development. We are working on this problem (right now trying to figure out how to integrate WIBU security into macros). If anyone has experience or suggestions on best way to do this please comment !