No worth developing free software

Heh, i've seen the concept of open/closed source, but how does it apply to php? I think if you're going to develop something in PHP the source is always available or iam wrong?

God. of course its not correct.

What you produce ON php is going to go with the license you choose it to have. GPL if you choose GPL, free software if you choose so, proprietary if you choose that.

Don't confuse licensing with whether the source code will be available.

Pretty sure php is a scripting language, so your scripts, will be "open source" in the sense that they will be readable by your customers (unless there is a php compiler available?). Your license can place restrictions on redistribution of that code. This doesn't mean that the php code will be transmitted to every browser that views a php web page. The server hands the php code off to the interpreter which emits content of one form or another and/or has side effects on the server.

If you have a proprietary algorithm, the detailed implementation of which you wish to conceal from your customers, php might not be the best form of distribution. You can implement such algorithms in a compilable language and then call those functions from a php interface. I'm pretty sure php supports calling C functions, possibly others.

To protect source of your PHP script you can use any php compiler. As far as I know the most popular php compilers are Ioncube and Zend.

And if you would encrypt your scripts, use Zend. It has a much more widespread parser than IonCube :-)

I think you mean Loader rather than parser as when encoding, the parsing and compilation is made at encoding time.

As the folks at WHT will tell you, (webhostingtalk is where many hosters hangout), in practice you can generally run encoded files from Zend or ionCube on most servers, although there are a few notable exceptions such as Yahoo! who don't support encoded files from any vendor. There's also been a move away from using Zend Optimiser by some people unless absolutely necessary when it was realised that the net effect can be a machine slowdown rather than acceleration.

One of the features that we saw early on as very beneficial for end users was making it possible to run encoded files without server changes, and whilst this technique is not supported by every host, the "runtime install" method is widely supported so that hosts don't need to install the Loader themselves and the Loader is installed on the fly when required. Although installing in the php.ini file is best as it avoids the overhead of calling dl(), this means that it's one less thing for the host to install.

Producing code in C as suggested by another poster is also a way to go, perhaps combined with encoding. To do this, a PHP module could be created that gets installed into PHP at runtime and that provides a new set of PHP functions. Although not a problem for installs onto dedicated servers, the downside with this is that there would be problems when distributing modules to shared servers because of the distrust factor. Market leaders such as ourselves and Zend have established trust and world wide brand recognition with a proven track record for more than half a decade, but no host would install an unknown module.

There are some notable advantages to using custom modules though for security sensitive installations. With the runtime core of PHP plus all the libraries being opensource, even when using encoded files, runtime behaviour can potentially be observed by modifying PHP because all builtin PHP functions map to opensource C functions. Locking files to particular machines and having trojan detection such as tripwire can help minimise the chance of someone being able to use or substitute a modified version of PHP to expose sensitive data, but these are considerations that can get ignored.

For general script protection, encoding PHP is sufficient though, with the primary benefit being the opportunity to lock down evaluation code, and the opportunity to license scripts to specific machine by domain, IP and MAC (ethernet address) being a useful secondary benefit.



hth.

As a followup, unity100 suggested that you should be able to choose the licensing model for your code and then go for it. In general this is certainly the case, but the case a few months ago of the Joomla team shooting themselves in the foot and being pursuaded that they should prohibit developers of Joomla extensions from making them closed source shows that it's not always that simple. For the leading developers in the thriving Joomla market, many of whom use our technology, this understandably caused quite a stir with talk of forking Joomla to a version that was closed source friendly and various other solutions.

Going back to the original subject of it not being worth developing free software, it actually can be useful and worth it as an adjunct to other commercial offerings. Open source code also need not be free, and there are ways to derive revenue from open source code. However those ways do not work well for all sizes of business, and for the smaller companies, their only revenue stream is likely to be from selling code hence the importance to protect it and maximise their revenue stream. Once they get established, having free versions and perhaps contributing open source code as well becomes more feasible, and many do this.