Licensing
What Is a EULA? The Software License Agreement, Explained
A EULA licenses software to a user instead of selling it. Here's what each clause means, how a EULA differs from a ToS, and what software sellers need in one.
A EULA — End-User License Agreement — is the contract between the maker of a piece of software and the person using it. It says one thing above everything else: you’re not buying the software, you’re buying a license to use it. The maker keeps ownership of the code. You get permission, with conditions attached.
Everything else in the document — the restrictions, the liability limits, the termination clause — hangs off that one idea.
I’ve been shipping WordPress products since 2009, and I’ve read more of these agreements than I’d wish on anyone. Here’s the whole genre in plain English.
Five clauses do almost all the work in a typical EULA. The rest is padding.
What a EULA says, in plain English
Strip the legalese and nearly every EULA makes the same five moves: it grants you a license, restricts what you can do with it, declares who owns the code, caps the maker’s liability, and explains how the deal ends. A 40-page agreement and a 2-page one usually differ in padding, not in substance.
License grant. “We give you permission to install and use this software” — usually on a set number of devices, for personal or business use, sometimes for a limited time.
Restrictions. What you may not do: copy it, resell it, reverse-engineer it, rent it out, remove the copyright notices.
Ownership. The maker keeps the copyright and all intellectual property. Your license is permission, not a transfer.
Liability limits. If the software eats your data, the maker’s responsibility is capped — often at what you paid for it, sometimes at nothing.
Termination. Break the rules and the license ends. Some agreements also let the maker end it for convenience.
That’s the skeleton. The EULA meaning, condensed to one sentence: a license to use, under conditions, with ownership staying home.
EULA vs Terms of Service vs Privacy Policy
People treat these three documents as interchangeable. They aren’t. A EULA governs software you install and run; a Terms of Service governs an online service you access; a Privacy Policy discloses what data gets collected and why. One product can need all three.
| Document | Governs | Typical example |
|---|---|---|
| EULA | Installed software — the license to run the code | A desktop app, a WordPress plugin, a mobile game |
| Terms of Service | Use of a hosted service or account | A SaaS dashboard, a social network, an API |
| Privacy Policy | Collection and handling of personal data | Any product that touches user data |
The line blurs in practice. A photo editor with cloud sync is installed software (EULA) talking to a hosted service (ToS) while processing your images (Privacy Policy). Vendors often merge everything into one agreement. That’s fine legally — but when you’re reading one, knowing which hat each section wears tells you what’s actually being promised.
Do people have to accept it?
Practically, yes — modern software won’t install or run until you click “I agree,” a pattern lawyers call clickwrap. Whether that click creates an enforceable contract is messier, and the answer varies by country and by how the agreement was presented.
The broad pattern: courts have been friendlier to clickwrap — where you took a clear, deliberate action to accept — than to “browsewrap,” where the terms sat behind a link you never had to open. And even an accepted EULA isn’t bulletproof. Consumer-protection law in many jurisdictions can override specific terms; clauses banning reverse engineering or resale have been trimmed by courts and regulators in parts of the world. The Wikipedia entry on end-user license agreements keeps a decent running history of these disputes if you want the case-by-case detail.
The practical takeaway for a software seller: make acceptance an explicit click before purchase or install, keep the terms reachable in one click, and don’t assume every clause you write will hold everywhere. This is context, not legal advice.
EULAs and open source
Open-source licenses flip the EULA model on its head. Instead of restricting what users can do, a license like the GPL guarantees what they can do: run the code, read it, modify it, redistribute it. The GPL version 3 text is explicit that you can’t bolt on extra restrictions that take those freedoms back.
This matters enormously in my corner of the world. WordPress itself is GPL, and plugins and themes that build on it are GPL for their PHP code. So a commercial WordPress plugin can’t use a classic restrictive EULA to forbid copying the code — the GPL already granted that right, and yes, that’s why nulled plugins exist in a legal gray zone rather than being straightforward piracy.
What a commercial plugin’s “EULA” (usually called terms of purchase) actually governs is everything around the code: your support entitlement, the license key that unlocks automatic updates, access to the vendor’s update servers, and the vendor’s trademarks. The code is free as in GPL; the service relationship isn’t. That’s an honest, sustainable model — the update-and-support pipeline is what customers renew for, and license activation is the mechanism that meters it.
If you sell WordPress products, be precise about this in your terms. Claiming your PHP code is proprietary when it’s GPL-derived isn’t just wrong, it erodes trust with the developers most likely to buy from you.
A EULA checklist for software sellers
If you’re selling software rather than just using it, your agreement needs to answer eight questions before a customer asks them. This is an explainer, not legal advice — have a lawyer review your actual agreement.
- Grant scope. Personal or business use? One user or a team? Perpetual or for the license term?
- Seats and activations. How many sites, devices, or installs per key? What happens at the limit?
- Refunds. How many days, and what voids eligibility? Say it plainly; disputes cost more than refunds.
- Support scope. What’s included (bug fixes, help channels), for how long, and what’s explicitly out (custom development).
- Updates. Are updates tied to an active license? What does the customer keep after expiry?
- Liability. Cap it — typically at the purchase price — and disclaim consequential damages.
- Governing law. Pick a jurisdiction. Ambiguity here helps nobody.
- Termination and revocation. What conduct ends the license, and what happens to installed copies.
Half of that checklist only works if your systems enforce it. Activation limits, license expiry, update gating, and refund-triggered deactivation are infrastructure problems, not paperwork problems — the Core Forms licensing server handles that enforcement layer for WordPress products, and I’ve written a full walkthrough on selling WordPress plugins end to end. One honest boundary: no license server calculates or remits global sales tax for you. That stays between you, your payment provider, and your accountant.
FAQ
What does EULA stand for?
EULA stands for End-User License Agreement. It’s the contract between a software maker and the person using the software, and its core function is granting a license to use the software rather than transferring ownership of it. You’ll also see it called a software license agreement or licensed application agreement.
Is a EULA legally binding?
Generally yes, when the user actively accepts it — the clickwrap pattern of clicking “I agree” before install or purchase. Enforceability varies by jurisdiction, though, and consumer-protection law can override specific clauses. Presentation matters: buried terms nobody had to see are the weakest form. Have a lawyer review yours.
What’s a common EULA example?
Every major software install shows one: the agreement screen before installing an operating system, the terms you accept when downloading a mobile app, or the checkout terms when buying a premium WordPress plugin. Apple’s Licensed Application End User License Agreement, which covers most App Store apps, is a widely seen example.
Do I need a EULA for a WordPress plugin?
You need terms of purchase, but not a classic restrictive EULA — plugin code building on WordPress is GPL, so you can’t forbid copying it. Your terms should instead govern support, license keys, update access, refunds, and trademarks. That’s the layer you actually control and the one customers pay for.