Software That Is Sold, Not Rented

This paper is provided for engineering, operational, and research purposes and does not constitute investment advice or a solicitation to invest in any Woodfine direct-hold solution. Statements marked "planned," "intended," "targeted," "may," or "expected" are forward-looking and subject to change. Full disclosures appear at the end of this paper.

Working Paper PDS-012 · v0.1.0 · CC BY 4.0

Our thesis is that business software should be sold once, in full, for a specific version that keeps working afterward — not rented by the month against the threat that it stops. A buyer who pays for a hammer owns the hammer. Nobody at the hardware store retains the ability to make it stop swinging if the buyer declines to purchase next year's model. Almost all business software has drifted away from that arrangement in the past fifteen years, and the drift has been treated as a fact of technology rather than what it actually is: a commercial choice, made by sellers, about where to put the off switch.

The arrangement we intend has three parts, and this paper takes each in turn. The first is the price: the full charge paid up front, at the time of purchase, with no ongoing account relationship required for the software to keep running. The second is the release cycle: a stable version that stays stable for years, rather than a continuous stream of changes a customer is obliged to absorb. The third is the part that decides whether the first two are real or decorative — where enforcement actually sits in the running system, which is the only question that determines whether a seller can switch a customer off, regardless of what the seller promises.

On that third part there is a fact to report rather than an intention. In the system running today, licence checks exist in two places, and both sit on the paid side of the commercial boundary: the server that hands out release files, which checks before a download begins, and the paid aggregation layer, which checks its own licence at startup and stops offering its own paid service if that licence has lapsed past a grace period. We looked for a licence check in the free software a customer actually runs to hold and work with their records — the archive operating system, the console, the workplace system — and there is none to find. That is not a promise about our future conduct. It is a property of the code, and a reader with access to the published source can confirm it in an afternoon.

1. The thesis

A software sale can be structured in two ways, and the difference is not the payment schedule. It is the location of the mechanism that decides whether the software runs.

In the first arrangement, the buyer receives a copy and the permission to use it, and the copy runs on the buyer's own machine without asking anyone's leave. Payment and operation are separate events: payment happened once, in the past, and the software's continued functioning does not consult it. In the second arrangement, the software asks a question before it runs, or periodically while it runs, and somebody other than the buyer decides the answer. Whether the buyer pays monthly or annually is immaterial to this distinction — what matters is that a party who is not the buyer holds a switch.

We hold that the first arrangement is the correct one for the records and operations of a business, and that the second is acceptable only for things a business can afford to lose access to on an hour's notice. An accounting system, a personnel record, a property history — these are not things a company can afford to lose access to because a payment card on file expired while the bookkeeper was on holiday.

The composition is the claim, and none of its parts is novel on its own. Software has been sold outright since software was sold at all. Long stable release cycles are ordinary in the operating-system business, where a serious vendor may support one version for the best part of a decade. Support sold separately from the product is the oldest arrangement in commercial computing. What we hold is that applying all three together, with no licence check anywhere in the running system, produces a purchase a business can evaluate the way it evaluates buying a vehicle or a piece of plant — and that this has become unusual enough to be worth arguing for explicitly.

2. The problem, in the reader's terms

Consider two ways of getting the use of a building.

You can buy it. The price is large, it is paid at the front, and afterwards the building is yours. The seller has no further involvement. If the seller's business fails, nothing happens to your building. If the seller raises prices, nothing happens to your building. You may choose to hire the seller for maintenance, and you may choose not to, and either way the roof stays on.

Or you can rent it. The price is smaller each month, which is genuinely easier at the start. But the landlord sets the rent at each renewal, the landlord decides what improvements are made and what is allowed, and — the part that matters most — the landlord can require you to leave. Everything you have built up inside is subject to a relationship you do not control, and the relationship is renegotiated on a schedule the landlord sets.

Business software has moved almost entirely from the first arrangement to the second, and the argument made for the move is a good one as far as it goes: renting is cheaper to start, spreads cost over time, and keeps the tenant current. All true. What is rarely said as plainly is the other half. A rented tool can have its rent raised. A capability the tenant relies on can be moved behind a higher tier. And access ends when payment does — not gradually, not with notice proportional to how long the tenant has been there, but on the day the billing system records a failure.

Two things follow that are worth separating, because they are usually blurred into an accusation of bad faith that the situation does not require.

The first is that the cost of leaving is itself a source of pricing power, entirely unrelated to the quality of the product. This is not a suspicion. It is a developed result in the economics of markets where customers face costs to switch, which shows that the mere existence of a cost to leave changes what a supplier can charge a customer who has already arrived [farrell-klemperer-2007-switching-costs]. The same literature treats lock-in of this kind as a structural feature of information markets rather than a failing of particular firms [shapiro-varian-1998-information-rules]. No seller needs to intend anything for the incentive to operate on them.

The second is that a continuing relationship is not free of cost merely because it is continuing. Where one party can change the terms and the other has already committed, economists describe the arrangement as governing an ongoing contractual relation rather than completing a transaction, and the governance of that relation is itself expensive [williamson-1979-transaction-cost-economics]. A business on a subscription is not simply paying a monthly fee. It is also carrying the standing obligation to watch what the supplier does next.

A buyer feeling uneasy about this is not being sentimental about the old days. They are noticing, correctly, that the thing they thought they had bought is a tenancy.

3. What a software licence actually is

This section establishes vocabulary. A reader who already knows what a licence is may skip to the next section without missing an argument.

Copies, permissions, and keys

Software is unusual among the things a business buys in that it can be copied perfectly and at no cost. That single fact is why software is sold the way it is. When you buy a vehicle, the seller's control over what you do with it ends at the forecourt, because there is only one of it and you have it. When you buy software, the seller has not given up anything physical — they have given you a copy and, separately, permission to use it.

The permission is the licence. It is a legal document, not a technical one. It says what you may do with the copy: run it, on how many machines, for how long, whether you may modify it, whether you may pass it on. The licence is enforced the way any contract is enforced — by the courts, slowly and expensively, and in practice almost never against an ordinary business customer.

Because legal enforcement is impractical at small scale, sellers add a technical mechanism. Historically this was a serial number typed at installation. Today it is usually a licence key or token: a piece of data the software checks before it will operate. The key is technical enforcement layered on top of legal permission, and the two can say different things. This matters more than it sounds. Most of what a buyer experiences as "the licence" is actually the key — what the key permits is what the buyer can do, whatever the document says.

Where the check happens is the whole question

A licence key has to be checked somewhere, and there are only three places a seller can put the check.

It can be checked once, at the point of delivery — when you obtain the software. Pass the check and you have the file; from then on, the file is yours and runs without further reference to anyone. This is the shape of a physical purchase, expressed in software.

It can be checked every time the software starts, against something stored on the machine. This is the old serial-number model. It gives the seller a switch, but a weak one: the switch is in the buyer's possession, on the buyer's hardware.

Or it can be checked continuously, against the seller's own servers. This is the subscription model in its technical form, and it gives the seller a real switch — one they hold, can throw at any time, and can be compelled by others to throw.

The industry's move to the third arrangement was gradual and was mostly sold on other grounds: automatic updates, easier installation, synchronised settings across devices. Each benefit is genuine. What travelled quietly along with them was the relocation of the switch.

The signature, plainly

One more piece of vocabulary, because it appears in the next section. A licence key in a modern system is not a serial number a person could guess. It is a short piece of data carrying a digital signature — a mathematical seal that only the holder of one particular secret key can produce, and that anyone holding the matching public key can check. The arrangement works like a wax seal whose pattern is published so that everyone can recognise it, while the stamp that makes the impression never leaves the sender's desk. The signature scheme used here is a widely adopted published one, designed for speed and for resistance to a family of implementation mistakes that had caused real failures in earlier schemes [bernstein-2012-ed25519]. A companion paper on this site treats what independent verification of such a seal makes possible; here the only point that matters is that the check is a matter of arithmetic and requires no permission from anyone.

4. Where the enforcement actually sits

Where a licence is checked, and where it is not

The distribution system behind this platform's software has three parts: a watcher that observes payments, a storefront that issues a signed licence token once a payment is confirmed, and a release server that hands out the compiled software. The licence check lives in the third of those, and only there.

When a request for a release arrives, the release server takes the token presented with it, confirms the seal against its stored public key, and reads three things from the sealed contents: which product the token is for, what the token permits, and the date on which the token's release channel expires. If the seal is bad, the request is refused. If the token is for a different product, the request is refused. If the channel date has passed, the request is refused. Otherwise the file is sent.

Note what that is a check on: the right to be handed a release. The word used in the sealed contents for the expiring thing is the channel — the stream of releases — not the software.

There is a second enforcement point, and naming it is the difference between an honest account and a flattering one. The paid aggregation layer — the commercial component that asks one question of many archives at once — checks its own licence when it starts. That check is entirely offline, made against a public key built into the component itself, with no call to us at any point. If the licence is absent, invalid, or expired past a grace period of thirty days, the component still starts and still reports that it is running, but the paid service it offers is withdrawn until a valid licence is supplied. The same pattern appears in the other paid component of that family: it continues in a reduced, read-only mode and refuses the operations the licence pays for.

That is the paid layer enforcing the thing that was paid for, which is what a commercial gate is for. The point worth holding on to is where the gate is not. A companion paper on this site argues that the free-to-paid boundary on this platform is architectural — one archive and its console are free, and the layer above them is the commercial product. Enforcement follows that same line exactly. The gate is in the paid layer. There is no gate in the free software, which is where a customer's records actually live.

What we looked for and did not find

The claim that matters to a buyer is not what the release server does. It is what the software does once it is on their machine. So we looked, in this pass, directly at the source of the three things a customer actually runs: the operating system that runs inside an archive, the console used to work with one, and the workplace system. There is no licence check in any of them. No token is read. No entitlement is consulted. No expiry is compared against a clock. There is no code to remove, because there is no code.

This is worth stating in the blunt form rather than the flattering one. It is not that we have generously chosen not to enforce here. It is that the enforcement points are at delivery and in the paid layer, and the free components a customer runs have no idea that licensing exists. A copy of them already installed does not stop working when a token expires, because nothing in it is looking.

There is a further consequence the same design produces, which we did not set out to advertise and will state anyway. The release server reads a small description file accompanying each product, and that file may declare that the product requires no licence at all — in which case the server hands it to anyone who asks, with no token and no payment. Some products are distributed that way deliberately. The mechanism that would let us gate everything is the same mechanism that lets us gate nothing, and both settings are visible in the same place.

The honest limits of that arrangement

Three present-tense limits belong here rather than in a footnote.

The first is that a token, once issued, cannot currently be withdrawn. The design anticipates a list of revoked tokens held at the release server; it is not built. A token in circulation is good until its channel date passes.

The second is that the customer-side independent check of our own public key is not reachable where it should be. The release server publishes that key at a known address so that a customer's own tooling can verify a seal without asking us anything. The service serves it correctly, but a routing gap in front of the public site means a request to that address does not currently reach the handler. Until that is fixed, independent key retrieval over the public site should be treated as unavailable.

The third is the most important one for a reader assessing the commercial claim. Every product listed today is priced at zero for a beta period and requires no licence or payment at all. The ordering path, the payment watch, the token issuance, and the download gate are working code, and that code is what a paid order will use. It is not code that has yet carried a volume of real paid orders. This paper argues for a pricing model whose live test has not been run.

5. The price, paid once

What "full charge up front" means here

Our intention is a direct sale of software rather than a rental of access: the full price charged once, at the time of purchase, for a specific version — you own it — with standard customer support offered while your version is the current stable one, and consulting or extended support available separately for those who want it. There is no subscription, no minimum term, and no annual renewal required for the software to run.

Two design decisions follow from that intention and are already visible in what runs today.

The first is that a purchase does not create an account. There is no registration step, no password, and no customer portal to log into. Payment is made directly, and the transaction itself — publicly recorded and checkable by anyone holding its reference — is the receipt. The storefront issues a licence token against that payment, and that token is what the buyer holds. Nothing about this arrangement requires the buyer to maintain a standing relationship with our billing system, because there is no standing relationship to maintain.

The second is that what is sold is sold once, by construction. There are two tiers and no enterprise tier above them. The free tier — one archive and one console — generates no revenue for us at all and is not expected to; its purpose is adoption, and a companion paper on this site argues where the free-to-paid line sits and why it is drawn by architecture rather than by a feature list.

Why the release cycle is long

A subscription is not only a payment arrangement. It is also a delivery arrangement: the seller ships changes continuously, and the customer absorbs them continuously, because the customer has no version of their own to stand on.

A company that sells a version has to decide how long that version stands. Our intention is a stable cycle of three to four years — long enough that a business can install a version, train its people on it, build its procedures around it, and not be interrupted; short enough that the version a customer bought does not become an antique. Longer cycles exist in this industry; one long-established operating-system vendor supports a release for closer to a decade, and there are real benefits to a customer in that. We have not chosen the longer figure, for a reason given plainly in the next section.

What a stable cycle means for a buyer is that the software is a fixed thing they can plan around. Regulatory procedures written against version three still describe version three next year. Staff training does not expire. An auditor examining how a process worked in a given period is examining one system, not a moving average of eleven monthly changes.

6. The honest economic trade-off

This is the section a reader should weigh most carefully, because it is where the model costs us something and we would rather say so than be found out.

A subscription business generates revenue from a customer every month for as long as the customer stays, without having to build anything new to earn the next payment. A business that sells versions generates revenue from a customer at purchase, and then generates nothing further from that customer until a new version exists that the customer wants. The length of the stable cycle is therefore the length of the gap.

At three to four years, the gap is real but bearable. At seven or eight years — the longer cycle that would serve customers better — the gap approaches a decade, and revenue from the existing customer base effectively stops for that period. A company choosing the longer cycle is choosing to be funded almost entirely by new customers for most of a decade. That is a serious thing to choose, and we have not chosen it, and the honest description of our position is that customer benefit and company solvency point in different directions here and we have split the difference.

Two further costs belong in the same paragraph. Optional support is genuinely optional, which means it cannot be modelled as reliable recurring revenue the way a compulsory support contract can; we have deliberately declined the arrangement where support is priced as the real product and the software is nominally free, because that arrangement reintroduces the ongoing dependency the whole design exists to remove. And hosted services, the other standard answer, carry real infrastructure costs against thin margins and would make us the operator of the customer's records, which is the position this platform is built to avoid.

What follows from all of that is a constraint on scale rather than a hidden problem. This pricing model is intended to work at a moderate installed base — a business serving a defined segment well — rather than one that assumes continuous mass growth to cover the revenue gaps between releases. Whether it remains durable at a meaningfully larger scale is a genuinely open question, and it is the first one in the invitation below.

7. What this changes for the buyer

The first change is what a purchase decision looks like. A subscription cannot be evaluated as a purchase, because it has no total. It is evaluated as a commitment with an unknown termination date and a price the other party may revise. A one-time purchase has a number. A buyer can compare it against the cost of doing the same work by other means, decide, and be finished deciding.

The second change is what happens when the relationship ends. Under a subscription, ending the relationship ends the use of the software, which means the decision to leave is entangled with the question of how much the business depends on it. Under this model those are separate questions. A buyer who decides we are no longer worth paying keeps what they already paid for. That is a weaker commercial position for us, deliberately.

The third change is what happens if we fail. A company that sells versions and holds no switch leaves a customer holding something that still works after the company is gone. The customer loses future releases and loses support. They do not lose the use of what they bought. This is the property that a "perpetual licence" is supposed to provide and frequently does not, because the perpetual licence is checked against a server that is not perpetual.

The trade-offs are real and belong in the same paragraph. A one-time purchase means a larger number at the front, which is harder for a small buyer than a monthly figure. A long stable cycle means a buyer waits longer for an improvement they want, and improvements that land mid-cycle land in a version they did not buy. Support being optional means a buyer who declines it and then needs it is buying it at the moment of need rather than holding it in advance. And the most honest caveat of all: a licence check we have not built is easier to add later than a licence check we had built would be to remove. What protects a buyer here is not our word — it is that the code is published, so the day we add one, anybody can see it.

8. An open invitation

This paper states a position we hold and a set of questions we cannot answer from where we stand.

To researchers in software business models and industrial organisation: the honest claim in Section 6 is falsifiable and we would rather see it tested than asserted. Whether a subscription-free, long-stable-cycle model is durable above some installed-base threshold, or whether it only works below one, is an empirical question with a real answer. We have a prediction and no evidence. The interesting version of the study is not whether such firms exist — several do — but what distinguishes the ones that survived the revenue gap between releases from the ones that converted to subscriptions during it.

To practitioners in open-source and open-core commercial strategy: the published body of work on where to draw a commercial line is largely written for firms whose product is a hosted service, and treats the licensing decision and the distribution decision as one problem [open-core-handbook]. Ours separates them, because the customer runs the software. We do not know whether the separation survives contact with a real sales motion, and we would value the judgement of people who have run one.

To lawyers working on software licensing: the gap between what a licence document permits and what a licence key permits is, as far as we can tell, under-examined. Our arrangement deliberately makes the key weaker than the document — the key gates delivery only. We do not know what that does to the enforceability of the document, or whether a court would read the absence of a technical control as evidence about the parties' intent. We would rather be told than discover it.

And to anyone who has managed a long-cycle software estate inside a regulated business: the argument in Section 5 that a stable version makes an auditor's task simpler is our reasoning, not our experience. Whether it holds when a security fix has to be shipped mid-cycle, and what a regulated customer actually does in that case, is something we would rather learn from people who have lived it.

9. Conclusion

Software should be sold once, in full, for a version that keeps working afterward. That is a commercial position, not a technical one, and it is falsifiable in the way commercial positions are: it costs the seller the recurring revenue a subscription would produce, and it survives only if the seller can be funded across the gaps between releases. We have taken the cost deliberately, chosen a three-to-four-year stable cycle as the compromise between what serves a customer and what keeps a company solvent, and declined the two standard alternatives — compulsory support and hosted services — because each rebuilds the ongoing dependency the model exists to remove. What makes the position more than a preference is where the off switch is and is not. A licence is checked when a release is handed over, and inside the paid layer that withdraws its own paid service when its licence lapses — and nowhere else. The free software holding a customer's records does not know licensing exists, and every line of that is published. A buyer does not have to trust that we will leave their records alone when they stop paying. They can check that there is no mechanism by which we could do otherwise.

References

Farrell, J., and Klemperer, P. 2007. Coordination and lock-in: Competition with switching costs and network effects. Handbook of Industrial Organization, vol. 3. Elsevier.

Shapiro, C., and Varian, H. R. 1998. Information Rules: A Strategic Guide to the Network Economy. Harvard Business School Press.

Williamson, O. E. 1979. Transaction-cost economics: The governance of contractual relations. Journal of Law and Economics 22(2): 233–261.

Bernstein, D. J., Duif, N., Lange, T., Schwabe, P., and Yang, B.-Y. 2012. High-speed high-security signatures. Journal of Cryptographic Engineering 2(2): 77–89.

Open Core Ventures. Handbook — Licensing and Distribution. https://handbook.opencoreventures.com/commercial-mvp/licensing-and-distribution/

Linux Foundation. SPDX License List — standardised licence identifier registry. https://spdx.org/licenses/

Contributors

Prepared by Woodfine Management Corp.

How this paper was produced

This paper is grounded in the operating and development work the preparing staff do themselves, and in what they have learned from the people they work with routinely: the graphic designers, web developers, and software developers and engineers who build the platform alongside them, and the architects and structural, building-services, and civil engineers they develop buildings with. No outside professional reviewed or approved this paper, and nothing in it is professional advice. It was drafted and edited with AI assistance under editorial direction, and the analysis and conclusions are Woodfine's own.

Disclosures

Woodfine Capital Projects Inc. ("Woodfine") is the author of record. PointSav Digital Systems, which builds the platform described, is currently a trade name of Woodfine, planned to become a wholly-owned Woodfine subsidiary upon incorporation; PointSav does not itself offer, sell, or solicit any security. The pricing and distribution arrangement described in this paper is our own commercial model, so this paper argues for an approach we have a direct commercial interest in. This work was funded internally; no external research funding was received. The description of what a licence document does and does not permit is given to explain a design and is not legal advice on any party's rights or obligations. This paper's content is provided for engineering, operational, and research purposes and does not constitute investment advice or a solicitation to invest in any Woodfine direct-hold solution. Some statements above describe planned or intended future work; language such as "planned," "intended," "targeted," "may," and "expected" marks this forward-looking content, which is subject to change and does not constitute a commitment regarding future performance.

Data and reproducibility

The claims in Section 4 about where a licence is and is not checked were established by reading the platform's own published source directly in preparing this paper, rather than from a summary. Licence-verification code appears in two places: the release server, where it gates the download path, and the paid aggregation layer, where it gates that layer's own paid service offline against a built-in public key, with a thirty-day grace period past expiry. A search of the archive operating system, the console, and the workplace system for any licence, token, or entitlement check returned nothing. The field in a sealed token that carries a date governs the release channel — the right to be handed further releases — not the running of software already installed. The provision allowing a product to be served with no licence check at all is a setting in each product's own description file, read by the same server. All of this is open code, published in full, and a reader with access to it can confirm each of these points at the place it is defined. The zero-price beta status of every currently listed product is stated in the platform's own published operating documentation. The figures for the intended stable-release cycle are our stated intention, not a measured result: no release cycle of that length has yet completed, because the platform has not existed for that long. Licence identifiers referred to in this paper follow the standard public registry of such identifiers maintained by the Linux Foundation [spdx-license-list]. No independent party has audited this software, reviewed these claims, or verified the absence of enforcement code described above.

PointSav Digital Systems™ and Woodfine Capital Projects™ are trademarks of Woodfine Capital Projects Inc.