How to efficiently protect part of an application with a license

Question

I am working on an application that has many functional parts.

When a customer buys the application, he buys the standard functionality, but he can also buy some additional elements of the application for an additional price. All of the elements are part of the same application executable. A license key is used to indicate which of the elements should be accessible in the application.

Some of the elements can be easily disabled if the user didn't pay for it. These are typically the modules that you can access via the application's menu.

However, some elements give more problems:

• What if a part of the data model is related to an optional part? Do I build up these data structures in my application so the rest of my application can just assume they're always there? Or do I don't build them, and add checks in the rest of may application?
• What if some optional part is still useful to perform some internal tasks, but I don't want to expose it to the user externally?
• What if the marketing responsible wants to make a standard part now an optional part? In all of my application I assume that that part is present, but if it becomes optional, I should add checks on it everywhere in the application.

I have some ideas on how to solve some of the problems (e.g. interfaces with dual implementations: one working implementation, and one that is activated if the optional part is not activated).

Do you know of any patterns that can be used to solve this kind of problem? Or do you have any suggestions on how to handle this licensing problem?

Thanks.

Answer 1

Actually, I am in a very similar position, managing the development of a product with a likewise license model, and a core database shared by different functions in our software.

What if a part of the data model is related to an optional part? Do I build up these data structures in my application so the rest of my application can just assume they're always there? Or do I don't build them, and add checks in the rest of may application?

I don't know your product, but in ours we deliver always the full data model. A data model per se (or any part of it) is no useful product function for any of our customers - a useful function is a process or operation on that data, which is part of the applications code. So we toggle the functionality only there. Also consider that a normalized data model tends to provide the same data for different functionalities.

What if some optional part is still useful to perform some internal tasks, but I don't want to expose it to the user externally?

I assume you are talking about parts of the data model - does it really matter if you expose it to the user, as long as all optional processes/operations the customer did not buy are switched off? And what does "expose" mean? If you mean "expose" at the UI level, then it should be easy for you to disable that UI. If you mean at the database level (because you give your users direct access to your database), then you can probably live with that.

What if the marketing responsible wants to make a standard part now an optional part? In all of my application I assume that that part is present, but if it becomes optional, I should add checks on it everywhere in the application.

To my personal experience, parts which are made optional are almost always parts the user can easy identify as separate functionalities. Otherwise marketing would run into problems to advertise that separate function. In most cases that means that those checks do not have to to be added "everywhere", but only at a handful, manageable number of places.

Answer 2

One thing that would be possible, as you mentioned it is having an interface with dual implementation, and using a DI container to conditionally inject the proper component if it is available. Simple and effective. You won't really need to add checks everywhere as this confines module management to a single place. This is obviously assuming that your system is designed well enough to profit from a DI container.

Answer 3

Sounds like what you need is a License or Product key. Searching google with "license key generator" will turn up a number of results, including this one if you want to roll your own.

Generally, you'll put a security / license check near the beginning of the licensed code path. Your callers will need to be able to gracefully handle a failed call due to not being licensed.

Ideally, you'll have some calls that check the license prior to populating the user menus. It's a lot harder for the user to select the "wrong thing" that they aren't licensed for when the option isn't even visible.

There are a couple of ways to solve the problem of areas where you need to use some licensed functionality within a standard function. Probably the easiest is to have two main paths into that licensed function. One path checks the license and is ultimately exposed out to the UI. The other path is not exposed and doesn't check the licensing either.

Similarly with the DB, you can have two paths to access the functionality. If some of the standard function really relies upon optional DB structures then keep them in place, but don't expose the access through the UI. Keep in mind that a DBA will still be able to tap into those table structures. Generally, it's the functionality you provide around the structures that's more valuable, not the tables themselves so that shouldn't be too big of an issue.

To deal with market changes on what's licensed or not, you can either have all major functionality go through the security checks described or just add them in later as necessary. I'd vote for the lazier route and only put the license check into standard functions if and when Marketing decides to go down that route.