The short answer is that an expired license stops the protected script from running. Nothing is deleted and your code is not damaged, but the script refuses to start until a valid license takes the place of the old one. Pyarmor license expiry is a deliberate control, not a malfunction, and understanding how it behaves helps you use it without surprising the people who rely on your scripts.
Expiry is one of the most useful features in the licensing system built into Pyarmor, because it turns a one-off file hand-over into a time-limited arrangement. You can let a client evaluate a tool for a month, or sell a script as a yearly subscription, and the limit enforces itself. The catch is that expiry works silently in the background until the day it triggers, so it pays to know exactly what happens at that moment.
This article walks through how expiry dates are attached to protected scripts, what the script does once the date has passed, and how expiry differs from your own Pyarmor license. It also covers renewal and how to plan dates so paying users are never caught out by a script that suddenly stops.
How an Expiry Date Gets Attached to a Protected Script
An expiry date is set at the moment you protect your script or when you issue the license file that goes with it. During the protection process you choose a date, and that date is recorded inside the licensing information the script checks when it starts. From then on, the date travels with the script wherever it is copied.
There are two common places the limit can live. Some developers bake the expiry into the protected script itself, so the deadline is fixed no matter which license file sits next to it. Others keep the script open-ended and put the expiry date in the individual license file handed to each user, which makes it possible to give different customers different deadlines for the same script.
The Decision Happens on the User’s Own Machine
Either way, the script itself carries or receives the rule. It does not phone home to ask permission, and it does not need an account or a server to decide. When the script starts, its runtime compares the recorded date with the current date on the machine, and that simple comparison decides whether the program runs.
What the Script Does Once the Date Has Passed
When the date has passed, the script stops at startup. The user launches the program in the normal way, the runtime performs its license check, finds the date is in the past, and refuses to continue. Instead of the program’s usual opening screen or output, the user sees an error message telling them the license has expired.
This happens before any of your actual code runs. Your program does not open and then close, and it does not run in a reduced or broken state. From the user’s point of view, the script simply will not start, in much the same way that an expired software trial refuses to open after the trial period ends.
Your Data Stays Safe, but Watch the System Clock
It is worth knowing that nothing else changes. The user’s files, saved data and settings are untouched, because your program never got far enough to read or write anything. As soon as a renewed license is in place, the same script on the same machine starts working again as if nothing had happened.
One practical detail is that the check uses the clock on the user’s computer. If a machine’s system date is set incorrectly, a script can appear to expire early or a renewed license can look out of date. When a customer reports a sudden expiry that does not match your records, asking them to check their system clock is a sensible first step.
The Difference Between Your Pyarmor License and a Script’s Own Limits
Two different licenses are easy to confuse here. The first is your own Pyarmor license, which is the registration that lets you use the tool itself to protect scripts. The second is the license attached to a protected script, which controls the person running that script. They work independently of each other.
If your own Pyarmor registration lapses or is not renewed, that affects you, the developer. You may be unable to protect new scripts or use the tool’s full features until you sort it out. However, scripts you already protected and handed over keep following the rules you set inside them, because those rules were fixed when the scripts were created.
Renewing One License Does Not Fix the Other
The reverse is also true. Renewing your own Pyarmor license does not extend the deadline inside a script you shipped last year. If that script was protected with an expiry date, it will still stop on schedule for the user, no matter how current your own registration is. Each limit has to be managed on its own terms.
Keeping this separation clear prevents the most common support confusion in this area. A customer whose script has stopped almost always has a script-level expiry problem, not a problem with your developer license. Understanding how licensing controls work for shared scripts makes it much easier to set the right limit in the right place.
What Renewing or Reissuing a License Changes
Renewal simply replaces an old permission with a new one. When a user’s license expires, you generate a fresh license file with a later date and send it to them. They place the new file where the old one was, and at the next launch the runtime finds a valid date and lets the script run again.
Where the expiry was placed decides how simple this is. If the deadline lives in the license file, renewal is quick, because only that small file changes and the protected script itself stays exactly as it was. You can renew one customer without touching anyone else, and there is nothing new for the user to install beyond swapping a single file.
When the Deadline Is Baked Into the Script
If the deadline was baked into the protected script itself, renewal is more work. The script carries the date internally, so you have to protect it again with a new date and send the user a fresh copy of the whole script. This is worth remembering when you first set up a script you expect to renew often.
Reissuing also gives you a chance to adjust other terms at the same time. You can extend the date by a month or a year, or pair the new date with other limits the license supports. Just keep a record of who was issued what, because when a user asks why their script stopped, your records are how you answer them quickly.
Planning Expiry So Paying Users Are Not Caught Out
Most expiry problems are planning problems rather than technical ones. The single most helpful habit is to warn users before the date arrives. A short email a week or two ahead, or a reminder inside your own documentation, turns a nasty surprise into a routine renewal.
Build in a small safety margin where you can. Setting expiry a little beyond the paid period, such as a few extra days, protects customers in other time zones and anyone whose renewal payment is processed slowly. It costs you very little and prevents the worst kind of support message, the one from a paying user locked out mid-job.
Keep Records and Test the Expiry Yourself
Keep a simple register of every license you issue. Note the customer, the script, the expiry date and any other limits you set. When renewal time comes, you will know who to contact, and when something goes wrong you can check in seconds whether the script behaved exactly as it was told to.
Finally, test the expiry behaviour yourself before you ship. Protect a test copy with a date in the near future, run it either side of that date, and watch what the user will see. Knowing the exact message your customers get means you can explain it calmly and fix it fast when it happens for real.
Frequently Asked Questions
Does an expired license delete or damage the script?
No. The script and the user’s data stay exactly as they were. The runtime simply refuses to start the program until a valid license replaces the expired one.
Can the user change their system clock to get around expiry?
The date check relies on the machine’s clock, so clock tricks are a known weakness of any offline expiry system. For most commercial scripts the protection is a practical barrier rather than an absolute one, and it works because honest customers renew instead of tinkering.
Do I need to re-protect my script every time a customer renews?
Only if the expiry date was baked into the protected script itself. If the deadline sits in the license file you issue, renewal means generating and sending a new file, and the script does not change at all.
What message does the user see when the license expires?
They see an error at startup telling them the license has expired, and the program does not open. The exact wording depends on the runtime, which is why testing it yourself before shipping is so useful.
Conclusion
When a Pyarmor license key expires, the protected script checks the date at startup and simply refuses to run until a valid license is in place. Nothing is deleted, and a renewed license file restores everything in moments. Keep your own developer license separate in your mind from the limits inside your scripts, record every expiry date you issue, and warn users before the deadline arrives. Handled that way, expiry becomes a calm, predictable part of selling scripts rather than a source of urgent support calls.
Pingback: Can Pyarmor stop a protected program from running on other machines? - Pyarmor