Ownership You Can Prove Without the Seller

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-014 · v0.1.0 · CC BY 4.0

Our thesis is that a buyer should be able to prove they own what they bought without the seller's cooperation, and that this is an ordinary engineering requirement rather than an unusual one. Almost every commercial software licence in existence fails it. A licence sold as perpetual — yours for ever, no renewal — is in practice only as durable as the seller's own computer remembering that you bought it. If that computer is switched off, if the records are lost in a migration, if the company is sold and the new owner runs the licence system differently, or if the company simply closes, the buyer holds a piece of software that can no longer establish that it is licensed. The word perpetual described the terms. It did not describe the mechanism.

There are two things a buyer might need to prove, and they are usually conflated. The first is that the licence itself is genuine — that the seller really issued it, and that its contents have not been altered since. The second is that it was paid for. Our position is that both can be made checkable by an independent third party using only public information, and that where this is done, the buyer's proof outlives the seller's infrastructure and the seller's business.

This paper takes three things in turn: what a signature that anyone can check actually is, built up from the beginning for a reader with no background in the subject; what a public settlement record is and why a payment recorded in one is a different kind of evidence from a receipt in a company's files; and how the two fit together in the arrangement running today, including three places where that arrangement is presently incomplete. On the connected question of what an expiring licence actually ends, this paper states the answer directly rather than leaving a reader to infer it: it ends the right to be handed further releases, and it ends the paid layer's own paid service, and it does not touch the free software a customer's records live in.

1. The thesis

A claim can be established in two ways. It can be attested — some authority states it, and you rely on the authority. Or it can be verified — you check it yourself, against evidence, using a method that does not require the authority's continued cooperation or continued honesty.

Commercial software licensing is almost entirely attestation. The authority is the seller, the evidence is an entry in the seller's database, and the verification method is asking the seller. The arrangement works well while the seller exists, is reachable, is competent, and is not adverse to you. Those four conditions hold most of the time, which is why the arrangement persists. They do not hold all of the time, and they are least likely to hold at exactly the moment a buyer most needs the proof: when the seller has failed, or been acquired, or fallen out with the customer.

We hold that a licence should be verified rather than attested, and that this requires two specific substitutions. In place of "the seller's database says you bought it," the proof becomes a sealed statement the buyer holds, checkable against a published key. In place of "our accounts show the payment cleared," the proof becomes a transfer recorded in a public register, identifiable by its own reference and confirmable by any independent observer.

The composition is the claim, and none of the parts is ours. Sealing a statement so that anyone can confirm who wrote it, and that nobody has altered it since, is decades-old cryptography. Recording transfers of value in a register anyone can read, rather than in a ledger only the institution holds, is older still in the paper world — a land registry works exactly this way — and has a well-known modern form in software. The idea of a credential a holder carries and a third party can check without contacting the issuer is a standardised web construction [w3c-verifiable-credentials]. What we are doing is putting them together for something mundane: proving that a small business owns a copy of a piece of software.

2. The problem, in the reader's terms

A reader over a certain age has had this experience in the physical world and remembers how it was solved.

You wrote a cheque. The cheque had your signature. The bank held a signature card — a slip of paper, filed at the branch, bearing a specimen of your hand. When the cheque arrived, a clerk compared the two. The arrangement was a lookup: the truth about your signature lived in the branch's drawer, and everything depended on that drawer being present, correct, and honest. If the card was lost, you could not draw on your own account until it was replaced. If the branch closed, the card closed with it.

Now consider how a deed to a property works instead. When you buy a house, you do not receive a slip of paper whose validity depends on the seller's filing cabinet. The transfer is recorded in a public register that anyone may search, indexed so that a particular entry can be pointed to, and kept by an institution whose whole function is to remain searchable long after any individual party to any individual transaction is gone. A purchaser's solicitor traces the chain backwards through that register. They do not telephone the previous owner and ask whether the sale really happened.

The difference between those two arrangements is the difference this paper is about. The signature card is attestation: the proof lives with an intermediary and depends on them. The land register is verification: the proof lives in public and can be examined by anyone with the reference.

Software licensing has, almost without exception, chosen the signature card. Consider what that has meant in practice for buyers over the past twenty years. Software bought outright has stopped working because an activation server was retired. Products have become unusable after an acquisition because the new owner did not carry over the old licensing system. Perpetual licences have been rendered unverifiable — not revoked, merely unverifiable — because the only party who could confirm them no longer answered. In each case the buyer's legal position was untouched. Their practical position was that the software did not run and there was nobody to call.

The failure in all of these is structural, not moral. Nobody set out to strand a customer. The proof was simply kept in a place that did not have to outlive anything.

3. What a signature anyone can check actually is

This section builds the idea from the beginning. A reader who already knows what a public key is may go straight to Section 4.

Two keys instead of one

Ordinary locks use one key, and anyone who has it can both lock and unlock. Ordinary secrets work the same way: a password that lets you prove who you are also lets anyone else who learns it prove they are you. The whole difficulty of password security follows from that single fact.

Cryptography of the kind used here works differently. A key comes in two mathematically related halves, made together, and what one half does the other undoes. One half — the private key — is kept by its owner and never shown to anyone. The other half — the public key — is published as widely as possible; there is no harm in anyone having it.

The useful consequence is this. The holder of the private half can perform an operation on a piece of text that produces a short block of data called a signature. Anyone holding the public half can then check the signature and learn two things at once: that it was made by the holder of the private half, and that the text has not been altered by so much as a comma since. What they cannot do, no matter how many signatures they examine, is work out the private half or produce a new signature themselves.

The closest traditional object is a seal rather than a signature. A wax seal impressed with a signet ring produces a mark everyone can recognise, while the ring itself never leaves the owner's hand. Publishing the pattern of the seal makes forgery no easier; only possession of the ring does. The mathematical version has one property the wax one lacks: the seal is computed from the text, so it seals that exact text and no other. Change a word and the seal no longer matches.

The scheme used here, and why the choice matters

The particular scheme this platform uses is a published, widely adopted one designed in the early 2010s. Its authors set out to be fast, to produce small signatures, and — the reason it matters most here — to remove a class of implementation mistake that had caused real failures in the previous generation of signature schemes, where a subtle error in how randomness was generated could leak the private key to anyone who collected enough signatures [bernstein-2012-ed25519]. We chose an established scheme rather than designing one. In this field, novelty is a liability.

What a licence looks like once it is a sealed statement

A licence here is not a serial number and not a database row. It is a short statement — which product, until when the release channel runs, what the licence entitles the holder to, the earliest version it covers, and an opaque reference to the purchasing party — with the seal placed in front of it. The whole thing is encoded as a single block of text the buyer holds.

Two things follow directly. The first is that the statement is self-contained: everything needed to evaluate the licence is inside it, so checking it requires no lookup anywhere. The second is that it cannot be edited. A buyer cannot extend their own expiry date, and neither can anybody else, because any change breaks the seal.

The check itself is arithmetic. In the running system, the component that hands out software releases takes the block of text, separates the seal from the statement, verifies the seal against the public key it holds, and then reads the statement to see whether it covers the thing being requested. It contacts nothing. It queries no database. It does not ask the part of the system that issued the licence whether the licence is still good, because it has no need to and no way to. We read this routine directly in preparing this paper rather than relying on a description of it.

One consequence of that design is worth drawing out because it is not obvious. The half of the key pair that can create licences is held only by the storefront. The component that checks them holds only the public half. If the checking component were broken into entirely, the intruder would gain the ability to hand out files — which is bad — but not the ability to manufacture a single valid licence, because the means of doing so is not there to steal.

Signing the software itself, separately

There is a second, independent use of the same machinery, and it is deliberately available to everyone. Each released file is published alongside a detached seal of its own — a small separate file that seals the contents of that exact binary. That seal is served to anybody who asks for it, with no licence required and no payment, because a seal on a public file is public by design. Its purpose is to let any party confirm that the file they hold is the file we published and has not been tampered with in transit or on a mirror. A buyer, a security researcher, or a customer's own IT contractor can perform that check without holding a licence and without our permission.

4. What a payment recorded in public is

The register, not the receipt

Now the second half of the proof. Suppose a buyer can demonstrate that their licence is genuine. How do they demonstrate it was paid for?

In the ordinary arrangement, the answer is a receipt: a document the seller produced, saying the seller received money. It is evidence, but it is evidence of exactly one thing — that the seller says so. A forged receipt and a genuine one look the same to a third party. The only way to check is to ask the seller, which returns us to attestation.

The alternative is a payment made over a public settlement network — a register of transfers that is maintained collectively rather than by one institution, and that anybody may read in full. Every transfer in it has a reference of its own. Given that reference, any independent observer can look up the transfer, see the amount, see the parties' addresses, see the date, and confirm that it happened. The seller is not involved in that confirmation and cannot prevent it.

The public land register is the right traditional comparison, and it is a closer one than it first appears. Both are public. Both are indexed so that a single entry can be cited. Both are maintained by an arrangement designed to outlive the parties to any individual entry. And in both, the public record is the record — not a copy of a private one, but the authoritative thing itself. The mechanism by which a collectively maintained register of this kind can be kept consistent without a single institution in charge was set out in a well-known 2008 paper [nakamoto-2008-bitcoin], building on much earlier work on how to fix a document's existence at a point in time so the fixing cannot later be backdated [haber-stornetta-1991-timestamping-digital-documents].

What we actually do with it

The platform's payment side is a read-only observer of such a network. It does not run anything on that network, does not hold a contract there, and does not ask anyone's permission to watch. It simply reads the public record, looking for transfers addressed to our own address, and when it sees one confirmed it writes a local receipt noting the transfer reference, the sender, the block it appeared in, when it confirmed, and which product the amount corresponds to.

The currency used is a unit pegged to the US dollar rather than a floating one, for a straightforward practical reason: a fixed software price is meaningless if the amount required changes between the buyer deciding and the buyer paying. The settlement network chosen is one with transaction costs low enough that a purchase in the single-digit dollar range is not dominated by the cost of making it.

A buyer who prefers a dedicated receiving address for their own accounting can have one, derived for their order alone from a master value we hold, along a standard derivation path. That is an option rather than the default, and payments to derived addresses are observed by the same watcher.

The sequence, and what is absent from it

The whole purchase runs as follows. The buyer sends the payment. The watcher observes the public record and writes the receipt. The buyer presents their transfer reference to the storefront, which finds the receipt and issues the sealed licence. The buyer presents the licence to the release component, which checks the seal and sends the file.

Three things are absent from that sequence, and their absence is the design.

There is no account. No registration, no password, and no profile to sign into later. The transfer reference is the order number, and asking the same question twice returns the same licence rather than creating a second one.

There is no intermediary holding funds. The payment goes directly, and the settlement is between the two parties on a public register.

And there is no moment at which the buyer's ability to prove what they hold depends on a system we operate. The seal is checkable against a public key. The payment is checkable against a public register. Both remain checkable if every machine we run is switched off, which is the entire point.

What this does not yet do

Four limits belong here rather than at the end, because a reader assessing the claim needs them in the same breath as the claim.

A licence once issued cannot be withdrawn. The design anticipates the checking component holding a list of licences no longer honoured; that list is not built. Until it is, a licence in circulation is good until its own channel date passes, whatever happens in between. For a one-time purchase of a perpetual right this is mostly the correct behaviour, but it is not a deliberate policy so much as a phase we have not reached, and we would rather say which it is.

We publish our own verification key at a known address so that a buyer's own tooling can check a seal without asking us anything — which is the mechanism that makes the independence claim real rather than rhetorical. The underlying service serves it correctly. A routing fault in front of the public site means a request to that address does not presently reach the handler. Until that is repaired, independent key retrieval over the public site should be treated as unavailable, which weakens the practical form of this paper's own central claim today even though the design and the code behind it are sound.

Recording the buyer's ownership of a specific file as an entry on the public network itself — so that the ownership, and not only the payment, is a public fact — is planned and not built. The association between a file and a purchaser is being written down now so that the data exists when the capability is added.

And every product currently listed is priced at zero for a beta period and requires no licence at all to download. The ordering, watching, sealing, and checking described above are working code, and that code is what a paid order will use. It has not yet been exercised by paid orders at volume.

5. What an expiring licence actually ends

This deserves its own short section, because it is the question a buyer asks immediately and because the honest answer is easy to state and easy to check.

The sealed statement carries a date. What that date governs is the release channel — the right to be handed further releases of the product. It does not govern the running of software already installed.

The reason is not restraint on our part; it is where the checks live. There are two places in this system where a licence is examined, and both sit on the paid side of the commercial boundary. The first is the component that hands out release files, at the moment a file is requested. The second is the paid aggregation layer — the commercial component that asks one question of many archives at once — which checks its own licence when it starts, entirely offline against a public key built into itself, and withdraws its own paid service if that licence has lapsed past a grace period of thirty days. That is a paid component enforcing the thing that was paid for.

What matters here is the third place, where no check exists. In preparing this paper we looked in the free software a customer actually runs to hold and work with their records — the operating system inside an archive, the console, the workplace system — for any licence check at all. There is none. Nothing in them reads a licence, consults an entitlement, or compares a date against a clock. A copy already installed does not stop when a licence expires, because nothing in it is looking, and an archive and its records stay reachable whatever happens to any licence.

There is a corresponding statement about our own infrastructure. If the storefront is unavailable, no new orders can be placed and every licence already issued continues to work. If the release component is unavailable, downloads stop and licences remain valid. Neither outage reaches software already on a customer's machine, because that software has no relationship with either of them — and the paid layer's own check, being offline, does not reach out to us either.

A companion paper on this site argues the commercial position that follows — that software should be sold once, in full, for a version that keeps working. The mechanism described here is what makes that position something other than a promise.

6. What this changes for the buyer

The first change is who has to still exist. Under the ordinary arrangement, a buyer's proof of a perpetual licence depends on the seller continuing to operate a particular service. Here it depends on arithmetic and on a public register, neither of which is ours. A buyer holding their sealed licence, the transfer reference, and our published verification key can establish both halves of their position with no reference to us.

The second change is what a third party can be shown. A buyer's accountant, auditor, lender, or acquirer frequently needs to establish what software assets a business holds and what it paid for them. Today that examination consists of asking the business for invoices and, where it matters, asking the vendor to confirm. Under this arrangement the examiner can be handed a sealed licence and a transfer reference and check both themselves, at their own desk, with neither party's cooperation.

The third change is what happens in an acquisition or a winding-up. When a software company is bought, its customers' licences become a matter of what the acquirer chooses to honour and what records survived the transition. A licence that verifies against a published key does not require the acquirer to have inherited anything, and a payment recorded in public does not require the acquirer to have inherited the ledger.

The trade-offs are real and belong in the same paragraph. A buyer holds the licence, which means a buyer can lose the licence; there is no "forgot my password" path, because there is no account to recover. Settling in a unit priced on a public network is unfamiliar and, for a small business without anyone comfortable with it, a real barrier — it is the part of this design most likely to be a practical obstacle rather than a benefit. A public payment record is public: the amount and the addresses involved are visible to anyone with the reference, which is precisely what makes the verification work and is also a disclosure a buyer should make knowingly. And the independence claim is currently stronger in design than in practice, because the route by which a buyer would fetch our verification key is broken on the public site today.

7. An open invitation

This paper states a position we hold and several questions we cannot settle from where we sit.

To researchers and practitioners in licensing infrastructure: the case handled here is the simplest one — a single product, owned outright by one buyer, with a release channel that expires. We do not know whether the model extends cleanly to the arrangements real businesses actually buy: per-seat licences where the seat count changes, usage-based licences where the count must be established after the fact, or site licences held by an entity whose membership changes. Each of those seems to reintroduce a party who must be consulted, which is the thing this design removes. Whether that is a fundamental limit or an unsolved design problem is a question we would rather work with people who have built such systems than answer alone.

To specialists in verifiable credentials and standardised proof formats: the sealed statement described in Section 3 is a bespoke construction, and there is a mature standardised family of constructions for holder-carried credentials checkable by a third party without contacting the issuer [w3c-verifiable-credentials]. We chose the simple bespoke form because it was small and we understood it completely. We suspect that was the right trade for a first system and the wrong one for a durable standard, and we would value being told which by people who work on the standardised forms.

To auditors and assurance professionals: a seal verified against a published key is mathematically conclusive, and it is not, so far as we are aware, a recognised form of evidence in any assurance standard. What documentation, procedure, or independent attestation an examiner would need before relying on such a check in place of a vendor confirmation letter is a question for that profession rather than for us, and the answer determines how much of Section 6's second claim is actually available today.

To insolvency practitioners and lawyers who handle the wind-up of technology companies: the argument in Section 6 that these proofs survive a seller's failure is our reasoning about a situation we have not been in. What a liquidator, an acquirer, or a court actually does with a customer's cryptographic proof of purchase — whether it is treated as conclusive, as evidence, or as a curiosity — is something we would rather learn from people who have administered such estates.

And to anyone who has deployed public-network settlement for small business customers: our honest assessment is that this is the weakest practical link in the design. We would rather hear where it has failed for ordinary buyers than discover it ourselves one customer at a time.

8. Conclusion

A buyer's proof that they own what they bought should not require the seller's continued existence, competence, or goodwill. Both halves of that proof can be made independent. That the licence is genuine is established by a seal anyone can check against a published key, with the means of creating such seals held in one place and the means of checking them held everywhere. That it was paid for is established by a transfer recorded on a public settlement network, citable by its own reference and confirmable by any observer. No account is created, no intermediary holds the money, and nothing about the arrangement requires us to answer a question for the buyer's position to hold. What an expiry ends is the stream of future releases, not the software already installed — a fact about where the check is, not a promise about how we will behave. The arrangement is built and running, with a list of withdrawn licences not yet implemented, the public route to our own verification key presently broken, and every product still priced at zero while the model is tested. We hold that a proof you can check yourself is worth more than a promise from a party who may not be there, and we intend to close the three gaps above rather than argue around them.

References

Haber, S., and Stornetta, W. S. 1991. How to time-stamp a digital document. Journal of Cryptology 3(2): 99–111.

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.

Nakamoto, S. 2008. Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf

World Wide Web Consortium. Verifiable Credentials Data Model 2.0. https://www.w3.org/TR/vc-data-model-2.0/

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 licensing and payment architecture described is our own design and 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. Sections 3 and 4 describe cryptographic and settlement mechanisms in general terms in order to explain a design; nothing in this paper is legal, tax, accounting, or financial advice, and nothing in it is a recommendation to acquire, hold, or transact in any currency, digital asset, or settlement network. 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 mechanism described in this paper was confirmed by reading the platform's own published source directly in preparing it, rather than from a summary. The routine that checks a licence separates the seal from the sealed statement, verifies it strictly against a stored public key, and then compares the product, the release-channel date, and what the licence entitles the holder to — touching no network and no database at any point. The provision by which a product may be served with no licence check at all is a setting in that product's own description file, read by the same component. A search of the archive operating system, the console, and the workplace system for any licence, token, or entitlement check returned nothing, which is the basis for Section 5; the same search found licence-verification code in the paid aggregation layer, where it is documented at its own definition site as an offline check against a built-in public key with a thirty-day grace period, which is reported in Section 5 rather than omitted. The payment side reads a public settlement network and holds no position on it; any independent observer of that network can confirm a transfer from its reference without our involvement, which is the property the argument rests on. The three incomplete items named in Section 4 — no withdrawal list, the broken public route to our verification key, and the not-yet-built public record of ownership — are each stated in the platform's own published operating documentation, and the second of them is described there as a known fault rather than a design choice. The zero-price beta status of every currently listed product is likewise stated there. The code is open source and published in full, so a reader with access to it can confirm each of these at the place it is defined. No independent party has audited this software, reviewed its cryptographic implementation, or verified these claims.

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