Charging for your work

Many people think that distributing your PHP code is bad - they want to get paid for their "hard" work. These same people tend to forget that no matter how complex their code is, it is not as complicated as PHP itself, or Apache, and definitely not as complicated as MySQL - and yet all three of those are available for free, with the source code.

The problem with PHP is that PHP scripts are just plain text - they can be read by anyone, and edited. If you try and put some licensing system in there, people can just edit it right out - as such, if you send plain PHP code out, people can send it to others freely. This problem has been solved through the use of PHP encoders, which mash up your PHP so the source code is no longer visible (although it still executes as normal), and let you restrict execution to certain machines if you want.

When you want to distribute your work, you have five choices:

  1. Sell the source code

  2. Sell the encrypted code

  3. Sell the encrypted code, tied to a particular machine

  4. Give away the source code, and sell support for it

  5. Give away the encrypted code, and sell support for it

Linux, MySQL, and PHP are all based on option 4. Option 5 is a possibility, and is probably better if you really want to keep the code to yourself - it allows you to get nearly as much distribution as option 4, without losing the ownership of the source code.

Option 1 is very common, but means that your buyer can pass the source code around to others. Option 2 is becoming increasingly common, however your buyer can still pass the source code around to others. You can limit this by sending each person a slightly customised script that says "Licensed to XYZCorp" at the bottom - this is usually enough to deter most people, because PHP is used mostly on the web.

Option 3 seems like a good idea at first - you keep control over the source code, and your buyer cannot distribute it to whomever they please. However, the problem with this is that customers are likely to contact your "technical support department" (read: you), saying "I want to move the script to a new web server - can you resend the scripts, tied to this new machine?" It is hard/impossible to tell whether they are telling the truth or not, but it is not really fair to say no either, because they could be legitimate!

Do not listen to people who say that Option 4 does not work - if your work is good, people will want support for it, and that generates good money as anyone from MySQL will tell you.

19.7.1.1 The long and short of it

The easiest way to make money from your script is option 1, and just trust that people do not give the source code away. Heck, make a tiny change in each script you send out so that you can trap people who distribute it if you want. If you want to spend a little cash on an encoder, go for option 2 - it will give you extra piece of mind if you do not want your source code public. If you want to join the long line of people who subscribe to the open-source movement, go for option 4. If you want to give your work away without also giving away control of the source, option 5 is for you - you still get maximum distribution, too.

Author's Note: If you use the include() or require() function to make use of external scripts from within your own, your licensing decision may already be made for you. If the external script you include()/require() is licensed under the GNU General Public License (GPL), it is the opinion of the Free Software Foundation that you would need to GPL your own work also or at least release it under a GPL-compatible licence. Again, this is an issue where you need to be quite careful how you step, as you almost certainly do not wish to end up in court over your use of another script!

 

Next chapter: PHP Encoders >>

Previous chapter: Distributing your code

Jump to:

 

Home: Table of Contents

Follow us on Identi.ca or Twitter

Username:   Password:
Create Account | About TuxRadar