License Architecture and Behaviour

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.

Run Flow

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:

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.

Key Management

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:

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 licensing process.
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.

License Options

Guard offers two levels of licensing support:

  1. License is requited (using --license-product switch)

  2. 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.

License Restrictions

Guard licenses can be enforced based on the following categories:

In addition, users can add custom fields (in key=value format), and write restriction code.

Usage

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.

 

 

Instructions on how to complete a procedure

To encode a project using a private key:

  1. Use --genenckey <path_to_key_file> to generate a Key or --extractkey <license_file> <path_to_key_file> to extract a key.

  2. Encode the application with the desired Licensing support.

  3. Specify the path to your private key. (for example, zendenc --license-product foo --private-key myKey foo.php foo.enc.php).

  4. Generate the license (zendenc_sign myLic myKey. This will run a textual wizard)

  5. Copy the license to the license path (defined in the php.ini file)

  6. Restart the web server to load the license

The files will be encoded with the restrictions set in the license.

Tips and Tricks