Who owns the code: what your contract with a Polish studio must say

Who owns the code is not settled by paying the invoice, and not by signing off the release either. Economic copyright moves to the client only through a written contract that names specific fields of exploitation — and only if the company signing it had itself acquired those rights from the people who physically wrote the code. That third condition breaks most often, because in Polish development teams a large share of people work on B2B contracts rather than employment contracts. Everything below describes the Polish Copyright Act of 4 February 1994, which is what applies when you contract a studio based in Poland; if your vendor sits in another jurisdiction, the default answers can be different. This material is information, not legal advice.

The three conditions that decide who owns the code

Economic rights to the code pass to the client only when three conditions are met together: the contract is in writing, it expressly names the fields of exploitation, and the vendor holds an unbroken chain of transfers from every author. Miss any one and you are paying for something you do not legally receive.

Art. 53 of the Polish Copyright Act says that a contract transferring economic copyright requires written form on pain of nullity. That is the harshest sanction Polish civil law knows: without the written form the transfer simply does not happen, whatever the parties promised each other.

Art. 41(2) adds a second filter — a transfer contract or a licence covers only the fields of exploitation expressly named in it. Anything the contract does not name stays with the author. Art. 41(4) closes the subject: a contract may only cover fields known when it is concluded, so a clause stretching rights over future ways of using the work adds nothing.

Why art. 74(3) does nothing when the team works on B2B contracts

Art. 74(3) gives the economic rights in a computer program to the employer only where the program was created by an employee performing duties under an employment relationship — and only unless the contract says otherwise. That is all it does: it does not cover mandate contracts, contracts for specific work, or cooperation with a sole trader.

The consequence is practical. If five developers write your app and two are employees while three invoice you through their own businesses, the software house automatically holds rights to part of the code only. The rest stays with the authors until each of them transfers it by a separate written contract, with fields of exploitation named, because art. 53 and art. 41(2) apply at every link in the chain, not only the last one. The same goes for subcontractors handed a module or the front-end layer.

Ask directly how the team is structured and what its members signed, then require one statement in the contract.

This belongs at the request-for-proposal stage, not at handover; alongside scope and budget it should sit in the document described in the guide on how to write a software project brief. The wording above is an English rendering; the contract itself will normally be in Polish and governed by Polish law, so have a Polish lawyer check it. If you would rather work the questions through with someone, tell us about the project.

Which fields of exploitation to put in a software contract

With a computer program you do not have to invent anything: art. 74(4) of the Polish Copyright Act itself enumerates the economic rights in a program, and that list works as a ready catalogue to copy into the contract. It covers three items: reproduction, alteration and distribution.

The second item matters most to the client, even though it looks the most technical. It decides whether you can hand development to anyone other than the original author. Without the right to make alterations you own code you are not allowed to fix.

The clause on the left looks stronger and is weaker: art. 41(2) requires the fields to be named expressly, and art. 41(4) rules out fields unknown when the contract was signed. The statutory list takes three lines and leaves no room to argue about what the parties meant.

What protection covers: the code yes, the idea no

Art. 74(1) gives computer programs the same protection as literary works, and art. 74(2) extends it to all forms of expression of a program while expressly excluding the ideas and principles underlying it. You are buying a specific expression, not a monopoly on an idea.

That has two effects. Transferring the rights does not stop the vendor from building a similarly working solution from scratch — exclusivity in your industry has to come from a separate contract clause. And a dispute about copied functionality is far harder to run than one about copied code, so your real protection is ownership of the repository plus a written list of what the vendor may reuse.

Transfer or licence — when a licence is enough

A transfer means the economic copyright passes to you and you decide what happens to the code next. A licence is permission to use the code on terms set by the rights holder, who keeps the rights. Art. 41(2) treats both contracts the same way — each covers only the fields of exploitation expressly named in it.

In practice almost every project is a mixture, and the contract should look like one:

• Transfer — custom code written specifically for you: business logic, integrations, the interface, the database schema.
• Licence — open source libraries, off-the-shelf components, the vendor engine or platform, software sold on subscription.

A licence is enough while you pay to use a finished product and do not plan to develop it with your own people. It stops being enough when you want to change vendors, sell the company or the product, bring in an investor, or move development in-house. Ask for a list of third-party components with their licences — that line item shapes maintenance and the mobile app development cost in later years.

The billing model settles nothing here: rights are transferred by the contract, not by the way you are invoiced, although the differences between fixed price and time and materials affect when you take delivery of each part of the code.

What to collect besides the code: repository, documentation and access

Rights to code without access to the code are useless, so write down next to the transfer clause exactly what you get at handover and in what form. Handover is the last stage of the process covered end to end in the guide on how to build a mobile app.

• Source code with repository history. Not a ZIP file at the end of the project, but a repository owned by your organisation from day one, with the vendor added as a team member.
• Documentation. Specifications plus user and developer documentation — the last decides whether a new team runs the project locally in a day or in two weeks.
• Access and accounts. Hosting, the domain, third-party services, API keys and app store accounts belong to your company, not the vendor. An account registered to a developer private address is a real point of failure.
• Exit plan and subcontracting rules. A typical implementation contract carries both: the first describes how the project is handed over, the second whether the vendor may bring in a subcontractor without your consent.

The cheapest moment to settle these points is the request for proposal. Repository ownership and the exit plan are also two of the seven questions in the guide on how to choose a software house, and an evasive answer to either one at the first meeting tells you more than any portfolio. The most expensive is the day you decide to change vendors.