Securing code against change by licensee

Here's a situation I face, which many other PHP developers must also face. I'm interested in how others solve it.

My employer has developed an application which we are beginning to license to customers. The price of the license is computed per seat per server. That is, if you want to run the product on one server with up to 75 simultaneous users, you pay 75*x dollars. If you add a second server with up to 50 simultaneous users, you pay 125*x dollars.

We  need to (1) verify that a customer is running the application on only the licensed number of servers, (2) prevent more than the licensed number of simultaneous users from using it on each server, and (3) ensure that the customer has not changed our code to evade the license restrictions without letting us find out

There's a fairly obvious answer to part 2, but I'm not convinced that it's the only answer or the best one, so I'd like to hear the thoughts of people who have dealt with every part of this problem.

The problem is complicated by the fact that customers may have legitimate security arguments for running the product on a system that is not attached to the Internet, which would prevent us from getting any type of on-line access at all. I'm not insisting that we have to accept that; but we may have to be able to offer them alternatives that satisfy their concerrns as well as ours.

Probably not really what your wanting to hear but we resolved this same issue where I work by selling our software as part of an entire system. ie; We actually sell and then maintain the server OS and all the software installed on that system.

Of course this open up a whole new can of worms as we have to actually maintain these systems now. Everything from our software updates to security updates for system software.

While technically our clients could mount a drive from these servers and gain access to the software that way, there not generally technically minded enough to do so (and of course this would break there license agreement that they have payed a substantial amount for).

We have done a similar thing aswell, supplying hardware and software together under a lease agreement, only giving the client access via CMS, due to the fact if the client owns the server, they have root access and the ability to access any file on that system.

Thorpe: When you say mount a drive from the server are you referring to actually removing it and mounting it in another system?

Thorpe: When you say mount a drive from the server are you referring to actually removing it and mounting it in another system?

Not necessarily, they could quite easily execute a Linux live CD and mount the drives from there.

It's always good to hear about others' experience, but you're right, thorpe, that's not what I wanted to hear    in the sense that it doesn't apply in our situation. we will also BE bundling hardware with software, but our customers will tend to be large technology companies, so if one of them decides to hack the system, lack of ability is not likely to be an issue.

I'm thinking about using PKI technology to "sign" the source files so that we can tell if they've been changed, but I haven't had a chance to work out just how to do that.

Depending on the particular application / code, you could set up an API System where they would have to access your single script located on a single server through the API with their API Key to pass various variables through to allow your script to process post / get requests.

The system wouldn't really be complicating and you could keep a list of all API Keys in the database to query against to make sure a particular person or company has a License to access that script.  A bit more dynamic programming and you can limit how many concurrent users would be allowed to access the script from a particular website / API Account, but it would have to be dynamic as other sites would also be able to utilize this.

You would absolutely have to have it set up on SSL and only accept incoming calls from HTTPS:// to prevent any eavesdropping, you may also want to ensure the clients using the API System also have SSL for extra insurance against it.  You may also want to find a good way to make sure it is only being called from a Single Server per API Key, so if they wanted to pay for a second server they would need a second API Key to access it.

You could Encrypt your code with Source Code Encryption Software, but they have been reversible for quite some time now so people with a higher intellect on technology could get your Source Code from it, so the best option to make sure no one is able to circumvent your licensing system is to set up the API.

Of course people would be required to have Internet Access on their servers to utilize it.  This would also increase Bandwidth Costs and won't be as clean as if you just gave the Application to the Client, so pricing structure may change a bit to cover the extra costs.

The real question you have to ask yourself is:  If people were to Circumvent the Licensing System, would you happen to lose more money with the circumvention or would you lose more money with the API System and Bandwidth Consumption.  The Encryption Software can be a bit pricey and still doesn't 100% protect your Source Code / Licensing System from circumvention, plus the Client would need to add a Mod onto Apache ( if this is a PHP Application ) to decrypt the encryption if it isn't already included on their Hosting System.

Have your Employer run some simulated loss projections from the three methods.  Go with a 1%, 5%, 10%, 25% loss projection which states that the percentage of people have circumvented and are using your Application for free.  Find out how much output the application would cause in Bandwidth and estimate 10% , 20%, 25% , and 50% of the bandwidth usage would be from First Time ( Full Bandwidth Load) and the rest are concurrent users who have cached some content for use.  Also if you go with Encryption, include the cost of the Encryption Software in with the loss projections.  If you have a feeling that your system would be very popular, like CometChat, you may also want to flop the loss projections around where the majority are using Free Versions and the minority are using Paid Versions... I do believe, before Adobe changed their system for Licensing for their Creative Suite Products, that more users were using Free Versions of let's say Photoshop than those who had paid for it.

Unfortunately with PHP and some other Programming Languages it is a lot harder to protect your Source Code from users who want to use it for free.  Even with C++ and other languages which are compiled before use, not during use, there is always the chance for Reverse Engineering, but that is likely to happen and doesn't really cause any losses for your company per say.

Hope this is helpful, I figure the best chance of securing your Licensing Arrangement would be the API System but it could potentially prove to be the bigger factor of Losses unless you increase cost per user to cover the additional Bandwidth / Server costs.

Jumpy09, I'm not sure I understand the API calls you're talking about. Do you mean that we should create a sort of license server on a computer under our own control and require each customer's server to get permission from it before allowing a user to log in? If so, I don't see how it would address the fundamental problem: that a licensee could hack the code to support excess users, or run on excess machines, while all of the information we received would indicate that everything was on the up-and-up.

Some of your suggestions imply that you're thinking about a product that occupies a very different market position than ours. They're valid suggestions for products that fit the profile you have in mind, but our profile is different. We're selling a very expensive product that will never have a lot of licensees, but most of those licensees will be large businesses with many concurrent users, all of whom are employees or quasi-employees (e.g. consultants).

API is where you own the only copy of the Application / Script and allow Licensees to access it remotely using iFrames, Javascript, cURL, or other methods to obtain information.  As I mentioned this would increase your bandwidth consumption and if you ever decided to close down the project, your Licensees may be entitled to obtain a copy of the code since they technically paid for it.

That is what I meant by API, not they have the Source Code and then call your server for the permission.  They never obtain the script so they never have the chance to alter how the licensing system works.  I figure a bit more work would be required to allow this potential to be a realistic implementation, but with PHP Applications you don't really have much of an option.

Jumpy09, it appears to me that you confirmed my interpretation of "API" in the first paragraph; then in the second paragraph you said you meant something else. There's a missing piece somewhere in this picture, and your suggestion isn't going to make sense to me until we figure out what it is.

I'll restate your suggestion as I understand it: the licensed system is programmed to communicate with a component on our server at critical times, i.e., when a user logs in or out. That component tells the licensed system whether or not the log-in is allowed.

If that is correct, it seems to me that a licensee doesn't need to control the licensing script if they want to cheat. They only need to control when the licensed system calls it and what the licensed system tells it, and as you pointed out, they can't be denied that.

For example, they could reprogram the licensed system to notify the licensing script of log-ins up to some level below the licensed limit, then report only some additional log-ins, so that the number of simultaneous users never appears to exceed the licensed limit when in fact it may.

If you can tell me what's wrong with my analysis, perhaps things will become clearer.

Technically with the "API" the Database containing the Users, and the Application that performs various functions would be hosted on YOUR server.  The only thing that the Client's Website does is request an embedded impression of only the Output the Application spits out.

Taking Javascript / PHP AJAX Calls the JS Script would send a request to your server, this would be exactly identical to a visitor stumbling upon that script and accessing it directly.  Your script verifies the API Key and sends output on whatever action or process would be taking place. 

Let us take Log-Ins for example:

1. Visitor lands on the Client's Website, the Client's AJAX Script sends a request from the Visitor's Computer to your Server with the Client's API Key and an action, let's call this action getlogin.  So the AJAX calls let's say http://www.yoursite.com/application.php?apikey=blahbah&action=login.

2. The server submits the login page and then it is sent back to the Visitor to be dealt with in their browser.  Javascript writes the content obtained from your server into the Client's Website from the Visitor's Browser, the Client's API Call never technically touches your Server.  So now the Log-In Page is displayed with all the appropriate actions, methods, and form input fields.

3. The Client then fills out the Form and clicks submit, which then sends the POST Request BACK to YOUR SERVER to validate the Log-In.  If the Log-In is valid the Server will send content back to the Visitor allowing them to proceed to utilize the Application.

As I said the Client / Your Customer never obtains a copy of the Application so they cannot alter the user limitation you have placed.  Since it requires Bandwidth Consumption / Server Usage, selling the Application in this fashion with User Limitations is Morally Acceptable.  Selling an Application to someone when they obtain a copy of it with a user limitation is just a Milking Scheme, trying to milk more money off of a customer.

This can also be done with iFrames to reduce the scripting of the Javascript Scripts featuring the AJAX Calls to YOUR SERVER, I still don't quite understand why you think they can still circumvent the User Limitations in this method.  From what I figure your Database would hold the Users in a Table and the Companies with a License in another table.  The Company Table would be tied to the Users Table in a One to Many relationship where you can count the number of users a Company has to restrict or prevent more users from joining.

API gives your company full control over the Source Code that prevents other people from making modifications and also gives Moral Grounds for charging on a per user basis.  You would also be able to charge on a monthly basis, granted the price was configured in a method to allow Companies to afford more users without forking over their entire profit margin for that month.  Any other method and you should be looking to alter the method in which the Application is licensed.  I personally suggest if you want to hand over a copy, remove the arbitrary user restriction and sell the licenses in some other format to generate a similar revenue.  Either suggestion would eliminate the need to try to stick it to your customers, which I don't personally feel is a good Business Model to be using.

Just my two cents, hopefully you are able to grasp the concept I am trying to portray when I say "API".  Application Programming Interface:  Think about it this way, when you access a website you are only obtaining the Visual Representation of what the Server Side Scripting is doing.  The API works in a Similar Manner, your Customer will only be able to display a Visual Representation of your Application on their website ONLY when an End-User accesses the particular webpage on the Customer's Server.  The Application / Program / Database / Functions / Schema / "" EVERYTHING "" pertaining to your Application is found on YOUR SERVER, the CUSTOMER never ever ever ever gets to OBTAIN or MODIFY the Application because it is never on THEIR server.

You were close, but you keep thinking that the Application somewhat ends up on the Customer's Server and only interfaces with you to obtain Licensing Information.  NO, the API would have them use a TINY bit of Code to Interface with the ENTIRE APPLICATION.  The License Tracking only offers the Application a secure way of knowing which Company has what License and how many Users are allowed on the Application.

In the end I simply suggest changing the Licensing Structure to a 1 Time Fee granting a Perpetual, Non-Revocable, Non-Exclusive License and give the Source Code to the Customer without a User Limitation.  Honestly, in my opinion, giving someone the source code and telling them they cannot modify it or use more than an arbitrary number of users is like trying to milk a bull.  You may get results, but they won't be the type of results you want.

Do you require any more explanation of what I am referring to when I say API?  If so, please send me a Private Message and I will try to convey this in a manner that may outline exactly what I am trying to say.

Edited Nutshell: The Licensed System is programmed to WORK OFF OF YOUR SERVER.  The component to work with the Licensed System ( Your Application ) is handed out to the Customer.  The component would be a small feature which has no control over functionality, processing or anything except with predefined methods of what you choose to accept.  Your third paragraph is completely wrong as you continue to assume I am suggesting they have the Licensed System ( The Application ) Hosted on Their Server.

Kindest Regards,

Jumpy09

Jump09, I think we're just going to have to agree to disagree.

My company's owners are aware of a large. potentially lucrative class of potential customers for our product who won't accept the hosted service that we now offer. You're proposing a solution that's more complex than a pure hosted service, but at the end of the day, is subject to all of the same objections. That simply isn't a constructive response to the problem.

Concerning the licensing provisions, I respect your moral judgments, but I don't share them, nor do my company's principals.

So far this thread has produced one promising solution to the problem I posed: source code encryption. I'd like to be able to present more alternatives, and I'm reasonably sure that this thread isn't gong to produce any while we're discussing the morality of per-seat licensing. Therefore I'd like to return to the original topic.

Alright, despite my Moral Objections, I will post some potentials for Source Code Encoding / Encryption.  There are ways of decoding / decrypting the source code to obtain it, but it can sometimes get expensive for someone to go through another company to do it.  As long as the Licensing Provision included a statement that claims the Customer cannot decode / decrypt the source code or they would be violating the Terms of Use, you would have legal grounds to sue if your company somehow finds out.

I feel most companies won't be looking to circumvent your system, but if there is a few rouge companies be sure to let the guys upstairs know it happens to be all you can really do with PHP to protect the system.  If someone circumvents it, they should be aware that they could lose money on the per seat license style as there would be no way to know for sure.  You would also be risking that a rogue employee would take the source, decode / decrypt it, and release it publicly.

Potentials for Code Encoding / Encryption:

http://www.sourceguardian.com/

http://www.codelock.co.nz/

http://www.ioncube.com/sa_encoder.php

http://www.zend.com/en/products/guard/

From what I can figure Zend Guard and Ion Cube's PHP Encoder are the Encoding / Encryption Services most frequently used, however here are some links to decoding / decrypting both Zend Guard and Ion Cube's PHP Encoder.

http://www.showmycode.com/ :: Claims they can decode Zend Guard ( Have not tested it )

http://zendecode.com/ :: Obvious from it's name ( Have not tested it )

http://forums.zend.com/viewtopic.php?f=57&t=2242 :: A statement by a Director of Product Management for Zend Guard related to Obfuscation Programs.

http://www.unzend.com/ :: Supposedly decrypts IonCube and a bunch of other types of encoding.

Obfuscation / Encoding only inconveniences your legitimate, law-abiding customers, while the people who would would rip you off are not your target paying customers anyway.

I'm not trying to say that Per Seat isn't acceptable, in many cases it is, but in this particular case it becomes an Arbitrary Limitation.  I know you may not be in a situation to convince the Boss that the Product Model is wrong, but any system to try to protect the Per Seat Licensing Model will just impose annoyances on your customers.  If they just altered the License Structure to suit per server then the Boss would make more money, the customers won't be annoyed, and you won't have to worry if someone has decoded your encoding to circumvent anything.  In all of my time spent on the Internet, which is more than I care to admit, I have never seen a PHP Application run on a Per Seat Licensing Model which the Customer obtains a copy to.  Now why would that be?

I am arguing the Per Seat Licensing because this is imposing serious annoyances and inconveniences on the company you work for, which both the KISS Principal and the how everyone on Earth works besides Humans, take the Path of Least Resistance!  A simple change to the Licensing Model / Pricing Structure will defeat everything else, make everyone much happier, it is the Path of Least Resistance.  For some reason humans are hard wired to defy nature and do everything in the most complex and complicated ways.

Negate the Moral Objection, now we are just talking what is the most Logical Solution to a problem that you can either jump through hoops and still have short falls, or change a bit to cover all your bases?  Either way I have given you examples of encoding / encryption systems, so you have alternatives.  I'm not sure if the Company will pay for the Encoding System or if you will, but if you take it to the Boss at least pitch the Path of Least Resistance!