The following topic describes how licenses are identified, what the changes are in comparison to the previous version (Guard 4), license options, restrictions and usage.
Software that is distributed with license restrictions depends on the Optimizer component to enforce restrictions. When the Optimizer is loaded, it finds and loads all the licenses (.zl files) in the license directory as specified in the "zend_optimizer.license_path" directive (in your php.ini).
When a file is encoded with a license (using --license-product or sign-product) the Optimizer tries to find a matching valid license.
There are certain conditions for a license to be valid.
It needs to be:
Produced with the same private key that was used to encode the file.
Have the same product name that was specified during the encoding.
Both restrictions must be satisfied. (Restrictions are checked on loading, so if they have expired while the web-server was running, they will still be accepted.
Up until Guard 5 (exclusive) private keys were produced by Zend, and were written in the Guard License. When using an evaluation version (no license) the application used a hard coded private key. However, this meant that in order to produce a license for an application, the users had to use the same Guard license that they used to encode the script. Moreover, when users upgraded the Guard version, they had to contact Zend in order to get a license with the same private key they had.
In Guard 5.0 private key was separated from the license by changing the license generator (zendenc_sign) to support:
Key extraction (from an old license)
Support key verification
The result is that when encoding file, and producing a license, a key must be specified.
This change allows users to manage keys on their own, without the need
to contact Zend. Therefore, the Guard license is no longer part of the
For example: Users can now encode their files on one machine (using one Guard license) and produce a license on other machine (using a different Guard license) as long as they use the same key.
Guard offers two levels of licensing support:
License is requited (using --license-product switch)
License is supported (using --sign-product switch)
The difference is the script that requires a license will not run unless
a valid license is present. Script that supports a license will run without
a valid license, but, if a license is present, it can be accessed (using
the Optimizer API functions). This enables
you to define your own restrictions.
For example: An application can be made to run in evaluation mode without a license, in limited mode, with one type of license and in full mode with another.
Guard licenses can be enforced based on the following categories:
ZendID (unique code based on the machine hardware)
In addition, users can add custom fields (in key=value format), and write restriction code.
The following procedure describes how to encode a project using a private key:
If you do not have a valid private key file, generate/extract one first before encoding your project.
To encode a project using a private key:
The files will be encoded with the restrictions set in the license.
To get a field from the license (for example, for custom limitation) use the zend_loader_file_licensed API function
To load license without the need to restart the web server use the zend_loader_install_license API function
License generator (zendenc_sign) usage can be found [Zendenc_sign_usage here] (Or by running it with no parameters)
Other API functions can be found [Optimizer_PHP_API_functions here]
Other ini directives can be found [Zend_Optimizer%27s_Php.ini_directives here]