How to prevent resale of PHP source?

Question

Do you have a strategy for this? If I sell a web-system to a client and in accordance with the legal agreement, the customer is not allowed to sell it to others, how can I be sure he doesn't do that anyway?

My first idea is some sort of key that must be in the root directory, and that file is only valid for that specific domain.

Other Ideas?

UPDATE 1 I agree that this is mainly a legal problem. But the facts are: I´ve got a client that buys this system from me to sell it to others. And he wants this system to function so it's easy for him to make his profit. The ability to package the web server and sell it is part of the specification.

UPDATE 2 Another one point of view is this. In that case it is hard to prove how much of the reselled software comes from my original system.

UPDATE 3 Obfuscating is not an option for me, a really hate it.

Answer 1

This is a social problem, not a technical one. You have copyright law on your side; no more should be needed. (Any and all technical solutions would be the equivalent of DRM, which is inherently ineffective.)

Regarding your update: So basically you become a DRM supplier for this client of yours. So: Does the client understand that DRM is ineffective? Try educating them before wasting time on implementation.
If the client remains adamant, I'd take a long hard look at what current DRM vendors are doing. E.g. lots of handwaving, some obfuscation, and, erm... I don't know... what else do they do? Either way, you can be certain that any solution you implement will be undone in less than 10% of the time it took you to implement it - so spend as short an amount of time on this as you can get away with. (Before it was edited out, you wrote "It's in the spec" about "being sure that the system isn't sold on": this might mean you've agreed to build something which is technically impossible (you can never be sure), and would require you spending an infinite amount of time building something which comes close...)

You might investigate having the application contact some central registry when run for the first time (with embedded fingerprint, different for each sale, so you know who passed on their code). That way your client can find out where the application is being run, and has a chance of contacting those who use it without permission. (Potentially turning them into new paying customers.) Maybe give said central repository the ability to send a kill-signal back? That gets really scary though, and liability concerns would be huge; avoid if at all possible.

Answer 2

The proper way of prohibiting re-sale of your software is via legal constraints, not technical ones. Have your customer sign a contract where they agree not to re-sell.

Technical prevention measures universally make the product worse, also in the technical sense, and that lessens the value to the customers. The stronger the technical protection is, the bigger the nuisance.

For example, suppose the customer legitimately wants to change their domain name. Should they have to buy a new copy? I think not. If you tell them how to change the keyfile to match their new domain, they can then use that information to enable them to re-sell. However, the legal protection applies regardless of what technical tricks they come up with.

Answer 3

Some use an obfuscator like Zend Guard but honestly I think that technical solutions for this kind of problem are as doomed as DRM is for audio and video content. Fundamentally what you've giving them is meant to work so it's just a technical problem to make it work in ways you don't want.

Your recourses here are (imho) legal not technical. You have a contract with the client that lays out what they can and can't do. You have a good lawyer draft that contract. If they don't abide by it then you pretty much have to take them to court.

Don't count on any form of obfuscation or copy protection as any kind of guarantee.

This is particularly a problem for scripting languages because (Zend notwithstanding), they are fundamentallly plaintext distribution methods. Java and .Net and other bytecode compiled languages have a little more protection but they can be disassembled into intermediate code too (but obfuscation is more useful here). Truly compiled languages (eg c, C++) have the most protection of all since disassembling a 50 meg binary into assembler code typically isn't that useful.

Even then there are no guarantees. If you're not comfortable with that then you need to carefully select your clients, live with the potential breach of contract (and the possible enforcement that might compel you to pursue) or find another line of work.

Answer 4

But a problem is when you aren't afraid of the customer reselling what you have done, out of the box, which can be tracked by lawyers. The problem can be that the customer is refactoring it. I mean take my many hours of work and change a couple of things and call it his... Sell it for a small amount cheaper and win the business...

That is why I am looking at technical solutions for protecting my work. It will also possibly help me to keep the invoicing fromo lawyers to a minimum, which is a substantial amount of change from having him/her to protect my work.

Answer 5

How can I be sure he doesn´t do that anyway?

You can't prevent it...period. If anyone has the source there is no way to stop them...you can only then resort to punishing them if they do.

Perhaps your contract, besides forbidding them from reselling it, has a price associated with them reselling it, i.e. something like 10x or 20x what you would normally pay, plus legal expenses if any required to get them to payup...that way, if they choose to do it anyway, you have a nice piece of paper, with their signature on it that already has a nice fat pre-agreed upon price that they need to pay should they go ahead and sell it.

Answer 6

Obfuscating the source is more trouble than it is worth, in my experience, unless you are trying to keep some complicated algorithm secret.

I would suggest doing the following:

1. Make sure you and your client and your lawyers all understand and agree with your contract.
2. Insert a short copyright statement as a comment in every source file.
3. Insert copyright notices into the generated web pages (via page templates or php code) as HTML comments, so a 'view source' will prove that your code is being in an unlicensed application.

If you're really worried, and this isn't an intranet-only app, you might expand on (3) and insert unique hidden text into the pages that is seen by Google but not by users.

None of this will stop a determined thief, but will help deter and detect "accidental" thefts.

Answer 7

I reckon the only way to be sure is to offer your product as a hosted solution so the client never has access to the code. If you build it with this goal in mind you can still have resellers and let them skin the system so it looks like their own product.

This works well where I work, in theory customers can licence the code to run on their own infrastructure, but it is priced at such a level that only big companies are prepared to pay, and big companies are on the whole more concerned with legal niceties so are less likely to just run off with your work.

People are very prepared happy to go with hosted solutions if the price is right, and it can have benefits for everyone. The customer doesn't have to worry about getting everything set up and they also have the security of knowing that if something does need tweaking we (the developers) are there to do it.

Answer 8

I haven't seen mention of Ioncube and so was wondering if there is a reason for not using it?

Yes it costs money to set up and yes it requires a server side library to be installed (I daresay most hosts these days have it already running) but it does allow for domain restrictions as well as time based restrictions.

Maybe you could even use it in conjunction with PHPAudit?