Pyarmor licensing works by giving every customer their own license file, which the protected script checks each time it starts. The script itself is locked with obfuscation, and the license file acts as the key that decides whether it may run, on which machine, and until what date. Pyarmor licensing controls turn a script you could once only give away into something you can sell with terms attached.
This matters because a plain Python script is easy to copy. Once you email it to one buyer, nothing stops that buyer from passing it to ten friends. Licensing changes the economics: even if the files are copied, the program will not run for someone whose license does not allow it.
This article explains what a license key actually controls, how you can give different customers different terms, and how expiry dates combine with keys. It also covers what your customer needs in place to run your script, and the common mistakes that accidentally lock out people who have paid.
What a License Key Controls in a Protected Script
A license in this system is a small file you generate for a specific customer after you protect your script. When the script starts, the runtime that travels with it reads the license file before any of your code runs. If the license is present and valid, the program opens normally; if it is missing or does not check out, the script refuses to start.
The most basic thing a license controls is permission itself: this person may run this program. On top of that, a license can carry a deadline, so permission ends on a date you choose. It can also be tied to a particular computer, using identifying details of that machine, so the same license file will not work if it is copied to a different computer.
Checks Happen Locally, Even Offline
All of this checking happens locally, on the customer’s machine, at the moment the program launches. There is no account to sign into and no server involved in the everyday decision. The license file, the protected script and the runtime form a self-contained package, which is why the system keeps working on machines that are offline.
The licensing system is part of the wider protection offered by Pyarmor: obfuscation hides what your code does, while licensing controls who is allowed to run it at all. The two halves work together, and a seller needs both halves set up thoughtfully.
Giving Different Customers Different Terms
Because each license is generated individually, no two customers have to share the same terms. One buyer might receive a license that runs for a year on a single office computer. Another might pay more for a license covering a longer period, or for permission that is not tied to one machine because they reinstall their system often.
This flexibility is what makes licensing commercially useful. You can sell a short, cheaper evaluation licence to a cautious new customer, then issue a full license when they commit. You can give a long-standing customer a generous renewal and a brand-new customer a standard one, all for exactly the same protected script.
One Protected Script, Many Different Keys
The protected script does not change between these customers. You obfuscate your program once, then generate a separate license file for each buyer as they purchase. That keeps your side of the process simple: one product, many keys, each key recording the bargain you made with that particular person.
Keep a record of every license you issue, noting the customer, the date limits and any machine tying you applied. When a customer writes to say their script has stopped, your records tell you immediately whether the license behaved as agreed or whether something has genuinely gone wrong.
The Same Simple Process as Sales Grow
This approach also scales gracefully as sales grow. Whether you have three customers or three hundred, the work per sale stays the same: take the order, generate one license file with the right terms, and send it with the standard package. There is no licensing server for you to maintain and no activation website for customers to struggle with, which keeps a small software business feeling small in the best possible way.
Combining Expiry Dates With License Keys
An expiry date is the most common companion to a license key. The key says who may run the script, and the date says for how long. Together they create the familiar arrangement behind trials, subscriptions and annually renewed software, except that here it is applied to a script you hand over as files.
A typical pattern is the paid trial that converts. You issue a license that expires in thirty days so a prospect can evaluate the real program, not a crippled demo. If they buy, you send a fresh license with a year on it, and they keep using the same script they already have installed.
Expiry That Stops Cleanly and Restarts Fast
Understanding exactly what happens when a license key expires helps you set dates your customers will experience as fair. The program stops cleanly at the deadline rather than misbehaving, and a renewed license file restarts it in moments, which makes expiry a civilised enforcement tool rather than a punishment.
When you set dates, think about time zones, slow payments and holidays. A license that ends at the close of a customer’s busiest week creates anger out of proportion to the money involved. A few days of grace costs you almost nothing and buys goodwill that matters when renewal is discussed.
What the Customer Needs Installed to Run Your Script
From the customer’s side, running your product is meant to be simple. They receive a folder containing the protected script, the runtime files that were produced when you obfuscated it, and their personal license file placed alongside them. Everything the program needs to check its own permission travels in that one package.
The machine also needs a suitable Python environment, because a protected script is still a Python program underneath. The version of Python on the customer’s computer must be compatible with the one your protected files were prepared for. Most support problems in this area turn out to be version mismatches rather than licensing faults.
No Tool to Buy and No Source Code to See
The customer does not need their own copy of the Pyarmor tool, and they never see your original source code. Installing your product is a matter of unpacking what you sent and starting the program; the license check happens silently in the first moment of launch.
Clear instructions help enormously here. Tell customers to keep the license file in the folder with the script, because moving the script away from its license and runtime files is the easiest way to make a perfectly good purchase refuse to start.
Common Licensing Mistakes That Lock Out Paying Users
The most painful mistake is tying a license to a machine too eagerly. A license bound to one computer stops working when that computer is repaired, upgraded or replaced, and the customer experiences it as your software breaking. Only use machine tying when your pricing genuinely depends on it, and have a quick reissue process ready when it bites.
A second mistake is the forgotten renewal. If you sell yearly licenses but never warn customers the date is coming, their script stops mid-work and the first you hear of it is an angry message. A reminder shortly before expiry, plus the small grace period mentioned earlier, prevents nearly all of these incidents.
Wrong Files Sent and Tests Skipped
A third mistake is sloppy file handling on your own side. Sending a customer the wrong license file from a folder of similar-looking files, or an older file you generated during testing, produces a refusal that looks like a product defect. Name license files by customer and date so the right one is obvious at a glance.
Finally, test every arrangement before it ships. Run your script with the exact license you are about to send, on a clean machine if you can. Two minutes of checking proves the customer will see a working program, and it is far cheaper than the support conversation that follows a locked door.
Frequently Asked Questions
Does each customer need a different license file?
Yes, that is how the system is designed to work. You protect the script once, then generate a separate license for each buyer, so every customer’s terms, dates and machine limits can differ.
Can a customer share their license file with a friend?
They can copy the file, but that does not mean it will work. If the license is tied to their machine or carries their own expiry terms, the copy will fail its checks on a different computer or run out on schedule.
Does the customer need to buy Pyarmor themselves?
No. Your customer only needs the package you send them: the protected script, its runtime files and their license file, plus a compatible Python installation. Your own registration of the tool covers the protection work.
What happens if a customer’s computer is replaced?
If their license was tied to the old machine, it will not pass its checks on the new one. You simply generate a replacement license for the new machine and send it over, which is why keeping good issue records matters.
Conclusion
Pyarmor licensing for scripts you sell or share rests on a simple idea: one protected script, and a personal license file for every customer that the script checks at startup. Those licenses can carry expiry dates and machine limits, giving you trials, subscriptions and per-customer terms without accounts or servers. Issue each license carefully, keep records, warn people before deadlines, and test before you send. Done that way, licensing quietly protects your income without ever punishing the customers who pay you.
Pingback: Does a protected program stop working when a Pyarmor license expires?
Pingback: Why does Pyarmor registration fail even with a valid code?