Protecting Free PHP Software - Chew on this...

Protecting Free PHP software, how does one do it?

Chatting with a friend late tonight and we were discussing the concept of offering a useful and free PHP-based system to the public. For the free-use version, the only requirement is that the publisher's name and backlink remain in the software. It sounded simple enough to me at first, but as I thought it over more and more, I realized that with clear-text scripts like PHP, there aren't obvious easy ways to ensure something so simple as maintaining the publisher's/author's link in the footer.

Googling the topic, I found lots of refs to Zend Obfuscator and SourceGuardian, but they seemed to require special server configurations and had their various caveats. The goal here is simple, just force the users to keep a link in the footer if they're not willing to pay for the "Pro" version. No real need to obscure or encrypt all the code.

Anyone have some suggestions for further discussion? I don't have dog in this race, but got hooked by the challenge and need some closure now! (even if it's just a consensus that it can't be accomplished without placing extra requirements on the installation environment.)

 

As far as I know, the only way to do it without a solution like Zend Obfuscator and SourceGuardian or at least partial encryption would be to have some small, but critical part of the code hosted on your server and referenced in the script. You can then check it from there.

 

IMO, the ease of which such links can be removed is the first problem - it's usually nothing more than removing a single line of HTML.

I wouldn't think about creating a bullet-proof solution, as much as trying to raise the bar to make it more difficult to remove such attribution - for a start, ensure that a single essential part of the script is coded with the footer in PHP, so that it's not so easy to remove the required code unless the user is good with PHP (a lot of users won't).

Additionally, if using MySQL, ensure parts of the template are called up via the database (not the parts the user would want/need to customise) and again, that the call-ups for these part of the template are coded into PHP. This would certainly put people off where the user is not proficient with databases.

Overall, making it harder to remove credit could be a more fruitful approach that trying to make it impossible, because the majority of users will not be that proficient with PHP/MySQL - which is precisely why they need to use such a script in the first place.

2c.

 

I, Brian, I think I get your drift. Security through difficulty, if not obfuscation. Presume many less technical people will use it and can't figure out how to decipher the indirection you put into it. That's a good suggestion. I think a moderate amount of twisting the code and mixing it with the database would give decent mileage.

Was my first notion, but don't see how that can work. You just remove from the code that checking. too easy.

 

You can do it with ioncube. http://www.ioncube.com/

 

Also, php obfuscator might help a bit.

 

Join the Open Source revolution and make you money in other ways (eg Adsense).

You're using PHP - Free software and Apache to deliver this 'product' - why do you feel you should charge for your last little link in the chain?

 

It seems to me he only wants to ensure that credit is given via a backlink. The pro version is an option.

 

This may or may not help but the www.milonic.com menu requires that you have a link to milonic on the homepage or it puts one in the menu.

Once you pay for the full version this requirement disappears. I have no idea how its done despite looking at all the source codes.

 

I, Brian made a lot of good points which are basically the same kind of things i was thinking. Personally, the way i would do it is like build a large mechanism within the application, all tying each module to each other so if one thing is missing then the application stops, which is your first requirement, the second is your core engine should have an authentication method querying your own server for a key, once its got the key, a new one should be generated and stored both on your server and also in the applications database so that next time it asks your server for an auth key it has to then match the one thats in its database with the one it was given previously and then repeats the process and gets a fresh key. The third thing you would do is then obfuscate the code module by module and then once again as a complete obfuscation. You could write your own obfuscation algorithm to do this.

Now ofcourse what ive discussed is a little overkill for ensuring 1 backlink stays in place. But is very effective for the primary goal, which is not to keep a backlink in the footer, but instead to enforce the terms of use for the application. My method would be best suited to a licencing system.

I'd love to get my teeth stuck into a project like this one day. Sadly i dont have the finance or resources to start such a large project. I'll get it... one day...

Dread