Orthic Labs / Notes / Ownership
Ownership · one-time purchase software
One-Time Purchase Software: What Ownership Should Include
One-time purchase software should let you keep using the purchased version without another payment, while clearly separating that durable right from future major versions, external services and unlimited support. “Pay once” is incomplete unless those boundaries are written down.
You rarely own software in the same sense that you own its copyright or source code. You receive license rights. The useful consumer question is therefore not “Do you literally own the code?” It is “Which rights and working version survive after the transaction?”
The eight-part ownership test
1. The purchased version keeps working
Stopping payment should not remotely disable a version sold as perpetual or one-time. If a product needs a server for its core workflow, the publisher must explain how that dependency affects continuity.
2. The license terms name the version boundary
Does the purchase cover one major version, all minor updates in a series, or every future version? Any answer can be workable if it is explicit before checkout.
“Lifetime” without a defined subject is not precise. Whose lifetime? The product, the company, the purchaser, the operating system or the current major version?
3. Bug and security fixes are distinguished from new products
A fair policy separates repairs to the purchased version from a genuinely new major product. The publisher should state which supported branches receive fixes and when support ends.
This does not create an infinite obligation to maintain every old version against every future operating system. It creates a duty to state the support window and avoid taking away what was sold.
4. The installer remains retrievable
Durable license rights are weak if the only installer disappears immediately. The policy should explain whether customers can redownload the purchased version, retain a local installer, or access an archive.
The archive also needs integrity. A retained installer should be signed so the operating system can detect alteration and identify the publisher.
5. Local work does not become hostage to routine activation
Initial activation or occasional license validation may be part of the product. But a one-time local tool should explain what happens when the activation service is unreachable and whether already-activated installations continue to work.
6. Your files remain usable
Ownership of access matters as much as ownership of a binary. The product should write standard files or offer a documented export path. A perpetual license that traps years of work in an unreadable format creates a different kind of dependency.
7. Hardware and device rights are clear
The terms should state how many personal devices are allowed, whether Windows and macOS are separate purchases, and how deactivation or replacement works. Avoid discovering the device policy only after a machine fails.
8. External services are named separately
Some features create recurring costs: hosted storage, provider APIs, email compliance, server-side processing or real-time collaboration. A publisher can charge recurring terms for recurring operation without converting every local feature into rent.
The honest model assigns recurring prices to recurring burdens and durable prices to durable local capability.
Compare common software purchase models
| Model | What continues after payment stops? | Main tradeoff |
|---|---|---|
| Perpetual version | The licensed version | Future major upgrades may cost extra |
| Perpetual + update window | Licensed version plus updates released during a period | Must define repair versus major upgrade |
| Subscription | Usually access ends | Ongoing service and updates are bundled |
| Free tier + one-time Pro | Free core remains; purchased Pro version remains | Publisher must define future-version policy |
| Hosted service | Data/service access depends on operation | Recurring infrastructure is part of the product |
No model is inherently honest. The contract and architecture decide that.
Questions to ask before buying
- If you never pay again, which version can you keep using?
- Can you download that installer again?
- Which fixes are included, and for how long?
- What happens when a new major version appears?
- Does the app need a server for its core job?
- Can you export your work in usable formats?
- How many devices and operating systems are covered?
- Which features have real recurring external costs?
- Can an update remove a feature you already bought?
- What happens if the publisher closes?
If the checkout page cannot answer these questions, “one-time” is a payment schedule rather than an ownership policy.
The Orthic standard
RightSuite is built around useful free tiers and one-time Pro purchases where the job can run locally without a continuing external burden. The installed purchased version should remain usable; an update should not take away a feature already bought.
That standard does not promise every future major product or unlimited human support. It promises a legible deal:
- Pay once where the capability can be delivered once.
- Name recurring exceptions where the burden genuinely recurs.
- Keep the purchased tool instead of converting it into permission later.
The distinction begins with open source versus commercial software: license rights, product work and service obligations are separate dimensions.
When a subscription is reasonable
A subscription can be the clearer model when the product is continuous operation: hosted compute, shared storage, ongoing data feeds, collaboration infrastructure or a regulated service that requires recurring work.
The objection is not recurring payment for recurring value. It is recurring permission imposed on a local capability whose use creates no corresponding monthly operation.
Mistakes to avoid
Buying the word “lifetime.” Read the version, update, device and installer terms.
Assuming one-time means every future version. Durable use of a purchased version and perpetual future development are different promises.
Ignoring operating-system drift. A version can remain licensed but stop working on a future OS. Support and compatibility windows matter.
Forgetting data exit. A lasting binary is not enough if your work cannot leave it.
Treating every network call as a recurring service. License checks and update downloads do not automatically justify renting the core local tool.
Frequently asked questions
Is a one-time purchase the same as a perpetual license?
Often, but verify the terms. A one-time payment describes billing. A perpetual license describes duration. The contract must connect the payment to a non-expiring right to use a defined version.
Does a perpetual license include lifetime updates?
Not necessarily. It may include updates for a period, minor releases within one major version, or only the purchased release. The update boundary should be explicit before purchase.
Can one-time software still require activation?
Yes. Activation can enforce device rights, but the publisher should explain offline behavior, service outages, machine replacement and what happens if activation infrastructure closes.
Is subscription software always worse?
No. Subscription can be appropriate for continuously operated services. Judge whether the recurring price funds a recurring dependency or merely keeps a completed local capability unlocked.
Read the deal before the slogan
Inspect the Orthic philosophy, the software productization process, and the public RightSuite repository. The useful promise is not “cheap forever.” It is a contract whose boundaries remain true after checkout.
About Orthic Labs: Orthic Labs is an independent software publisher. It turns open-source ingredients into finished, documented and supported desktop software.