Orthic Labs / Notes / Ownership
Ownership · software update policy
A Fair Software Update Policy: Seven Rules for Software You Own
A fair software update policy repairs supported versions, authenticates every release, explains major upgrades and never removes a purchased feature merely to force a new payment. It can end support without pretending that the customer's existing license never existed.
Updates combine several different obligations under one button: security repair, bug fixing, compatibility work, feature delivery, data migration and sometimes a new product. A useful policy separates them.
1. Define patch, update and major upgrade
The labels should predict the commercial and technical consequence.
- Patch: repairs a defect or security issue in a supported purchased version.
- Update: changes the current product while preserving its identity and user data.
- Major upgrade: a separately defined product generation that may require a new purchase.
Marketing names do not decide the category. If a release is delivered as an ordinary update and removes previously purchased capability, calling it “the new experience” does not make the loss fair.
2. Keep the purchased version licensed
When software is sold as one-time or perpetual, declining a future major upgrade should not deactivate the version already bought.
The old version may eventually stop receiving fixes. It may become incompatible with a future operating system. Those are lifecycle limits. Remote deactivation or a newly imposed subscription is a different act: it changes the bargain after purchase.
Read the broader one-time purchase software checklist before treating a billing label as an ownership promise.
3. State the support window before it matters
A publisher cannot support every historical version on every future OS forever. A fair policy states:
- Which versions are currently supported.
- Which operating-system versions are tested.
- How much notice precedes end of support.
- Whether critical repairs can extend past feature support.
- What continues to work after support ends.
Silence transfers all uncertainty to the customer.
4. Never use an update to repossess a feature
An update may remove a dangerous or impossible feature, but the publisher should identify the reason and provide a migration or alternative where possible.
It should not move a capability the customer already bought behind a new recurring tier merely because recurring revenue is preferable. That turns the update channel into a pricing weapon.
The strongest rule is simple: an update should not make the license smaller.
5. Sign and verify every delivered release
An automatic updater is a privileged software-delivery mechanism. It needs cryptographic verification, publisher-controlled keys, secure manifests and failure handling.
Read what a signed installer proves. The same origin and integrity questions apply to every update after installation.
The policy should also describe what the user sees before material changes: version, release notes, restart requirements, data migration and rollback limitations.
6. Preserve user data and provide recovery
Updates should not silently move, overwrite or reformat user data without a tested migration. Before a one-way change, the product should create a recovery point or explain the backup requirement.
A useful update contract covers:
- Configuration migration.
- Project and document compatibility.
- Model or cache replacement.
- Interrupted-download recovery.
- Failed-install rollback.
- Uninstall behaviour.
The updater is finished only when failure has an exit.
7. Separate recurring service from local capability
A desktop product may include a hosted component whose operating cost recurs. The policy should identify that service separately from the installed local version.
If cloud storage, a data feed or regulated integration expires, say which remote feature stops and which local capability remains. Do not let one service dependency obscure the rights attached to the rest of the product.
A buyer-readable policy template
| Question | Required answer |
|---|---|
| What did you buy? | Named version or clearly defined version family |
| What repairs are included? | Patch and support boundary |
| What may cost extra? | Future major upgrade or recurring external service |
| Can you decline? | Existing purchased version remains licensed |
| Can an update remove a feature? | Only with a stated safety/compatibility reason and migration plan |
| How is delivery verified? | Signed installer and signed update payload |
| What happens to your data? | Migration, backup, rollback and export behaviour |
| When does support end? | Published lifecycle and notice process |
If the answer to any row is “whatever the current terms page says,” the purchase is not durable enough.
What “lifetime updates” gets wrong
The phrase compresses three different promises:
- The license does not expire.
- The current product line receives updates.
- Every future major product is included.
Those promises have different costs and durations. A publisher should state the exact one it offers. A customer should not have to infer it from an asterisk.
Orthic prefers version and entitlement language over an undefined lifetime claim.
The publisher's operating discipline
A fair written policy fails if the release system cannot enforce it. The implementation must keep repair releases distinct from paid feature releases, preserve entitlements, replace current artifacts cleanly, and verify signatures before installation.
This is part of software productization: commercial language, updater architecture and release operations must describe the same reality.
Mistakes to avoid
Promising all future work. Sell a defined product rather than an unbounded obligation.
Ending support without explaining continued use. Support status and license validity are separate.
Changing terms inside an installer. Material purchase boundaries should be visible before checkout and retained with the receipt.
Skipping rollback because updates usually work. Recovery exists for the release that does not.
Using release notes as advertising. Name fixes, changes, removals, migration and known limits.
Frequently asked questions
Do perpetual licenses include updates?
Only if the terms say so. A perpetual license keeps a defined version usable; updates may be included for a period, within one major version, or under a separate plan.
Can a publisher stop supporting a purchased version?
Yes. Support and compatibility obligations can end. A fair lifecycle gives notice and distinguishes end of support from cancellation of the existing license.
Should security patches always be free?
Publishers should state which supported versions receive security repairs. The exact obligation depends on the product and terms, but customers should not discover the boundary only after a vulnerability appears.
Is an automatic update safer than a manual installer?
Not automatically. Automatic updates reduce friction but create a powerful delivery channel. Safety depends on authenticated manifests, signed payloads, key protection, testing and recovery.
Keep the tool; understand the lifecycle
Read the one-time purchase ownership test and signed-installer guide. A fair update is not free work forever. It is a release that respects the version and rights already delivered.
About Orthic Labs: Orthic Labs is an independent software publisher. It turns open-source ingredients into finished, documented and supported desktop software.