Encrypting Stored Procedures Doesn’t Make Me Avoid Looking at Your Code

Dear Vendors that encrypt stored procedures in SQL Server,

Stop It!

We were having a discussion on Twitter about vendors encrypting stored procedures recently, and this justification came up that had been told about why vendors encrypt stored procedures some times.

To this I point out, that if you’ve encrypted your code so that I won’t look at it by accident, you are actually getting the exact opposite result. Because you are encrypting code that means that I can’t see if. That means that I want to make sure that you aren’t hiding any stupid practices from me. That means that as soon as I see your encrypted procedures I’m decrypting them to see what is going on with this code.

Along with this, because you’ve bothered to encrypt the stored procedures that means that I can’t get an execution plan, and query store can’t be used for the queries within the stored procedure. And since I’m guessing that I can performance tune your database better then your developers can, I’m going to be decrypting the procedures so that I can tune the system.

But It’s Our IP

Another reason that companies have for encrypting stored procedures is that the code is their IP. Does the vendor have a patent or trademark on their code? The answer to this is no, as you can’t patent or trademark the actual code, and anyone that tells you that they can trademark their code, is wrong.

If you have given me your code, then I can look at it. If we have an NDA in place then I can’t use the code. If there’s no NDA in place, then I can use your code all I want. You at that point have no legal way of stopping me.

If you want to stop supporting the software that we have purchased from you, is there something in the EULA about us not decrypting the stored procedures? No, then support it or get risk getting sued for violating the EULA and support contract. And assume that you’ll be loosing us as a customer and that your competitor will be gaining us as a customer (yes I’ve done this at companies, so it’s not an empty threat).

Running Code

When you sell your customer a license to run your software you are giving the customer your code, and you have to trust the customer to not use your code in order systems. The customer has to trust that you are providing them a system that will perform well. You usually don’t and someone has to to some performance tuning on the application that you provided in order to keep their business up and running. If you hamper or slow that process down, expect to have your application replaced in short order. No application is so critical to a business that it can’t be replaced, so make it so that your application doesn’t make the live of the people that have to actually maintain it suck less.

Denny

Share

Share on facebook
Share on twitter
Share on linkedin

One Response

  1. I am a developer and starting my own Database/Web development business. I read your article and, the section I cannot (and don’t have to) agree is where you say “…you are giving the customer your code.” I am sorry but, when I buy a plate at any restaurant, I am not given its recipe. When I buy a car, I am not given their full design sheet. When I buy any non-open source software, I am not given the source code (nor should I ask for it to be given to me). Any product I buy, is not entitled to include their source, design and architecture that explains how the product is built or functions. I only own the finished product to be consumed. Of course where it may differ is, if were to develop a system for your business as an employee.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trust DCAC with your data

Your data systems may be treading water today, but are they prepared for the next phase of your business growth?