Limit Software Version Updates to Customers with a Valid Maintenance Agreement

Goal

Let paying customers install your updates, while preventing customers whose maintenance has expired from installing builds released after their maintenance ended (the versions they already have keep working).

How it actually works

The mechanism is a date comparison, not a hard license expiration:

1. You store each customer's maintenance expiration date in their license. It travels into the PLUS5 license file as EffectiveEndDate, and because the license file is tied to the activated machine, it is unique per installation.
2. You hard-code a release date (or build date) into each version of your software.
3. Your software (or installer) compares the two. If a build's release date is later than the customer's maintenance expiration, that customer is not entitled to that build, so you block it. Builds released while their maintenance was still valid keep working.

This gates upgrades by entitlement without expiring the license itself.

Steps

1. Store the maintenance expiration date - SOLO Server

Configure the product so the maintenance expiration date is written to the license and included at activation. This date is delivered to the client as EffectiveEndDate. Set or adjust it on the Product Option or on an individual license.

2. Hard-code a release date - your build process

Embed the release date (or build date) of each version in your source or resources. This is the value you compare against at runtime.

3. Compare the dates - your PLUS5 application or installer

Read EffectiveEndDate from the license file and compare it to the build's release date. If the release date is after EffectiveEndDate, block installation or launch of that version. PLUS5's date validators help here (see PLUSManaged or PLUSNative: Validating Time-Limited and Subscription Licenses). You can run the check in the installer before install, or when the application first launches.

4. Keep it in sync - refresh the license

Give the application the ability to refresh or background-check the license, so that when a customer renews and SOLO Server updates the date, the local license file picks up the new expiration (PLUSManaged, PLUSNative). Set how often this happens in License Validation Options.

Recommended: check maintenance before you activate (InfoCheck)

The most customer-friendly approach is to check the maintenance expiration date before you process the activation, using InfoCheck (or InfoCheckS). InfoCheck reads the license details, including the maintenance expiration (EffectiveEndDate / "Download Until") date, using only the License ID and password, and it does not consume an activation.

1. Before activating, call InfoCheck to read the maintenance expiration date.
2. Compare it to your hard-coded release date (step 2 above).
3. If the release date is after the maintenance expiration, the customer is not entitled to this version. Show your own message (for example, that their maintenance has expired, with a link to renew it so they can access this version) and do not proceed with the activation.
4. If they are entitled, continue with the activation as normal.

Why check first: if you activate first and only then compare the dates, you will have used one of the customer's activations just to turn them away. You can deactivate that installation to free the activation again, but checking with InfoCheck first avoids the wasted activation and the extra steps.

Example

Today is November 1 and the customer's maintenance expired October 1. A build you release today carries a November 1 release date. Because that is after their October 1 expiration, they are not entitled to this build, so your check blocks it, while the version they were entitled to keeps running.

Related

• Configuring a Subscription License (SOLO Server + Protection PLUS 5 SDK) (the same EffectiveEndDate field, used for a different policy)