DRM - Make sure that a SDK is used by the client legally

Question

We are an IT startup which provides some clients with a Software Development Kit, which may be used by the client within a specific environment, according to some terms and legal agreement. Especially, the client could call SDK's public services and methods from its own source code.

For example, the agreements may require that the client may use the SDK only in ONE environment (in an application for example).

Thereupon, we would like to monitor the SDK to ensure that the client respects this constraint, and if he use the SDK in an environment he didn't buy the SDK for, we want to be able to block the access to the SDK, so he couldn't use it.

I do know that several companies implement such features for the frameworks and SDK they provide, but I couldn't find anything on the web on how to set up such a mechanism ...
We would like to use some standard solution, even it is a paid one, rather than building something from scratch ...

Thanx very much for anyone who could enlightens us !!!

Clarification/Update Our SDK does not provide web services, it provides only local methods which client may call after installing the SDK.
Actually there is only one http-request-based method in the SDK. It's the entry point of the SDK, a method which is called setUp() which takes essentially two parameters : client's username and password.
So foremost the client has to call this method, which check out his credentials through http request to our server. If the authentication succeed, then the client may use the SDK local methods, otherwise he cannot.

Edit I just discovered the concept of API key, at first I thought it would be a potential solution for this problem, but it appears that it doesn't suit the context of the issue I'm trying to solve, thanx to @Matthew.
Now I'm wondering if a license enforcement would be a suitable solution ?? Actually I am thinking about the way Aspose team handles the licenses they give to their clients. Following to this link, they seems to manage DRM rather tightly ...
And one last thing, what is the difference between a license and a product key ? Knowing the advantages and drawbacks of each of these solutions might help me a lot for choosing the right security system for my API.

Answer 1

It's essentially a legal problem - you want to control what is running on a client's device, which means you'll need the co-operation of the client.

For a company providing a web based API (e.g. your SDK does some kind of interfacing with your web based service, possibly by implementing some encryption, or special transport method), this is down to monitoring the service, looking for unusual patterns. You could bill on a per request basis (don't care where the requests come from, but if they suddenly start using more, you get more money). You could look for changes in key elements being sent (if you're suddenly getting data reflecting both Windows and Linux hosts, you can be fairly sure the client is using two copies on different systems, and block one).

In your case, though, based on the question as it stands now, you have no interaction with the individual requests (you interact once, when they initialize the framework, but then allow use through some method). It's like your SDK is an image file which the client has been asked to only use in one place. If the client copies it, you don't know. If they run it on a different machine, you don't know. If they run multiple applications on a single machine all using it, you don't know.

So, what are your options?

1. Hardware dongle. Done properly, they restrict the use of software to a specific machine. This generally requires moving parts of your software into the dongle, else it becomes trivial to strip out any checking code from your software. This also doesn't prevent multiple applications on the same system from using the software - if it can legitimately be used from one, it's possible to copy the data being sent to the dongle from another.
2. Change your model to be web/network based. Now you can see what's going on, but you may limit the uses of your software. Depending on what it does, it might not be suited for the latency this would introduce, or there may be limitations on where your client's data can be sent (e.g. EU data to US servers can be problematic, at times).
3. Change your pricing model. Allow clients to use the software as much as they want, but charge more up-front. Make the software free, and charge on a support basis. Charge less, to encourage people to buy multiple copies if they use it in multiple places. These are all models that various companies use, to varying degrees of success.
4. Be really selective with clients. If you don't trust your clients to abide by your licensing terms, the only really sure way to prevent abuse is to only let people you do trust have access. Require third party "running software" audits on client networks, looking for abusive use of your code. I've never seen a company succeed on a large scale with this model, but it can apply to some specialist areas, such as sensitive control systems.

Some big companies have used some of these: Microsoft, for example, uses ongoing web based authentication - after an initial check, Windows/Office apps ping home every so often to see whether they have been deauthorised. Red Hat charge for the software (but you can get most of it for free), but they charge more for the support, and they check licensing details with support requests. There are some specialist software packages (especially in academic fields) where you only get access to them after attending training on how to use it, which is essentially a form of being selective with clients - the theory is that it cuts down on "trivial" questions from new users. NXP (a large semi-conductor company) offer dongles for some of their development tools, on the basis that not all users have network connectivity.

Depending on how your initialization code works, it's even possible that a really unscrupulous client could simply look at the return value from your servers, and provide that themselves - this would be the case if the method returned a true/false response when provided with a username/password combination, but also if it returned some fixed or predictable value (hash of the current time, or a pre-determined string).

Answer 2

@Matthew 's answer above is very good, but omits a suggestion that has worked for centuries: contracts.

Write your sales contract to restrict usage in whatever way serves your business interests best, and in the contract state that you reserve the right to use web messages to monitor compliance with the contract, and provide for additional charges or contract termination for usage outside of the license terms. Consider including language reserving the right to remotely disable your SDK in case of non-compliance. Your lawyer should be able to draft an acceptable set of terms.

While you probably won't be obligated to specify all the data you'll possibly collect in the contract, you'll want to include encrypted identifying data such as the user ID, MAC, IP address, computer name, CPU serial number, installation ID#, contract/license #, application name, version, project/file name, date/time, # of lines processed, etc. These are all things that can be shown in court to help verify your claim that your software is being used beyond the terms your clients agreed to.

It's then up to you to monitor for changes in usage patterns that may indicate a contract violation. Instead of calling the corporate lawyer, though, I recommend first engaging your sales people to contact your clients and offer them license terms with increased capacity. It's generally more profitable to extend your clients a carefully worded sales pitch than to threaten them with lawsuits.