Software Protection for MV applications – Part 1

There are several schools of thought about how MV developers deploy their software. Here is a summary of a few approaches to the task, and my own new solution.

Let’s face it, software protection is a major hassle but a necessary evil for many developers. With most commercial software, the developer wants to make sure he gets paid for his work, and licensing mechanisms are the only way to get that guarantee.

There are many ways to protect non-MV software. Some software is offered as trialware that goes dead if it’s not activated. Dongles and other hardware keys are increasingly used to keep software alive after payment has been made. Some software is called "nagware" because it nags (bothers, annoys) the end-user until it’s licensed.

Companies offer software protection mechanisms for hundreds to thousands of dollars. Because of the cost, and the fact that cost is not always commensurate with quality, many developers come up with their own custom algorithms. Then hackers post cracks and keys for software to get around such mechanisms, usually for the most popular and/or expensive software. Software protection (also equated to "security" though I try to keep the topics separate) is a never ending game between people who want to earn a living by writing software, and those who want to want to improve their own lives at the expense of others.

In the MV market, developers approach this topic much less rigorously. One group of MV developers is happy to install all source and object on end-user systems. There are a few reasons for this open policy.

• End-users are sufficiently disconnected that the chance of companies sharing code is very small.
• With business software most sites understand that they must pay for their software. They have no interest in giving software to other companies, not only because this is illegal and unethical but because this undermines the developers’ efforts to stay in business. If a developer goes out of business due to software piracy then there will be no more support or product updates, and everyone suffers.
• When the source is on the end-user system it’s easy to make code changes. This used to be one of the advantages MV developers relish over other platforms. This isn’t really a differentiating advantage anymore in a world where Open Source licensing not only mandates that end-users have source, but in a lot of cases you simply can’t create or deploy binaries, so you don’t have a choice but to leave the source on the target system.

Other developers prefer to have object-only on the end-user system. The obscurity of object-only is enough to keep the software from migrating to other DBMS platforms, but isn’t enough to keep the software from moving to another platform of the same type. In this case, the software is object-only mostly to keep end-users from poking at the code, but also to ensure that the developers have exclusive ability to maintain it. If the end-user stops paying for support, no one else can support it. So object-only distribution is a fairly effective means of implementing software protection. To cover for the "what if the developer gets hit by a bus" scenario, many end-users insist on getting the source code for their products put into escrow – where a third party guarantees the availability of the code in the absence of the author.

Application developers usually don’t put in a mechanism to ensure that their software only runs on one system. Their "security" is limited to user authentication, perhaps with a hard-coded table of the list of users authorized to login to the app. If their software finds its way to another site, some developers would consider it a compliment that someone felt the software was good enough to steal. Many developers welcome the opportunity to have their software "stolen" – more sites using it means more opportunities to provide services later. It’s not unusual at all in this market for a developer to find out that their software has been in use in some end-user site for years, and the end-user finally needs help with it. (The call usually comes from a new owner or a clerk who had no idea their company was running pirated software.) The usual protocol is to get the site on current licenses, get paid to address the current issue, protect the software so that it doesn’t travel to other sites – and then there is the occasional law suit or other remedy for license violations.

It’s usually the "third-party" tools that have the most extensive software protection mechanisms. The reason is that most tools are still based on the per-port licensing model. Some tools are licensed based on the total number of DBMS licenses and others have their own unique per-seat licensing. All of these mechanisms are different, developed by the same people who built the tools. ( As required, MV people pride themselves on being database administrators, business application specialists, tool developers, and security experts – it just depends on which hat we need to wear on any given day. )

To minimize strain on your eyeballs I’ve split this blog into two parts. This one is being published on November 11th. Part 2, with my solution and an offer to others facing the same challenges, will be published on November 12th. Please come back for part 2 !