A startup has been developing its flagship product for 2 years. The team is mostly developers from body leasing companies - 8 out of 10 people. Core algorithm, architecture, entire codebase written by external specialists. Series B funding round comes, due diligence, and a question from the VC lawyer: “Do you have all copyrights transferred from subcontractors for the code?” The CEO checks the contracts. Silence. Nobody thought about it.
This situation repeats in dozens of companies. In the rush for fast development, they forget about a fundamental question: who owns the code that external specialists create? Under copyright law, the answer isn’t obvious - and can be very costly if not properly addressed in the contract.
How does copyright law treat code created by external developers?
“The global IT outsourcing market is projected to reach $541 billion in 2025, with a compound annual growth rate of 8.4%.”
— Statista, IT Outsourcing — Worldwide Market Forecast | Source
Default rule: the creator is the owner. In copyright law, economic rights belong to the creator - the person who created the work. The developer who wrote the code is originally its owner, regardless of who paid them.
Exception: employee work. If a work was created within an employment relationship, the employer acquires economic rights upon acceptance of the work. But this only applies to employment contracts - not B2B contracts, not service agreements, not body leasing.
Body leasing = not an employment relationship. A developer from a body leasing company isn’t your employee. They’re an employee (or contractor) of the body leasing provider. Automatic transfer of rights doesn’t occur.
Contract governs transfer. For the body leasing client to acquire rights to the code - it must be explicitly regulated in the contract. And in a specific way required by copyright law.
Chain of rights can be long. Developer → Body leasing company → Client. Each link must properly transfer rights. A gap in one link = gap in the entire chain.
What are the legal requirements for effective copyright transfer?
Written form required for validity. Under copyright law: the agreement for transfer of economic copyright requires written form. Without a signature on paper (or qualified electronic signature) - the transfer is invalid.
Specification of exploitation fields. The agreement for transfer of rights covers only those exploitation fields that are explicitly listed in it. General “transfer of all rights” without listing fields is risky.
Exploitation fields include:
- recording and reproduction (copying)
- trading in original or copies (sale)
- distribution (public sharing)
- rental, lending
- loading into computer memory
- public performance, exhibition, display
- broadcasting, rebroadcasting
- public sharing (internet)
Unknown exploitation fields. Transfer of rights to exploitation fields unknown at the time of contract conclusion requires a separate agreement. The clause “and all future exploitation fields” is ineffective.
Future works with limitations. Transfer of rights to works not yet created is possible, but they must be sufficiently defined. “Everything the developer writes” may be too general.
What does a proper body leasing contract structure look like regarding IP?
Three-party relationship. Developer - Body leasing provider - Client. Must regulate: (1) Developer transfers rights to Provider, (2) Provider transfers rights to Client. Alternatively: Developer transfers rights directly to Client with representation by Provider.
IP clause in framework agreement. The agreement between Client and Provider should include:
- Provider’s obligation to ensure transfer of rights from developers
- timing of transfer (e.g., upon acceptance of sprint/deliverable)
- list of exploitation fields
- representation that Provider has the right to transfer (has them from developers)
- regulation regarding open source software used in the project
Agreement between Provider and Developer. The Provider must have an agreement with the developer that:
- transfers rights to works to the Provider (or directly to Client)
- covers all necessary exploitation fields
- is in written form
Assignment vs. license. Transfer (assignment) means the transferor loses rights. License means they retain rights but grant permission to use. For code that should be owned by the client - assignment is safer.
What about open source code and third-party libraries?
Developer doesn’t create everything from scratch. They use frameworks, libraries, tools. Rights to those elements remain with their authors. Open source licenses define terms of use.
Permissive licenses (MIT, BSD, Apache 2.0). Allow inclusion in proprietary software with minimal requirements (attribution, preserving license notice). Generally safe for commercial projects.
Copyleft licenses (GPL, AGPL). Require making derivative works available under the same license. Using a GPL library in your product may require open-sourcing your code. AGPL also covers network use (SaaS).
SBOM and license compliance. The client should require a list of all dependencies and their licenses. Without this - risk of violating third-party licenses.
Contract should regulate. Developer represents that: (1) original code is original, (2) third-party components used are legally licensed, (3) licenses are compatible with commercial use by Client.
What risks are associated with inadequate IP regulation in body leasing?
Inability to dispose of ownership. If you don’t have copyrights to the code - you can’t legally sell it, license it, sublicense it. This blocks M&A, product licensing, partnerships.
Due diligence in investment round. VC/PE conduct IP due diligence. Lack of clear rights = red flag. Can block investment or significantly reduce valuation.
Disputes with former providers. Cooperation with body leasing company ends. They claim their developer wrote the code so they have rights to it. Without clear contracts - expensive court dispute.
Claims from developers. A specific developer finishes the project, starts a competing company, claims “their” code was stolen. Without documented transfer - risk.
Problems at exit. You’re selling the company, buyer wants guarantees that all code is legal. You can’t give such guarantee because you don’t have contracts with all developers from 5 years ago.
Open source license violation. Developer used GPL library, you don’t know, you sell a closed-source product. FSF sends cease-and-desist. Reputational and financial consequences.
How to conduct an IP audit of existing body leasing cooperation?
Gather documentation. All contracts with body leasing providers. All orders/statements of work. Check if they contain IP clauses.
Identify gaps. Which contracts don’t have rights transfer? Which have incomplete exploitation fields? Which are only in email form (invalid)?
List of developers and their contributions. Who worked, when, on what. Mapping authors to code. Git blame and commit history help.
Remediation plan. For each gap - solution: contract amendment, new agreement, statement. Prioritize by risk and code value.
For former collaborators. If provider or developer no longer cooperates - need to find them and sign post-facto agreement. May require negotiation (and potentially compensation).
Documentation going forward. Introduce standards for all new collaborations: contract template, IP checklist, legal review.
What should an IP due diligence checklist for new body leasing projects contain?
Before starting:
- Does framework agreement contain IP clause with full exploitation fields?
- Is contract form valid (written)?
- Does Provider represent they have the right to transfer (have them from developers)?
- Is open source software regulated?
During project:
- Has every developer signed appropriate documents?
- Is there tracking of who writes what code (git)?
- Is there a register of used libraries and licenses (SBOM)?
- Does code review include check for problematic licenses?
At completion/deliverable:
- Is there formal acceptance of works (acceptance protocol)?
- Is transfer documentation complete?
- Is SBOM current and verified?
At end of cooperation:
- Have all rights been transferred?
- Developer doesn’t retain code copy (except portfolio)?
- Does NDA remain in force?
How to regulate rights to developer’s tools and reusable components?
Developer brings a toolkit. Experienced developers have their own tools, snippets, libraries they use across many projects. Transferring rights to them to one client would prevent further use.
Solution: license instead of assignment for generic tools. “Developer grants Client a non-exclusive, perpetual license to tools X, Y, Z used in the project. Rights to these tools remain with Developer/Provider.”
Distinction: project-specific vs. generic. Code specific to the project (business logic, features) - assignment to Client. Generic code (utils, helpers used everywhere) - license.
Documentation of distinction. List of components with designation: “assignment” or “license”. Prevents later disputes “but that’s my tool!”
Avoiding derivative works issue. If project-specific code is a derivative work of developer’s tool - the matter gets complicated. Architecture should account for this.
What provisions protect both parties - client and provider?
For client (rights acquirer):
- Provider’s representation that code is original and doesn’t infringe third-party rights
- Guarantee that provider has the right to transfer (has them from developers)
- Indemnity clause - provider covers damages from third-party IP claims
- Right to sublicense and modify without restrictions
- No territorial or temporal limitations
For provider:
- Clear specification that transfer occurs after payment (IP retention as security)
- Right to reference and showcase (preserving confidentiality)
- License for generic tools/components (doesn’t lose their toolkit)
- Liability limitation to contract value
- Acceptance procedure (after acceptance client can’t challenge IP)
For developer:
- Clarity about transfer scope (not “everything you ever create”)
- Retention of rights to pre-existing toolkit
- Right to portfolio/demonstration (without disclosing secrets)
- Compensation for transfer (included in rate)
How does the situation differ across cooperation models?
Time & Materials body leasing: Developer works under client direction, code created “on the fly”. Rights transfer should be continuous (e.g., at each sprint review) or automatic upon creation. Key: continuity of transfer, not just at project end.
Fixed-price project: Deliverable is defined. Rights transfer occurs at final acceptance (or milestone). IP retention until payment is standard. Client must ensure ALL rights are transferred (including intermediate deliverables).
Managed services / outsourcing: Provider maintains system, makes changes. New code created as part of maintenance - does client acquire rights? Must be explicitly regulated.
Consulting / advisory: Consultant delivers analyses, recommendations, documentation. These are also works under copyright law. Are reports, presentations, specifications transferred?
Table: IP checklist for body leasing agreement
| Area | Element to Include | Responsible | Risk of Omission |
|---|---|---|---|
| Contract form | Written with signatures (or qualified e-signature) | Legal both sides | Transfer invalidity |
| Exploitation fields | Full list (recording, reproduction, distribution, modification, sublicense, etc.) | Client legal | Limited rights |
| Chain of rights | Provider representation that they have rights from developers | Provider + legal | Gap in chain, ineffective transfer |
| Transfer timing | Specified (at acceptance, at payment, continuously) | Both parties | Dispute over timing |
| Open source | List of allowed licenses, SBOM requirement | Development team + legal | GPL/AGPL license violation |
| Pre-existing IP | Distinction: assignment for project-specific, license for generic | Developer + legal | Developer loses their tools |
| Indemnity | Provider covers third-party IP claims | Client legal | Client bears cost of disputes |
| Moral rights | Waiver or non-exercise (authorship, integrity) | Legal | Developer can block modifications |
| Territorial scope | ”Worldwide” without limitations | Client legal | Limited geographic use |
| Temporal scope | ”Perpetual” | Client legal | Rights expire |
| Documentation | Acceptance protocols, git history, SBOM | PM/Tech Lead | Lack of ownership evidence |
| Confidentiality | NDA covers code as confidential information | Legal both sides | Code leak |
Intellectual property in body leasing is an area where mistakes are expensive and hard to fix. A contract that “somehow” regulates IP may prove insufficient when real money appears - investment, company sale, court dispute.
Key takeaways:
- By default the developer owns the code - transfer requires explicit contract
- Written form is mandatory - email or verbal agreement isn’t enough
- Exploitation fields must be listed - “all rights” isn’t enough
- Chain of rights must be complete - developer → provider → client
- Open source has its licenses - SBOM and license compliance are necessary
- Developer’s pre-existing tools are a separate matter - license instead of assignment
- IP audit should be done regularly - not just at due diligence
Best practice: engage a lawyer specializing in IP and IT at the contract negotiation stage, not when problems appear.
ARDURA Consulting offers transparent body leasing contracts with full intellectual property regulation. Our clients receive clean rights to code, compliance with open source licenses, and documentation meeting due diligence requirements. Contact us to discuss secure cooperation with external IT specialists.