What You Own When the System Is Ready: Code, Data and Developer Dependence

The system has been handed over, the invoice is paid, and six months later the company decides to change developer, and that is the moment the question is asked that until then nobody thought urgent: who owns what was paid for. The answer is not on the invoice. Who owns commissioned software is the law of the contract’s governing country, and inside the EU and the EEA paying an agency does not by itself transfer copyright in the computer program — that default is national and it genuinely differs, and it is not a legal nicety but the default that operates whenever the contract has written nothing else.

This article is about what remains in your hands after handover, and that is not the same question we have already looked at in comparing an off-the-shelf product with custom software. There the subject was what to choose; here the subject is what you are holding when the choice has already been made and the system is running. The answer splits into three parts: the code and the rights in it, the data together with the place where it is stored, and dependence on the people who know the system.

The author is usually a person, not a company

In most European copyright acts the author is the natural person whose creative activity produced the work, so a company is usually not the author: the authors are the programmers, the designers and the people who wrote the copy. A few acts do treat a legal person as author in named cases, and that is a trap of its own. Computer programs are protected as literary works, as they are in Directive 2009/24/EC of the European Union, and copyright arises when the work is created, without registration, without a mark, and independently of whether the work is finished.

Copyright splits into two parts, which European acts typically name as moral rights and economic rights, and in practice that is the most important split in this whole subject, because only one of them can reach the company at all. The economic part is the one that can be assigned, and in the case of a computer program it lets the program be distributed, made available, rented, reproduced, and also translated, adapted or otherwise transformed, and the results of that transformation reproduced. The moral part stays with the author for life in the continental catalogue and is not assignable to anyone — UK moral rights are a narrower bundle — which is why a contract cannot simply write that the company becomes the author, except in those few acts that already let a legal person be one.

There is another boundary that is rarely noticed, and it can turn out expensive. The rule that delivers the economic rights to the employer often speaks only of the computer program, while everything else the project produces — design, documentation, copy and instructions — follows a different default, and that default is not the same in every country. In some acts those other works stay with the author and the employer gets only a purpose-limited use; in others the employer takes more, and common-law systems often treat the employer as first owner of all employee works, not only programs. In practical terms that means two things created in one project can have two different owners, and a contract that talks only about software can leave the design outside.

From that follow the first practical consequences, which are worth understanding before everything else: when a company commissions a system from an agency, the chain of rights is at least two steps long, because first the programmers are the authors, then the agency has or has not acquired the economic part from them, and only then can the agency assign anything to you. If a step is missing, the agency is promising more than it owns, and that is noticed only when someone starts to check.

Employee and commission are two different defaults

This is the core of the article, and this is the place where intuition goes the wrong way. Directive 2009/24/EC Article 2(3) provides that where a computer program is created by an employee in the execution of his duties or following the instructions given by his employer, the employer exclusively shall be entitled to exercise all economic rights in the program so created, unless otherwise provided by contract. That is the EU and EEA floor, and it applies only to employment and only to computer programs.

On a commission the default is the other way round, which is why the two cases must not be mixed: a commissioned-work contract typically obliges the author to perform the ordered work and deliver it to the client for use, and it does not by itself say that the economic part passes to the client by payment. A contract for work is silent on copyright altogether, because it governs performance and delivery, not the circulation of rights. A US-style work made for hire for commissioned software is not the European pattern, and it is not the United Kingdom default either.

Put the two together and you get the situation a typical company lands in without knowing it: the client commissions a system from an agency; the programmers are the agency’s employees, so Article 2(3) of the directive delivers the economic part to the agency; the contract between client and agency is a contract for work, which does not move it on. The result is that the client has paid for the result and received the result, but the economic part has stayed with the agency, and the only thing the client has is an unclear implied copyright licence to use the system for the purpose it was commissioned for.

The intuition is common enough that it has to be named in so many words: it is a mistaken belief that the rights in a computer program belong to the person who commissioned and paid for its development, and that payment itself vests those rights in the client. They do not, not automatically, and not by the invoice. The contents of an implied copyright licence stay unclear. The software directive settles employees and leaves commissioners to national law, so the invoice is not where the answer is written.

Receiving files is not receiving rights

The second assumption that does not survive a check is that receiving the code settles anything. Delivery of the object is not delivery of the copyright: economic rights are not tied to ownership of the material thing, and handing over possession of the files does not of itself transfer the author’s rights. In practice that means an archive with the full source, access to the repository, and even complete documentation is still not the same as the right to use that code, adapt it and hand it to another developer.

It also works in the other direction, and this side is less well known, because a company can have acquired the economic rights under a well-written contract and still not have received the source, if the contract had no separate duty to hand it over. A permission without the file is as unusable as a file without the permission, so the contract needs both, and they are two independent clauses, not one clause that includes the other by itself.

When the rights are assigned properly, the governing law still asks for a certain precision, and that is not a formality, because economic rights can be assigned or licensed, and the contract may name both a territory and a term, but the gap-filler if the territory is left blank is not the same in every country: one act treats the silence as the country where the contract was concluded, another adds a five-year cap, and several use purpose or specificity instead of a country default. A company that operates in more than one country, or plans to, has a direct reason to write the territory down, and permission is often needed for each mode of use separately, so a formula about one mode does not open the others.

There is another surprise waiting for a company that lives on an implied copyright licence and has never put it in writing. No single copyright act that an English-language reader can treat as their own writes that an open-ended copyright licence may be terminated on six months’ notice, or that a waiver of that right is void — that mechanism is national, and it is not the same in every country. What remains is the contract: if the only basis for using the system is an unwritten understanding, the governing law fills the silence, and those gap-fillers are not the same in every country.

Moral rights, and what they do not always forbid

The moral part typically includes authorship, the name, the integrity of the work and, in some catalogues, the possibility of withdrawing the work from use, and all of that stays with the author, because none of these elements can be assigned to another person during the author’s life in the continental bundle. UK moral rights are narrower than that bundle, and there is no statutory withdrawal right of that kind in every country. For a company that has commissioned a system this sounds threatening at first, because it creates the impression that a former developer could at some point demand that the system be stopped.

In practice that is not a reliable way to stop a system. In several European acts the author of a computer program cannot, on the basis of moral rights, forbid its transformation, alteration or supplementation unless that use harms honour or reputation, and cannot use a withdrawal right — but that limit is not a 2023 novelty in every country, and some countries never switched transformation-as-moral-right off in that form. That means a former programmer cannot be counted on to halt ordinary maintenance or a rewrite through moral rights, and that is the part of the bundle that would have been dangerous for the company.

Inside the EU there is another rule that is favourable to the company and worth knowing, because otherwise it can be expected from the wrong side. The rules on fair remuneration and the author’s right to receive information about the use of the work, which for other kinds of work let the author come back to the question of payment, do not apply to authors of computer programs — that is Directive (EU) 2019/790 Article 23(2). There is no corresponding statute that an English-language reader can treat as their own: a programmer who thinks the system turned out more valuable than both sides expected cannot claim extra remuneration on that EU ground where the directive has been transposed, and has no equivalent extra-remuneration right in English-language markets that never transposed the directive.

What remains is the possibility of being named as author and protection against a use of the work that harms honour or reputation, and that is a considerably smaller risk to live with. The only thing that must not be confused is two things: transformation as a moral-rights question is no longer a barrier in those acts that have switched it off, but transformation as an economic right still requires the rightholder’s permission, so if the economic part has stayed with the agency, a rewrite of the system still needs its consent.

What you still have without a good contract

Even a company that has formalised nothing still has a few options, and it is worth knowing which of them a contract can take away and which it cannot. Inside the EU and the EEA the useful text is Directive 2009/24/EC; outside it, it is the governing copyright law of the contract. Article 5(1) of that directive lets the lawful acquirer reproduce, translate, adapt or otherwise transform the program as needed for use in accordance with its intended purpose, including for error correction, in the absence of specific contractual provisions — so a contract can take this away, and many contracts do.

Making a backup copy is a different case, and it is the only one in this section that a contract cannot take away, because Article 5(2) of the same directive provides that the making of a back-up copy by a person having a right to use the computer program may not be prevented by contract in so far as it is necessary for that use. Article 8 of the directive further provides that any contractual provisions contrary to Article 6 or to the exceptions provided for in Article 5(2) and (3) shall be null and void.

The difference is fine and easy to overstate: some national acts, for the backup copy, use a wording about the prohibition being inadmissible, and then do not put a separate sentence in the decompilation-for-interoperability article that a contrary contract is void, even though the directive so provides. It is therefore not correct to write that every European copyright act literally takes over Article 8 of the directive; what is correct is to say that a backup copy cannot be taken away in the contract where the directive applies, and that the directive itself additionally treats as void terms that conflict with the decompilation exception.

Decompilation for interoperability, in turn, is permitted narrowly and on conditions: it may be done to achieve the interoperability of an independently created program, if the information is not otherwise available, it is done by a person who has lawfully obtained the right to use a copy, and the act is confined to those parts that interoperability requires. The information obtained may not be used for other purposes or to create a product that is substantially similar, and this way out is useful but narrow, and no company wants it to be the only one.

There is a lot of code in the system that will never be yours

A custom system is almost never only the code the developer wrote, because most of the volume comes from libraries and a framework that already existed. That code never becomes your property, not in any contract, because you receive a licence from its authors, and this difference matters precisely when someone promises to assign all rights in the system.

Permissive licences do not create a problem, because they ask for little and do not restrict how the finished system may be used in a commercial business. The MIT licence allows use, copying, modification, merging, publication, distribution and sale provided the copyright notice and the licence itself are retained, and the software is provided as is, without warranties, while the Apache License 2.0 adds an express patent licence and requires modified files to carry notice of the changes. Both are compatible with a closed commercial system, most modern frameworks are one or the other, and that is why this part of the system usually asks for no negotiation at all.

Copyleft licences ask for attention, not panic, and this is exactly where half-truths are told most often, even though the Free Software Foundation on its GPL FAQ page writes clearly that a company running a modified GPL program on its own website is not required to publish the modified source, because the copyleft duty arises on distributing copies to others, not on using the program in-house. Making and using several copies inside one organisation is not distribution, although handing copies to other organisations, including contractors for use off-site, already is.

The exception is the GNU Affero GPL, and it is section 13 — the network interaction clause (AGPL §13) — that surprises people, because if you modify the program and the modified version lets users communicate with it remotely over a computer network, then those users must be offered a chance to receive the corresponding source. The conditions are two and both are required: modification and remote user interaction, so it is not correct to say that any use of an Affero licence requires publication of the source, and it is not correct to say that one such library automatically subjects the whole system, because that depends on how the components are connected.

Source code escrow with a third party, and what it actually gives

Source code escrow is a three-party arrangement in which the developer deposits the source with a neutral holder, and the holder releases it to the client only when a trigger described in the contract occurs, typical triggers being insolvency, cessation of business or a material failure of maintenance obligations after notice. There is no statute that sets those triggers or even lists them, so everything that operates here is what the parties themselves have written, and that is why the escrow agreement has to be read as carefully as the development contract itself.

Escrow gives exactly what was deposited, and only when what was described occurs, but it does not by itself transfer copyright, because delivery of the object is still not delivery of the rights, and it does not teach anyone how to run the system. NCC Group, which has sold this service for decades, admits as much in its own materials: having the source in the vault is one thing, and being able to compile it is another, which is exactly why the same company also sells verification of the deposited contents. That is an interested party’s assessment, but it is an admission about the weak point of its core service, and that is why it is usable.

Modern systems have a second shortcoming that has nothing to do with the legal side at all: if the system runs as a service on the developer’s infrastructure, then source without the runtime environment, the configuration and the data solves the smaller part of the problem, because the recipient is left with an archive, not a working system. Practitioners close that gap by supplementing escrow with an agreement about who takes over the environment and what happens if the hosting invoices go unpaid, and those are exactly the clauses that usually do not appear on escrow standard forms.

There is also a legal obstacle that sits in insolvency rather than in copyright: in insolvency proceedings the deposited material and its release can come into conflict with the regime of the estate, which is the very event escrow is most often bought for. The practical conclusion is not to refuse escrow, but not to treat it as a substitute for a written assignment of rights and for regular handover of the source.

Where the repository sits and where the data sits

The question of where the code and the data sit decides more than the question of who they belong to, because rights without access are a slow problem. GitHub’s documentation describes clearly that an organisation is a shared account that owns repositories, that you cannot sign in as an organisation, because people sign in with personal accounts, and that organisation owners always have access to every repository; a repository can belong to a personal account or to an organisation, and this choice matters more than it looks.

If the repository belongs to the developer’s personal account, then the client’s access is only collaborator access, which the account owner can revoke at any moment, and when they leave the project they take the address itself with them. If the repository belongs to the client’s organisation, in which the developer has been invited as a member, then leaving means the removal of one access and nothing more, and that is one of the rare things in this article that can be fixed in a single day and without a lawyer.

Data is a separate question, and there the subject is no longer copyright: if the developer processes personal data on your behalf — running production, seeing customer or staff data, or taking backups — then, where the GDPR applies, you are the controller and the developer is the processor. The Regulation applies in the EU and, through the EEA, in Norway; it does not apply of its own force to processing that sits only in, for example, the United Kingdom after Brexit, or the United States. Article 28 requires a written contract with named points: the subject-matter and duration of the processing, its nature and purpose, the types of data and the categories of data subjects, and the controller’s rights and obligations.

Pure coding work without access to personal data does not engage Article 28, so not every development contract needs a processor contract. The boundary is simple and checkable: if the developer can see real customer data, then you need one, but if the developer works only with test data and never sees production, then you do not, and that in itself is an argument for keeping the test environment separate.

What you gain, and what you take on at the same time

The logic of this article so far has been one-sided, so it is only fair to name the other side: full control of a custom system is not only a gain, but also a set of obligations that do not go away. For off-the-shelf software, maintenance, security patches and compatibility with new environments are provided by the vendor, and that is included in the subscription; for a custom system all of that is provided by the owner, which is you, and that is a direct cost that appears every year whether or not anything in the system changes.

The second thing you take on is the ageing of the system, which accumulates quietly and does not show itself in any way until someone looks for it. The system rests on language and framework versions for which the vendors set support dates, and after those dates new vulnerabilities are no longer patched, even though the system continues to run exactly as before and no screen warns you. That is not a prohibition on running an ageing system, but it is the moment at which the owner takes the risk, and the concrete dates for PHP and Laravel we have gathered in the article on what choosing PHP and Laravel actually means, so we do not repeat them here.

The third is the market, and for an off-the-shelf platform a specialist is comparatively easy to find, because they are taught and there are several of them, whereas a custom system is known only to the people who built it, and a new developer has to be given time to learn it before they can change anything safely. That does not mean a takeover is impossible, but it does mean it costs, and that cost appears at exactly the moment when the relationship with the previous developer has already ended.

That is why the question of what you own is not a legal formality, but a question of how expensive the next choice will be. A company with a written assignment, the source in its own repository and a list of the components in use can look for a new developer within a week, whereas a company without all of that first finds out what it is even allowed to do, and only then starts looking, and that is the difference between a conversation from a position and a conversation from need.

What to write in the contract while you still can

All of the previous sections lead to a small set of points worth writing into the contract before work starts, because after handover the negotiating position is much weaker. The first is a written assignment of the economic rights, naming which rights pass, in which territory and for what term, because if the territory is not named the governing law fills the silence, and those defaults are not the same in every country. The second is a warranty that the agency has acquired those rights from its own employees and subcontractors, because without that step the assignment itself can be empty.

The third is regular handover of the source and of everything needed to compile it, not a one-off handover at the end of the project, and the fourth is that the repository sits in your organisation account from the first day. The fifth is a list of the open-source components with their licences, because without that list nobody later will know what is in the system and on what terms; the sixth is a processor contract if the developer will see real data, and the seventh is an agreement about what happens to environments, keys and access when the collaboration ends.

None of these points requires a long text, none of them is in conflict with a good collaboration, and no honest developer objects to them, because they write down exactly what both sides already think. The only thing they change is that the agreement no longer depends on whether the particular people still work at the same company three years later and whether anyone remembers what was said orally at the time. These points are worth asking of any developer, including us, and writing them into the contract before work starts. Our custom software development page currently promises to hand over the source code, the documentation and the infrastructure configuration at the end of the work, and that is exactly why the third point on this list — regular handover as the work proceeds — is worth discussing separately, rather than assuming it is obvious. If you would like us to look at a contract you already have, write to us.