Eight days ago we published a thirty-minute background check on software suppliers, built entirely out of free UK public registers. It works well, and it works on exactly one kind of supplier: a company incorporated somewhere you can read the filings.
That leaves out most of the world's software buyers, and most of the world's software.
If you are a hotel group in Dubai hiring a studio in Kraków, a clinic in Toronto hiring four contractors in Manila, or a manufacturer in Ahmedabad hiring a two-person team you found on a call, there is no equivalent register, or there is one and it tells you nothing useful, or it is in a language and a format nobody will read on a Tuesday afternoon. The advice that survives the jurisdiction change is not "look them up". It is narrower, harder, and considerably more useful.
Here is the version that works anywhere. It rests on one legal fact that surprises almost every buyer, one clause that fixes it, and one drill you can run at 25% of the build for the price of an hour.
Part one: the default nobody tells you
Ask a room of business owners who owns the software they commissioned and paid for in full, and essentially everyone says: we do. We paid.
In most of the world, the law says otherwise unless somebody wrote it down.
United Kingdom. The Copyright, Designs and Patents Act 1988 is blunt about it: "The author of a work is the first owner of any copyright in it." The exception is employment — "Where a literary, dramatic, musical or artistic work, or a film, is made by an employee in the course of his employment, his employer is the first owner of any copyright in the work subject to any agreement to the contrary." An outside development agency is not your employee. Software is a literary work. The author owns it.
United States. Buyers reach for "work made for hire", and for a commissioned supplier it usually does not apply. The Copyright Office's own guidance sets out the two routes: work by an employee within the scope of employment, or a work "specially ordered or commissioned for use" in one of nine listed categories — "as a contribution to a collective work, as a part of a motion picture or other audiovisual work, as a translation, as a supplementary work, as a compilation, as an instructional text, as a test, as answer material for a test, or as an atlas" — and only with an express written agreement.
Read that list again. Software is not on it. A commissioned application generally cannot be a work made for hire in the United States no matter what the contract calls it, which means ownership has to arrive by assignment instead — and "a transfer of copyright ownership, other than by operation of law, is not valid unless an instrument of conveyance, or a note or memorandum of the transfer, is in writing and signed by the owner of the rights conveyed."
India — relevant to a very large share of the world's outsourced development, including ours. Section 17 of the Copyright Act 1957 says "the author of a work shall be the first owner of the copyright therein", then carves out two exceptions. Clause (b) covers work done for valuable consideration in photographs, paintings, engravings and films — not software. Clause (c) covers work made under a contract of service, that is, employment. A studio you engaged is under a contract for services, not of service. The default lands back on the author.
And the assignment formality is the same shape everywhere: "No assignment of the copyright in any work shall be valid unless it is in writing signed by the assignor or by his duly authorised agent", and it "shall identify such work, and shall specify the rights assigned and the duration and territorial extent of such assignment." The UK equivalent: "An assignment of copyright is not effective unless it is in writing signed by or on behalf of the assignor."
Three jurisdictions, three legal traditions, one practical conclusion. Paying the invoice transfers no copyright. A signed written assignment does. If your contract does not contain one, the working assumption should be that your supplier owns the code you paid for and you hold, at best, an implied licence to use it — the scope of which you will discover in the worst possible week.
This is not a reason to distrust anybody. Most suppliers who omit the clause are not scheming; they copied a template. It is a reason to read six lines before you sign.
Part two: what the clause actually has to say
"All IP shall vest in the Client" is the sentence most contracts contain and it is not enough, because it answers one question out of five. A workable assignment clause covers all five, and every competent supplier can produce one.
What it must settle | Why the one-liner fails |
|---|---|
Which work | Statutes require the assignment to identify the work. "All deliverables under this agreement, including source code, build scripts, configuration, schema, and documentation" — the last three are what people forget, and a schema you can't take with you is as blocking as code you can't take with you |
Which rights, where, for how long | Assignment provisions expressly require rights, duration and territory to be specified. "All rights, worldwide, for the full term of copyright" is the sentence |
When it takes effect | Present assignment on creation, or on payment of the relevant invoice. Not "on completion of the project" — projects stop without completing, and that is precisely when you need the clause |
Pre-existing and third-party material | No studio builds from nothing. They reuse their own libraries and they install open-source packages. Those cannot be assigned to you. What you need instead is a perpetual, irrevocable, worldwide, royalty-free licence to use, modify and sublicense them as part of the deliverable — and a list of what they are |
Moral rights, and who signs | In jurisdictions that recognise them, moral rights are not assignable and must be waived separately. And the signature has to come from whoever actually holds the rights: if the code was written by subcontractors, the agency can only assign what it first obtained from them in writing |
That last row is the one that quietly fails. An agency that assigns you everything, in good faith, while its four freelancers signed nothing, is assigning rights it never acquired. The question is one sentence long and the answer is instant: does everyone who writes code on this project have a written IP assignment to you or to the company contracting with me? A supplier with a standard subcontractor agreement says yes and attaches it. A supplier without one goes quiet, which is also an answer.
Two more worth adding to the same email, because they cost nothing to ask and are expensive to discover later:
The open-source inventory. Ask for the dependency licence list — a generated file, not a document anyone has to write. What you are looking for is whether any copyleft licence sits in a place that would affect how you can distribute or sell your own product. Usually there is nothing. Occasionally there is, and it is far cheaper to know in week two than in year two.
Where the code was generated. AI assistants are now in nearly every development workflow, including ours. This is not a reason for alarm and we are not going to pretend the law here is fully settled. It is a reason to ask a practical question: which tools are used, under which account tier, and does that tier's agreement permit commercial use and keep your code out of training. Any supplier with a policy will tell you in two lines. A supplier who has never considered it has told you something about how they handle everything else.
Part three: the hand-back drill
Contracts tell you what someone owes you. They do not tell you whether you can actually get it. That gap is where most "we own everything" relationships fail — not in court, but on a Friday when the person with the deployment credentials stops replying.
So run the drill. It is the single most useful thing in this post and almost nobody does it.
At roughly 25% of the build — before the money and the momentum make it awkward — tell your supplier you want to do a hand-back rehearsal. Not an exit. A rehearsal. Any good supplier will agree immediately, because it is the cheapest possible demonstration of competence.
You are testing four artefacts.
1. The repository. Not a zip file emailed to you. Access to the actual version-controlled repository, with full history, owned by an account in your organisation's name, with your supplier holding access rather than ownership. The history matters: it is the difference between inheriting a codebase and inheriting a mystery.
2. A second running environment. Someone who is not the original author follows the setup documentation on a clean machine and gets the thing running. This is the whole test compressed into one step. If it takes three days and two phone calls at 25% complete, it will take three weeks after the relationship ends.
3. The credentials and accounts inventory. Every service the system depends on — hosting, domain, database, payment processor, email, storage, monitoring, any third-party API — with a note on whose name the account is in and who pays for it. The correct answer for almost all of them is yours, with the supplier granted access. The common answer is that four of them are on someone's personal account, which nobody notices until that person is gone.
4. The data export. Your data, out of the system, in a format you can read, produced by a documented process rather than by a developer who knows the right query. This is the one that decides whether you can ever move, and it is the exit question we apply to every supplier we write about.
Score it honestly: how long did it take, how many times did the supplier have to intervene, and what was missing. Then keep the result. Re-run the drill at handover and compare.
A supplier who passes this at 25% has proved more than any portfolio, reference or case study can. A supplier who resists it has answered your question without meaning to.
Part four: the three questions that replace the registers
When you cannot read a filing history, these are the substitutes. None requires a lawyer to ask.
Which legal entity am I contracting with, and where is it? Not the brand — the entity on the invoice. Company name, registration number, country, registered address. If the brand is in one country, the entity in a second and the bank account in a third, that is not automatically wrong; international groups are structured exactly that way, and so are we. It is a thing to understand before you pay a deposit, not after. Where a company register does exist and is readable, use it — the thirty-minute UK version transfers in shape, if not in detail, to most of the OECD.
Which law governs the contract, and where does a dispute get resolved? This clause is usually the last one anybody reads and it is the one that decides whether a disagreement is a phone call or a fantasy. A governing-law clause naming a jurisdiction neither party can practically litigate in is, for a small contract, the same as having no remedy at all. It is worth knowing that on day one, because it should change how you stage the payments — which is the real protection on a cross-border build. Small milestones, each one delivering something you can actually run, is a better safeguard than any clause you will never enforce.
Whose data protection law follows my users? This one catches buyers out, because it does not follow the supplier — it follows the people in your database. The GDPR says so directly: it applies "to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to: (a) the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or (b) the monitoring of their behaviour as far as their behaviour takes place within the Union."
So a US company, using a development partner in Asia, serving customers in Europe, is inside that scope — and the same logic applies to a growing list of regimes elsewhere. The practical consequence is simple: you need a written processing agreement with whoever touches that data, wherever they sit, and you need to know which countries the data is stored in and who the sub-processors are. Ask for the sub-processor list. It is short, it is boring, and its absence is informative.
Part five: reading the answers honestly
Most vendor-vetting advice is written to frighten. The point of asking is calibration, not suspicion — you are finding out which conversation to have, not deciding who is guilty.
What you find | What it means | What it doesn't mean |
|---|---|---|
No IP assignment clause at all | They used a template. Fix it before the first invoice | Bad faith |
"All IP vests in the Client", nothing more | Incomplete, and standard. Ask for the five elements in part two | That they'll fight you |
Subcontractors with no written assignment | A real gap — they can't assign what they don't hold | That the work is worse |
Repo owned by the agency | Extremely common. Ask for transfer of ownership now, access for them | Lock-in by design |
Two accounts on a developer's personal login | Housekeeping, and universal | Negligence |
Hand-back drill takes a day, with fixes | A good result. Note what was missing | A failed test |
Hand-back drill declined | Stop. This is the only finding on this list that is a decision rather than a question | — |
No sub-processor list | They haven't been asked before | Automatic non-compliance |
Entity in a different country to the brand | Ordinary for international groups. Understand it before the deposit | Anything on its own |
The short version
Registers are a luxury of a particular jurisdiction. Three things travel everywhere.
Ownership is not automatic. In the UK the author is first owner; in the US commissioned software falls outside the nine work-made-for-hire categories; in India the exceptions cover photographs, films and employees, not contracted software. All three require assignment in writing, signed, identifying the work and specifying rights, duration and territory. Paying the invoice does not do it, and the clause has to cover subcontractors too.
Capability is testable before you're committed. The hand-back drill at 25% — repository with history, a second running environment built by someone else, a credentials inventory, a documented data export — tells you more about the next two years than any reference call.
The questions that replace the registers are three. Which entity, under which law, and whose data protection regime follows your users — which, under the GDPR's own territorial scope, follows the people in your database rather than the location of your supplier.
None of this is adversarial. Every item is a document or a rehearsal a competent partner already has, and the speed of the reply is most of the information.
Run this on us. We are Symentic Technologies Limited, a UK company, working with an engineering team in India, for clients across the UK, Europe and the US — which makes us precisely the cross-border arrangement this post is about. Ask us which entity invoices you, ask for the assignment clause and the sub-processor list, and book the hand-back drill into the plan at 25% before you sign anything. If you are holding a proposal from somebody else, send it over — we will read the IP and exit clauses with you whether or not we are one of the people who bid. See what we've built, or tell us what you're trying to do.
Related reading: Their portfolio is curated. Their filing history isn't. · Every supplier looks the same until you try to leave · Nobody can price your software from a blog post · Most AI vendor checklists ask you to verify things you can't