How to prevent resale of a PHP source?

Question

Do you have a strategy for this? If I sell a web system to a client and in accordance with a legal agreement, the client cannot sell it to others, how can I be sure that he will not do it?

My first idea is some kind of key that should be in the root directory, and this file is only valid for this particular domain.

Other ideas?

UPDATE 1 I agree that this is mainly a legal issue. But the facts are as follows: I have a client who buys this system from me in order to sell it to others. And he wants this system to work so that it is easy for him to make a profit. The ability to pack a web server and sell it is part of the specification.

UPDATE 2 Another point of view -. In this case, it is difficult to prove how much of the reprogrammed software comes from my source system.

UPDATE 3 Obfuscation is not an option for me, it is very hateful.

Answer 1

Some use an obfuscator, such as Zend Guard , but to be honest, I think that technical solutions for these kinds of problems are doomed to the fact that DRM is designed for audio and video content. Fundamentally, what you give them is designed to work, so it’s just a technical problem to make it work the way you don’t want it.

Your resources here (imho) are legal not technical. You have a contract with a client that determines what they can and cannot do. You have a good draft lawyer for this contract. If they do not comply with it, then to a large extent you will have to take them to court.

Do not count on any form of obfuscation or copy protection as any guarantee.

This is especially a problem for scripting languages ​​because (despite Zend), they are the fundamental methods of distributing plaintext. Java and .Net and other compiled bytecode languages ​​have a bit more protection, but they can also be disassembled into intermediate code (but obfuscation is more useful here). Truly compiled languages ​​(for example, c, C ++) have the greatest protection against all, since parsing 50 megabytes into assembler code is usually not so useful.

Even then there are no guarantees. If you don’t like it, you need to carefully choose your clients, live with a potential breach of contract (and possible coercion that may cause you to pursue), or find another job.

Answer 2

I believe that the only way to make sure that you offer your product as a hosted solution is to ensure that the customer never has access to the code. If you build it for this purpose, you can still have resellers and let them hide the system so that it looks like its own product.

This works well when I work, theoretically, clients can license the code to work on their own infrastructure, but it is evaluated at a level that only large companies are willing to pay, and large companies are generally more interested with legal subtleties, so it’s less likely to simply run away with your work.

People are very willing to happily go with hosted solutions if the price is right, and it can benefit everyone. The customer does not need to worry about everything being configured, and they also have security, knowing that if something needs to be configured, we (the developers) must do this.

Answer 3

This is a social problem, not a technical one. You have copyright law on your side; do not need anymore. (All technical solutions will be equivalent to DRM, which is inherently inefficient.)

Regarding your update: In this way, you become a DRM provider for this client of yours. So: does the client understand that DRM is inefficient? Try to train them before you spend time on implementation.
If the client remains adamant, I would take a very long look at what current DRM providers are doing. For example. many hands, some obfuscations, and, erm ... I do not know ... what else do they do? In any case, you can be sure that any solution that you implement will be canceled in less than 10% of cases when you need to implement it, so spend a short time on it, since you can leave. (Before it was edited, you wrote "This is in the specification" about "assurance that the system is not for sale": this may mean that you agreed to build something technically impossible (you can never be sure ), and you it will take an infinite amount of time to create something that is close ...)

You can investigate when the application contacts some central registry on first launch (with a built-in fingerprint that is different for each sale, so you know who passed their code). Thus, your client can find out where the application is running, and has the opportunity to contact those who use it without permission. (Potentially turning them into new billing customers.) Maybe give the specified central repository the opportunity to send a signal of dismissal? However, it is very scary, and the problems of responsibility will be huge; avoid if at all possible.

Answer 4

Obfuscating the source is more of a problem than it costs, in my experience, if you are not trying to keep a secret algorithm.

I suggest doing the following:

• Make sure that you and your client and your attorneys understand and agree with your contract.
• Insert a short author statement as a comment in each source file.
• Embed copyright notices in the generated web pages (via page templates or php code) as HTML comments, so the “view source” will prove that your code is in an unlicensed application.

If you are really worried, and this is not an intranet-only application, you can expand it (3) and insert unique hidden text into the pages that Google is viewing, but not users.

None of this will stop a certain thief, but will help to contain and detect "accidental" thefts.

Answer 5

The right way to prevent the resale of your software is legal restrictions, not technical ones. Ask your client to sign a contract in which they agree not to resell.

Technical preventive measures everywhere make a product worse, also in a technical sense and reduce customer value. The stronger the technical protection, the more trouble.

For example, suppose a customer legitimately wants to change their domain name. Should they buy a new copy? I think no. If you tell them how to change the key file according to their new domain, they can then use this information to allow them to resell. However, legal protection applies regardless of the techniques they come up with.

Answer 6

But the problem is that you are not afraid that the client resells what you have done out of a box that can be monitored by lawyers. The problem may be that the client is reorganizing it. I mean, take many hours of work and change a couple of things and call it yours ... Sell it for a small amount cheaper and win a business ...

That is why I am considering technical solutions to protect my work. It may also help me keep the invoice from lawyers to a minimum, which is a significant change from having he / she protect my work.

Answer 7

How can I be sure that he will not do this?

You cannot prevent this ... period. If someone has a source, there is no way to stop them ... you can only then resort to punishment for them if they do.

Perhaps your contract, in addition to preventing them from reselling it, has a price associated with their resale, that is, about 10x or 20x that you usually pay, plus legal costs, if necessary, to make them pay ... that way if they still want to do this, you will have a good sheet of paper with their signature on it, which already has a nice thick price that they have to pay if they go ahead and sell it.

Answer 8

I did not see the mention of the Ioncube, and so I was wondering if there was a reason not to use it?

Yes, it costs money to configure and yes, it requires installing the library on the server side (I believe that most hosts are already running), but this allows you to use domain restrictions and time limits.

Perhaps you could use it with PHPAudit?