Imagine you're preparing to sell your SaaS company. You do due diligence, the buyer asks for evidence that your business owns the software it's selling. Most of the code was written by your employees, but an important part of the backend came from a developer you hired overseas two years ago. You find the original contract. It covers the project scope, payment terms, and delivery deadlines. There's nothing about transferring copyright.
Now the buyer's legal team wants to know whether you actually own that part of the application.
It's an uncomfortable question, especially when the developer has moved on and the code has since been modified by several other engineers.
International development teams run into this risk because paying someone to write software doesn't always mean they have ownership. The developer's employment status and the laws governing their work sometimes affect the company in different ways.
Your GitHub repository tells only part of the story
Engineering teams have fairly straightforward ways to track software development. Git records who contributed particular changes, pull requests document reviews, and repository permissions determine who has access. None of those records establish that copyright has been transferred.
If you hire a contractor to develop a payment integration and they complete the project inside your GitHub repository and invoice you for the agreed amount. Your developers take over maintenance, and the integration becomes part of your commercial product.
You have a working application and evidence that the contractor delivered what you paid for. The legal rights you received depend on the applicable law and the original agreement.
Copyright protects qualifying original expression in software, including source code. It doesn't generally protect the underlying programming ideas or methods. The copyright owner controls certain uses of that expression, subject to applicable exceptions and licenses. In many jurisdictions, independent developers initially own copyright in qualifying work they create unless it transfers through an agreement or another legal rule.
An IP assignment is one way to establish that transfer. Its wording matters because a business might require rights to modify software, incorporate it into other products, or license it to customers.
These questions are easier to resolve while negotiating the development contract than after the finished code has been integrated into a product.
Three hiring arrangements, different ownership questions
Software companies hiring internationally generally encounter three arrangements. They employ developers directly, engage independent contractors, or hire employees through an employer of record (EOR).
Each arrangement has implications beyond payroll and the practical management of developers.
| Hiring arrangement | What to examine |
|---|---|
| Direct employee | The employer's rights under local copyright law and the employment agreement |
| Independent contractor | Whether the client has received an effective assignment or suitable license |
| Employee hired through an EOR | How rights pass from the developer through the relevant employment and commercial agreements to the client |
The developer on your payroll
In many countries, employers receive particular rights in software developed by employees as part of their duties. That doesn't mean every project an engineer works on automatically belongs to the company.
Someone employed to maintain a cloud application might also develop a personal budgeting app during their free time. Whether that personal project falls within an employer's rights depends on the applicable rules and contractual terms.
The boundaries become harder to interpret when employees use familiar tools across both projects or bring existing libraries into their work, so a well-drafted employment agreement addresses the scope of the employee's work and any relevant pre-existing intellectual property.
The overseas freelancer
Consider a freelancer who develops your application's reporting functionality, there’s a chance that they reuse a utility from an earlier project and write the remaining application code specifically for your business. Agreement could transfer ownership of the newly commissioned code while allowing the developer to retain their reusable library. Your company would then require suitable licensing rights for that library.
The developer's legal classification introduces another consideration. An independent contractor might qualify as an employee under the relevant country's employment rules.
This is particularly relevant to remote developers working exclusively for one company under close supervision. The distinction between contractors and employees affects the employment rules governing the arrangement, including the framework within which IP rights must be considered.
If that freelancer later joins your company as an employee, you should check the earlier contract as well. The new employment relationship doesn't necessarily settle ownership of software they produced before joining.
Hiring through an employer of record
An EOR arrangement adds another organization to the employment relationship.
If your US company hires a developer in Spain without establishing a Spanish subsidiary. An EOR becomes the legal employer, while your engineering manager assigns the developer's work and reviews their contributions, so the developer works on your product, but the employment contract is with the EOR.
This is important when determining how rights to the software reach your business. The employment agreement and the commercial arrangement between the EOR and its client must be considered together, with attention to applicable local law.
An EOR may have established processes for addressing IP provisions, but the actual agreements still require review. Engineering teams should be clear about which organization is intended to hold the rights before the developer begins contributing commercially important code.
Reusable library problem
Most developers maintain a collection of code they've used before. Small validation functions, some internal library that saves weeks of development, various reusable instances of code. This creates an ownership question that broad contract language doesn't always resolve easily.
If a developer was hired to build an authentication service for your SaaS platform, they can write the application-specific logic and incorporate a private utility library from an earlier project. The finished service also depends on an open-source cryptography package. Your company receives ownership of the new work without acquiring copyright in either dependency most of the time.
That isn't necessarily a problem. Commercial software routinely depends on components the business doesn't own. The important question is whether the licenses permit the intended use. Privately developed library might require a license covering continued use, modification, and distribution. The open-source package comes with its own conditions.
Those conditions vary. Some open-source licenses primarily require preservation of notices, while others impose additional obligations when covered software is distributed. Engineers need to understand the licenses attached to the dependencies they're introducing.
A software bill of materials (SBOM) provides a structured record of components included in an application. It won't resolve copyright questions by itself, but it gives teams a reliable starting point when they need to investigate a dependency's origin.
For proprietary libraries, the development contract should distinguish previously created material from newly commissioned work. That distinction is easier to document when the developer first introduces the component.
What happens when an IP assignment is poorly written?
A contract stating that the company owns "all intellectual property" might seem sufficient until someone has to establish exactly which rights were transferred. The wording could cover software developed for a particular project while leaving uncertainty about reusable components or work created outside the original scope. Broad language doesn't necessarily resolve those questions, especially when different countries impose their own requirements on copyright assignments.
The timing of the transfer is another potential problem. An IP assignment might require the developer to sign a separate document before copyright transfers. If that paperwork never gets completed, the company could end up contacting a former contractor years later, perhaps during an acquisition when buyers are asking for proof of ownership. Depending on the agreement and applicable law, the business may have a contractual right to demand the assignment without having acquired the copyright itself.
Ownership of every component isn't always necessary. Developers frequently reuse libraries across client projects, and transferring those libraries outright is impractical. A suitable license could give the company the rights it requires to maintain, modify, and commercially distribute its software while leaving ownership of the underlying library with the developer.
The engineering team has a role in getting those terms right. Lawyers drafting an agreement need to understand whether a component will remain inside an internal application or be distributed to customers as part of a commercial product. A clear explanation of how the software will be used makes the contract more precise than a generic clause claiming ownership of everything produced during the engagement.
Software ownership rules vary by country
Copyright law doesn't treat internationally hired developers the same way everywhere. The differences become particularly relevant when a business uses a standard employment or contractor agreement across several countries, even when the same developer responsibilities are involved, the legal rules governing ownership and assignment usually differ.
United States
The work-made-for-hire doctrine generally treats qualifying work created by an employee within the scope of employment as belonging to the employer. Independent contractors are subject to narrower requirements, and describing a project as "work made for hire" in a service agreement doesn't automatically make it one.
The US Copyright Office explains that specially commissioned works must satisfy specific statutory conditions, including a signed written agreement and inclusion within an eligible category. Ordinary freelance software development won't necessarily meet those conditions, so companies commonly rely on a separate copyright assignment to establish ownership of commissioned code.
United Kingdom
Section 11 of the Copyright, Designs and Patents Act 1988 generally makes the employer the first copyright owner of qualifying work created by an employee in the course of employment, unless an agreement provides otherwise. The rule concerns employees, which means a company commissioning software from an independent contractor cannot simply rely on the same statutory treatment.
An overseas business hiring a UK developer therefore has to establish the nature of the working relationship and the rights provided by the contract. The employment classification and the agreement both affect the ownership analysis.
European Union
Directive 2009/24/EC sets out specific rules concerning copyright in computer programs. Article 2(3) generally entitles an employer to exercise the economic rights in software created by an employee while performing their duties or following employer instructions, unless the contract provides otherwise.
The directive operates through national legal systems, and ownership of other forms of intellectual property can follow different rules. A business developing potentially patentable technology may face requirements beyond those governing software copyright. Companies hiring across multiple EU countries still have to account for the relevant national laws.
A governing-law clause selecting the company's home jurisdiction doesn't necessarily override mandatory legal provisions in the country where a developer works. This becomes particularly significant when an employer of record or another third party sits between the developer and the business commercializing the software. The agreements need to establish a legally effective path for the relevant rights, taking the local requirements into account.
Developer offboarding, IP records, and knowledge transfer
When a developer leaves, engineering managers usually concentrate on unfinished features, documentation, and access to development systems. Someone else needs to understand the code well enough to maintain it, while the departing developer has to return company-owned materials and lose access to systems they no longer require.
IP documentation should be reviewed during the same process, because developers may have introduced a private library without clearly recording its license, or an earlier contractor agreement still requires a signed assignment. Resolving those questions while the developer is available is easier than trying to reconstruct their work months later.
If the departing developer built a critical part of the application, the handover may involve technical walkthroughs and training sessions for the engineers taking over. Larger teams sometimes keep training completion records so they know who has completed the required handover sessions before assuming responsibility for a system. Those records can support continuity, although the original agreements are still what establish the company's legal rights to the code.
Changes in employment arrangements can also affect the documentation. When a contractor becomes a direct employee, earlier work may remain governed by the original service agreement. A developer moving between legal employers may have separate agreements covering different periods of employment, so the company needs to retain records covering each period.
Could your company prove ownership of its core software?
During an acquisition, the buyer's legal team may request evidence that the business owns or has sufficient rights to use the technology being sold. That request can become difficult when the product contains contributions from overseas contractors, former employees, and developers hired through third parties. Git history might identify who wrote a particular module, but the contracts establish what rights the company acquired.
The easiest way to prepare for that situation is to maintain IP records alongside the information engineering teams already keep about their software. When a developer introduces a private library, its licensing terms can be documented with the component. Employment agreements and completed assignments should remain accessible after the developer leaves, with records connecting them to the relevant work.
Engineering managers don't need legal counsel reviewing every pull request. They can identify changes that raise ownership questions, such as the introduction of a privately developed dependency or a developer moving into a different employment arrangement. Legal counsel can then determine whether the existing agreements cover the situation.
A useful internal exercise is to select one commercially important module and trace the rights behind it. The team should be able to identify who created the code, which agreement governed the work, and whether third-party components impose separate licensing conditions. If that information is scattered across old emails and undocumented agreements, the company has a records problem to resolve before someone outside the business asks for proof.
The benefit extends beyond an eventual sale. Developers can reuse components with greater confidence when their licensing terms are known, and customers requesting evidence of software rights receive answers based on actual documentation. That makes IP ownership a practical part of maintaining a software product over time.
