What do you consider a "very high price" for a PHP application you would consider? That was encoded... that gave you 99% source code?Quote:
Originally Posted by RichardAnderson
Printable View
What do you consider a "very high price" for a PHP application you would consider? That was encoded... that gave you 99% source code?Quote:
Originally Posted by RichardAnderson
I really like your whole 99% idea. However, if it is JUST your licensing that is encoded... what is to stop a use from including that license file?Quote:
Originally Posted by Olate
Surely the "check" must be somewhere else if you say the admin panel does not work? If you could just clarify a bit, that would be great!
EDIT: Also, I just took a quick look at phpDoc. Can you show me something generated with it? I am a bit puzzled by its "automatic" documenting...
I do appreciate your input throughout this thread and also the e-mail replies I have received from your company. I have already indicated (in the e-mails) that I will be making the purchase of your encoder closer to the final development of the software.Quote:
Originally Posted by ioncube
Thanks again, and to EVERYONE for their input!
We use our own licensing product to license our products :) This works by the user purchasing a license, entering a key string, then the license data is downloaded in a local file which is read on subseqent loads. The code that checks the license is within the admin.php file. If the license is valid, then nothing happens and the user can use the admin panel. But if the license is invalid then an error is shown and they can't go any further. We chose to put it in the admin panel because of the nature of our product - licensing. If the entire application stopped working, then their customers would also get errors, which isn't fair - it isn't their fault the developer stopped paying (or whatever the situation is). In our case, this works because you need the admin panel!Quote:
Originally Posted by sdesigns
In theory, you could manually access the database or work around the fact that the admin panel is disabled, but this is a lot of hassle. You can't just include the license file because it is "encrypted" and must be decypted by the licensing code, which is encoded.
Basically you add comments like this to your source:Quote:
Originally Posted by sdesigns
In this case, the documentation will then be generated with a description of "Changes the status of all licenses for a specific order" and it will create a function prototype (like you see in the PHP manual) which looks likePHP Code:/**
* Changes the status of all licenses for a specific order
*
* @param int $id Order ID
* @param int $status New status
* @global object database Database functions
*/
function status_by_order($id, $status)
{
global $database;
$database->query('UPDATE '.$database->prefix.'licenses {data} WHERE (order_id = '.$id.')', 'UPDATE', array('status' => $status));
}
void status_by_order (int $id, int $status)
Which you can see has been generated from the comments in the PHP. You can see the actual output of this phpDoc syntax at http://www.olate.co.uk/support/docs/...tatus_by_order
This therefore means that the developer has all the information they need to use the functions - just include the file and you can use them. There is no need to worry about how the function works, just how to use it!
It really is nonsense that your product could appear on edonkey. Unless you are selling software as big as vbulletin, I doubt that even if there was a leak, it would only make it to a small group of people who wouldnt buy it anyways.
Use vbulletin as a business model. Why do you think they do not encode their script? It does not make business sense to encode your scripts. You are more likely to lose a client because of the encryption than to have your software warez'd to some people who wouldnt buy your software anyways.
Olate, I am still not quite sure how your system of encoding the licence file and requiring it in admin.php ensures security. Where is the mechanism to disallow access to admin.php? If it's in admin.php (which is unencoded?) couldn't it just be removed, and, if it's in the licence file, then not including the licence file would fix the problem. No?
The only way I can think of to offer a mostly unencoded version is to encode a few critical portions of the code so that reverse engineering them from what code is open is more costly than simply buying the product. How do you secure your product without encoding critical operating processes?
admin.php is encoded. It is the only file which is.Quote:
Originally Posted by Adam A Flynn
Ahh, okay, that makes sense then. Sorry about the confusion.
With a focus on encoding products, it's also worth noting other reasons that users encode. These include:
* Site designers who charge their client for site updates.
* Shared host users protecting their scripts from other users on the machine (quite a few shared hosts have insecurities that allow users to easily browse other accounts on the same machine).
* Shared or dedicated host users protecting their scripts from modification if hackers break in, and that might go undetected for a while.
* Site owners protecting their scripts from unauthorised observation or changes from other users in the same organisation, either for security reasons, or from developers tinkering and circumventing rigid UAT (user acceptance test) and rollout/signoff deployment procedures. This is common in larger enterprise organisations such as banks, where regulatory issues would mandate encoded files.
* Embedded product reverse engineering protection. We have customers using special Loaders built for embedded systems, such as network routers, that use PHP for the router help or configuration system. Knowing that the routers would be analysed by competitors, the PHP code is protected to create barriers to such reverse engineering.
The fact is that there are many products that are as big and also much bigger and more complex than vbulletin. Lost sales are one concern for companies, but IP theft and loss of competitive edge is another significant issue, particularly for larger organisations that will have invested 10's or 100's of thousands of dollars into development of a product.Quote:
It really is nonsense that your product could appear on edonkey. Unless you are selling software as big as vbulletin
Whilst the popularity of PHP was inevitable thanks to the ease with which experienced and inexperienced/non-programmers alike can produce solutions quickly, the availability of solid encoding solutions is also a major contributory factor to PHP being embraced and seen as a viable solution that can be taken seriously by large enterprises, and where having unencoded scripts is simply not an option.
I wouldn't encode, you will lose customers as I don't even buy encoded products, I like to be able to run scripts on mutiple sites and servers, etc. :D
Sure, on a guestbook or something you can create in 20 minutes. I agree with you :) Who would buy an encoded version?Quote:
Originally Posted by ArcticPro
What you don't realize is the way php scripts are being designed lately making it possible for clients like you to buy and modify the "output" aka HTML without seeing the sources. It doesn't matter if it's encoded, since there is always way around "encoding" that provide customers with ease of use and design flexibility (ie: template system). If you want full source, you pay extra for that or move on.
HTML is HTML, it can't be encoded anyways. These days, script authors provide a sense of design flexibility and that's all that matters. We recently moved this way for ILance, and the results have been fantastic. Our sales doubled in the first month of the new product release at the same time our entire property is fully protected from prying eyes.
It's not what you've done with encoding, it's how you market the product as an encoded entity to the customer. If the client can change his homepage after purchase, where is the problems? [unless that customer turns developer over night] we have a new package for him - Developer Edition sources at 3 (if not 4) times the cost of the encoded version. It's solid firms like Zend and Ioncube here to help us authors by going further to provide trials, demos, expiring licenses, and so on. It's basically where PHP meets Shareware (in a way).
The point is there are people who don't buy encoded software, and there are people that look at it different way. "Even If I purchase this encoded version, will I still be able to do the things I want without an unencoded version?". In most cases for the average customer, it's HTML that is only of concern, and if that's the only concern, where is the problem?
You want the code? don't want pay for it? Write your own logic. It's pretty simple. :D
I have bought a few different PHP scripts, some that are encoded, with call backs and some that are not encoded.
Almost all of the encoded scripts I have come across I've had problems with. Some problems include:
- You find a bug and it takes a while for the developer to get you a fix.
- Their server goes down for some reason and so the callback fails on your script
I understand why developers encode there script do to piracy but I feel that it has been blown out of per portion. Especially with scripts with niche markets.
As a rule now I don't buy encoded scripts anymore its just to risky. I do not like trusting that someone will be around in a few years to fix/update/etc.. the script when it is my main source of income.
Is it necessary to encode you work?
Silverline makes some interesting points. Calls to servers when running scripts, sometimes called a "phone home" mechanism, could cause problems, but this is not an inherent feature of most encoded systems themselves. With the ionCube solution we actually made a deliberate decision not to put such a feature in so far, although at the low level is the best place for it.
Some 3rd party licensing solutions do offer this technique, and it is ideal for cases where software is leased rather than purchased outright, as it gives a way to shutoff a script if a customer stops payments and decides to walk away with the script. When purchasing a license for software that is perpetual, asking the provider whether the script uses a phone home mechanism or not could be a good idea to avoid possible reliability issues.
Worrying about whether a PHP script company will be around in 6 months time is perhaps more than anything a telling comment on how developers of PHP scripts are perceived when compared to providers of software using other technologies. The "here today, gone tomorrow" perception of script developers is certainly not far off the mark in some cases, but the PHP developer community is also rich with quality products from companies that are very successful, and who are not going to pack up shop because they need to concentrate on finishing high school!
When purchasing, use due diligence to evaluate a company and product. Check support forums, see how often updates are provided, how quickly responses are answered if at all, and whether by other members or by qualified company staff. Also review what people say about a product on the web, and evaluate all aspects. You could also ask about their policy of releasing source if they had to shutdown due to an unrecoverable disaster (e.g. death). True, none of this guarantees trouble free use of software. Having source may be tempting, and in some cases there are undeniable merits to having the source, or at least a framework within which to extend or modify functionality.
However once the results of DD are in, whether or not a product is encoded is likely to be less relevant when compared to the performance of the company, product and their likely longevity. A company taking steps to guard its IP and revenue stream is taking positive action to help secure a long term future for themselves and their products, and with most people not wanting or being able to dedicate resources to maintaining code from a failed company if it came to that, this should be an important consideration.