I want to create a WordPress plug-in but also want to ensure that the plugin can only be used after it has been activated with a serial key that should be unique for each domain.
What is the best way to go about it assuming:
- I have to give the actual source code to the users and cannot have a VideoPress type of security – which is just a JavaScript wrapper for the actual content that comes from the plugin’s server.
- I want to ensure that a novice to average PHP developer will not be able to cirumvent the security easily.
Option 1 – Process some data on your system
I wouldn’t place all of the plug-in’s processing on your own server, but pick one or two vital functions and keep them hosted on your system. Then require an API key for each site that uses the plug-in so that they can communicate with your server.
Option 2 – Encrypt stored data and require a hosted decryption key
Another alternative is a basic encryption setup – this is actually a system I’ve been toying with for a while, I just haven’t bothered to deploy it anywhere yet. The code itself (to stay true to the GPL) is all plaintext just like you’d expect. However, all stored data (default values, plug-in settings, etc) is encrypted before being saved to the database. The trick here is that the plug-in on the remote system doesn’t have the decryption key – in order to decrypt the data, it has to post its API key to your system which then responds with the decryption key. This can then be stored in a transient (temporary option) for a certain period of time before being flushed – that way you don’t have a site hitting your server every 2 seconds during heavy traffic.
The downsides of this approach might outweigh the benefits, though (which is why I haven’t deployed it anywhere yet). First of all, a savvy programmer can capture the decryption key and then they don’t need your server any more. Or they could just flush out all the encryption/decryption hooks and run in plaintext. This is the advantage of open source for the user and the disadvantage to the developer who wants to distribute a free-but-restricted system.
The other downside is the dependency on your server. Storing a key in a transient lifts some of the burden off your server … but if your site goes down for an hour or two, then every site using your plug-in goes down for an hour or two unless you plan for some kind of graceful deactivation. Also, it would mean you’d have to keep said server up-and-running indefinitely if people continue using your system.
Option 3 – Limit the features of the “free” version
A last option, and one I’m actively working on using, is to split your plug-in’s featureset and functionality. The core of the system (UI, basic features, etc) is freely available without registration. For more advanced features, users have to register their copy, gain an activation key, then enter that key into the UI to complete the process – the plug-in then verifies with your server and downloads additional premium “add-ons” to the system.
The disadvantage here is that once downloaded, all the code now rests on the user’s site and, under the GPL, they can still redistribute the full package. The advantage is that it only depends on your system once and doesn’t require any kind of long-term download/processing support.
Any way you decide to move forward, you’re either going to be hit with maintaining some sort of external API on your server or providing the full source of the system to your users. If you keep some functionality on your system, you almost have to guarantee 100% uptime for it to be worth it. If you’re going to provide the full source, there’s no way (under the GPL) to prevent someone else from re-distributing your system.
You can’t hide the sourcecode away from WordPress users nor are you permitted to limit the redistribution of your plugin because of licensing implications.
You’re creating a WordPress derivate with your plugin and your users have the right to get the source of it and to freely redistribute it (see the four freedoms in free software).
Assuming WordPress is licensed under GPLv2 and you have got non-US customers you should deal with implications of a GPL violance you might have in your (“protected”) product.
You’re trying to implement a vendor lock-in for your users.
The only way to have a distributed plugin that has a secure license which any halfway decent programmer can’t hack is to run the plugin’s main functionality on your own server, like Akismet. The user must send a request to your server which contains their license key. If the key checks out, execute the source code on your end and send the results back.