Adapted from the Polish article, originally published on 23 April 2026. The English version was published on 01 October 2026.
The product works and customers are paying. An investor or enterprise buyer asks who owns the code. The founder answers: “We do. It is in our repository.”
Then someone asks for the developer agreements, the supplier’s underlying rights, the licences for reused components and the evidence of transfer to the company. The answer becomes less certain.
To establish software ownership, follow the code from its creator to the entity that sells the product. Repository control, payment and copyright are separate questions. The business problem is common across markets; the statutory formalities below concern Polish copyright law.
What you will learn
- Why repository access and invoices are not a chain of title.
- How founder, employee and contractor contributions can differ.
- What to ask a software development supplier about its contributors.
- How assignments and licences fit third-party code.
- Which ownership gaps to investigate before an investor or customer asks.
In brief
- Trace each material contribution from its creator to the company.
- Distinguish ownership, licence scope and practical repository control.
- Check contractor transfers and third-party components before giving ownership assurances.
Start with contributors, not the repository name
List the important modules and who created them. A single repository can combine code written before incorporation, employee work, contractor contributions, supplier libraries and open-source dependencies.
For each contribution, identify the original rightsholder, the legal basis for the company’s rights and any conditions still outstanding. That sequence is the chain of title. A commit history can help identify contributions, but it is not an assignment agreement.
Ask which legal entity received the rights. An agreement signed by a founder personally before incorporation does not itself explain how the company later acquired them. An agreement with one group company may not establish rights in another company selling the software.
Founder code may predate the company
A founder can bring an existing prototype or a library used across several projects. Distinguish code created for this product from reusable materials that remain theirs.
Record what the company owns and what it licenses. For a retained library, the licence should support the intended product use and continuity if the founder leaves. Avoid an arrangement that works only while the founder informally approves every change.
Coordinate that work with the founders agreement. Owning shares in the company does not explain the legal basis for every piece of code contributed to it.
Employees and contractors are different routes
Under Article 74(3) of the Polish Copyright Act, economic rights in a computer program created by an employee in performing employment duties belong to the employer unless the agreement provides otherwise. Check the employment relationship and duties. Do not apply that rule automatically to a freelance or business-to-business developer.
For contractor code, review the actual assignment or licence. Payment for development and delivery of source files do not by themselves prove the company acquired economic copyright.
Where Polish law governs an assignment, Article 53 requires the prescribed written form for validity; the agreement must identify the relevant work and expressly cover the fields of exploitation. Check transfer timing and the rights needed for modification, distribution and the intended product model. For electronic execution, confirm that the signature meets the required form rather than assume any online acceptance does so.
The same documentation shortcut may affect UI, design or technical documentation, but those assets should not automatically be treated as employee-created computer programs.
A software house needs an upstream chain too
The startup’s contract may promise delivery and broad rights, yet the supplier may itself rely on freelancers, subcontractors and pre-existing components. Ask how the supplier obtains the rights it promises to transfer or license.
Match the agreement to the delivered modules, acceptance records and payment conditions. If rights transfer only after a specified payment or acceptance event, establish whether it occurred for the code already in production.
Request a clear list of retained supplier materials and third-party components. A warranty can allocate risk, but it is not evidence that a missing upstream transfer actually happened.
Not every line should be company-owned
Open-source and commercial libraries usually remain subject to their own licences. The question is whether the company may use, modify and distribute them in the way the product requires, and whether it meets the relevant conditions.
Record the component, version, source and applicable licence. Code found on a public repository should not be treated as freely reusable merely because it is visible. Check the actual permission and intended use.
Some licence conditions depend on distribution or network use. Review the specific licence and deployment model rather than label all open source safe or incompatible with SaaS. Identify any copy-pasted code whose origin the team cannot explain.
Repository control is another necessary check
The company can have legal rights yet lack practical access after a supplier or founder leaves. Conversely, it can administer the repository while lacking the necessary rights to commercialise what is inside.
Confirm administrative control, required history, build materials and access recovery. Keep the contributor records, contracts and deliverable references together so an ownership claim can be checked without relying on memory.
A common MVP problem
Consider a hypothetical product built from a founder’s prototype, a B2B developer’s new modules and a software house’s reusable library. Every invoice is paid and the company controls the repository. The developer’s contract contains no effective assignment, while the library’s permitted uses are unclear.
The product can run while those gaps remain. They become commercially painful when an enterprise customer asks for licensing assurances or an investor makes ownership repairs a closing condition.
Map the gaps first. Agree the necessary transfer or licence with the actual rightsholders, fulfil the relevant formalities and retain evidence. Do not backdate documents or promise the investor that an invoice cured the issue.
Five ownership questions before the next deal
- Who created each material part of the code, and for which entity?
- What assignment, licence or statutory rule gives the company rights?
- Were the required form and transfer conditions satisfied?
- Which components remain third-party or pre-existing IP?
- Can the company both lawfully commercialise the software and practically maintain it?
This is a focused ownership review. For the wider product inventory, branding, design, AI-assisted assets, domains and transaction preparation, use our startup IP due diligence guide. That guide covers the broader review around the code’s chain of title.
For help resolving Polish assignments and supplier documentation, see our startup services and software contract services, or contact us.
Sources and further reading
- Ustawa o prawie autorskim i prawach pokrewnych, Polish Copyright and Related Rights Act, particularly Articles 41, 53 and 74. Official text in Polish.