Best Way to Distribute a Custom SQL Server Database Application

Question

I have an SQL Server 2016 database that I would like to package as a commercial application that I can then distribute to my customers. I'm just not sure how to package it and am hoping that someone can provide some sage practical advice ...

Ideally, I would just like to give my customers a DB restore file (or perhaps some other executable package) that would copy the application onto their existing SQL Server implementation. The tricky parts that I don't know how to address are:

1. How can I secure the source code for the stored procedures and functions that contain my proprietary IP so that the customer can't see the code? I don't mind (and actually prefer) that my customers be able to view the tables and views.
2. How can I incorporate software licensing for my application so that it is only functional as long as they pay their maintenance/license fees?
3. Eventually, I might want to replicate the same application for Oracle users so it would be ideal if the same approach worked on both platforms

Any ideas?

Answer 1

(Warning: this answer contains needless editorialising, but it's Saturday night)

How can I secure the source code for the stored procedures and functions that contain my proprietary IP so that the customer can't see the code?

Strictly speaking, you can't.

And DRM or IP-protection system where Bob and Charlie are the same person is doomed to eventual failure because Bob (the user) must have the decryption key to view the protected content, which means Charlie (the same user, e.g. after their license has expired) must also have the decryption key. Presently the only effective DRM on computer systems still used today (e.g. Widevine for media, various DRM techniques for games) uses OS-provided content protection support or third-party kernel-mode driver packages, which is why you never see effective DRM for Linux-based OSes.

Such as it is, code running in SQL Server cannot use OS-provided DRM functionality.

You can use WITH ENCRYPTION - but any server admin can simply attach a SQL Server debugger (such as SSDT's) to the stored-procedure as it runs and view the decrypted stored-procedure in-memory... or just use a freely available decryption tool.

How can I incorporate software licensing for my application so that it is only functional as long as they pay their maintenance/license fees?

There's an entire industry of DRM providers that all have their own techniques for this. A couple of decades ago there was a thriving industry of small companies providing DRM services to software publishers (like what Adobe, Macromedia and others used to "protect" the time-limited demo versions of their $600 software titles) but that industry is dead now because as I said above, it's literally mathematically impossible to implement this and a determined adversary can get around it easily. (And by "determined adversary" I mean an adept middle-school kid armed with a copy of IDA Pro).

After the backlash against draconian DRM systems from legitimate consumers in the mid-to-late-2000s when software publishers used their own kernel-mode DRM systems that, naturally, had bugs and caused data corruption, indicated false-positives and false-negatives, DRM just lost popularity with line-of-business software vendors - in the end it just isn't worth it for line-of-business software (not forgetting the guerilla-marketing approach of actually letting people pirate your software so it attains market dominance, mindshare, and leads to more paying customers - conspriacy theorists like myself believe Adobe tolerated Photoshop piracy in the early-2000s which led to the massive userbase they have today which they're milking quite successfully through Creative Cloud).

Of course, in ye olden days (1980s-1990s) expensive software used hardware dongles - those are still a thing, but again, can be easily cracked just by modifying the original software to skip the JNE instruction that checks for a hardware dongle - and of course, you have no way of accessing hardware dongles from a SQL Server sproc.

Since the early 2010s, with widespread always-on Internet connections, more and more software, including mission-critical line-of-business software is made available exclusively as web-applications over the Internet where DRM isn't a concern. Depending on how your application works, this may be an option

One product I built recently performs "proprietary" analysis of on-premises customer data - it works by having a small program that runs on the customer's database server computer and reads data from their database program and does some quick aggregation before sending it to our cloud-service where we process their data and make it available as a web-based reporting service. Incidentally, we aren't using this technique to make our analysis service immune from cracking and unlicensed users, but because our users asked to be able to view their reports from their phone, tablet or when out of the office - something that simply can't be done if it's running as an on-prem program on their database server (and no sane sysadmin would let us, or anyone else, run our own web-server and set-up port-forwarding rules and dynamic-DNS just for our reports).

Eventually, I might want to replicate the same application for Oracle users so it would be ideal if the same approach worked on both platforms

I think you're a tad naïve - not least because of the massive incompatibilities between PL/SQL and T-SQL - Oracle has an empire to maintain.

Finally, I note that the providers of our own platform: Microsoft, doesn't even attempt to obfuscate or encrypt their own proprietary binaries - you're free to poke through any of the .NET Framework assemblies using RedGate Reflector or ILSpy - and this extends to CIL assemblies of their expensive products like Exchange Server, Team Foundation Server, and so on. At the end of the day, a bunch of curious users isn't going to break your business-model, and if your business depends on some secret-sauce algorithm contained in a couple of SQL Server stored procedures then your business model isn't one worth keeping alive through artificial means - because even if people couldn't see inside your sproc's source-code it's often straightforward enough to black-box reverse engineer your super-special algorithm and publish it as a competing product at half the price, drive you out of business, while all being 100% legal.