Key takeaways
Under Polish law, transferring economic copyright in the code requires a written contract — without one, the rights don’t formally pass to your company.
The contract only covers the fields of exploitation explicitly listed in it, so the list should reflect how you’ll actually use the system.
The code, repository, documentation, and infrastructure accounts should belong to you or be fully accessible to you — otherwise switching vendors becomes very difficult.
Acceptance procedures, a change process, and exit terms protect you more than a high contractual penalty.
Why the contract matters more than the quote
When choosing a vendor, attention focuses on price and deadline. Yet it’s the contract that decides what happens when something goes wrong: when the deadline slips, the scope changes, or you want to move the system’s development to another company.
The most expensive problems in IT projects rarely come from the quality of the code itself. More often, they come from a company paying for a system but not having full rights to it, access to the repository, or the cloud provider accounts. Below we go through the clauses worth checking before signing — in order of importance.
Note: this article describes Polish law and is provided for information only; it is not legal advice. For larger projects, it’s worth having the contract reviewed by a lawyer specializing in IT.
Copyright in the code: transfer or license
Under Polish law, a computer program is protected as a work — the Polish Act on Copyright and Related Rights devotes a separate chapter to it. From the ordering company’s point of view, three provisions are key.
Written form. A contract transferring the author’s economic rights must be made in writing, or it is null and void (Art. 53). Accepting an offer by email or a clause in terms and conditions isn’t enough.
Fields of exploitation. The contract covers only the fields of exploitation (in Polish: pola eksploatacji) explicitly listed in it (Art. 41(2)). A general statement that rights are transferred “in all fields of exploitation” is no substitute for a specific list.
Scope of rights in a program. For computer programs, the Act explicitly lists, among other things, the right to permanent or temporary reproduction of the program, the right to its “translation, adaptation, rearrangement, or any other modification” (our translation), and the right to distribute it (Art. 74(4), in Polish).
In practice, you have two options. A transfer of rights means that once the contract’s conditions are met, the system is yours. A license means you can use it within a defined scope, while the rights stay with the vendor. A license can be justified when the system is built on top of the vendor’s existing product. For software built from scratch around your process, it’s usually worth pushing for a transfer of rights.
Separately, make sure you have the right to modify the code and commission its further development from other companies. Without an explicit clause, switching vendors can become contentious.
Fields of exploitation worth listing for software
The list should reflect how you’ll actually use the system. It most often includes:
Reproduction — Permanent and temporary, in whole or in part — including installing, running, storing, and displaying the program.
Modification — Translation, adaptation, rearrangement, and any other changes to the code.
Distribution — Including making the system available to users over the internet, if it will run as an online service.
Adaptations and derivative rights — The right to create new versions, commission them from other vendors, and use those adaptations.
Further transfer and licensing — In case the company is sold, licenses are granted to partners, or the system is moved to a subsidiary.
Documentation and materials — The same fields for documentation, visual designs, and other materials created during the project.
When the rights pass to your company
It’s worth setting the moment of transfer explicitly. The most common options are transfer upon payment of the fee for a given stage or upon acceptance. Payment is safer for the vendor, acceptance for the ordering company. A reasonable compromise is to transfer rights in stages, together with the payment for each accepted stage.
Until the rights are transferred, the contract should grant you a license to use what has already been built. Otherwise, for part of the project you’re using a system you formally have no rights to at all.
Source code and access — what you must receive
Copyright is half the story. The other half is a real ability to take over the system:
Code and repository
Continuous access to the repository throughout the project, ideally a repository under your company’s account. Not just a package of code handed over at the end.
Documentation
A description of the architecture, instructions for running and deploying the system, and a description of the integrations. Without this, a new vendor starts by analyzing someone else’s code.
Infrastructure accounts
Cloud, domains, app stores, payment and email providers — set up in your company’s name, with access granted to the vendor.
Open-source libraries
A list of the components used and their licenses. Nobody can transfer rights to third-party libraries to you, and some licenses impose obligations when the software is distributed.
Acceptance, changes, and payments
These clauses determine how the project runs day to day:
Acceptance criteria
For each stage, a description of what has to work and how you’ll check it. “A working orders module” isn’t enough — you need concrete scenarios.
Deadline for raising issues
How many days you have to test and report issues, and what happens if you don’t. Watch out for a clause on automatic acceptance once that period expires.
Change procedure
How you request a change, how quickly you get a quote and its impact on the deadline, and who approves it on both sides.
Payment for outcomes
Payments tied to the acceptance of stages, not to the calendar. With time-based billing — to time reports.
Warranty, statutory warranty, and maintenance
If the contract is a contract for a specific work (in Polish: umowa o dzieło), the provisions on statutory warranty for defects in sales (rękojmia) apply accordingly to the vendor’s liability for defects (Art. 638 of the Polish Civil Code). Between businesses, however, the parties can as a rule extend, limit, or exclude that statutory warranty (Art. 558 § 1 of the Civil Code; exceptions apply to consumers, among others) — and IT contracts often do.
That’s why it’s worth checking whether the contract offers a contractual guarantee in return: for how long the vendor fixes bugs free of charge and how quickly it responds. For business-critical systems, add a maintenance agreement with an SLA, i.e. service levels: response time and resolution time for issues of different severity.
It’s worth distinguishing the two times explicitly. Response time is when someone starts working on a report. Resolution time is when the problem is fixed or worked around with a temporary solution. A contract that only guarantees a response guarantees very little.
Planning a project and want clear rules from the start?
Let’s talk about scope, stages, and acceptance before they end up in the contract. A well-described project means a simpler contract for both sides.
Red flags in a contract with a vendor
None of these clauses necessarily rules out working together, but each one needs to be clarified before signing:
A license instead of a transfer of rights — without justification
If the system is built from scratch around your process, ask why the rights should stay with the vendor.
No list of fields of exploitation
A general “all fields of exploitation” or no list at all creates a risk that key ways of using the system aren’t covered by the contract.
Infrastructure accounts in the vendor’s name
A cloud account, domain, or app store account set up in the vendor’s name is a real obstacle when you change providers.
No change procedure
Changes will come anyway. Without a procedure, each one is a negotiation from scratch.
No terms for ending the engagement
The contract should state what the vendor hands over when you part ways and within what time — including if notice is given mid-project.
GDPR, confidentiality, and ending the engagement
Personal data. If the vendor will have access to personal data — for example, to a production customer database during migration or maintenance — you need a data processing agreement within the meaning of Art. 28 GDPR. It’s worth putting it in place in parallel with the main contract, because the lack of one can halt a project at the least convenient moment.
Confidentiality. The contract or a separate NDA should cover information about your company, processes, and data that the vendor gains access to — including after the engagement ends.
Ending the engagement. A good contract provides a notice period, the handover of code, documentation, and access, and support while a new team takes over the project. If you’re using the vendor’s licensed product, consider a source code escrow in case the vendor goes out of business.
The pricing model affects how acceptance and payments are written into the contract — we compare both models in fixed price vs. time & materials. You’ll find the broader context for the decision in our guide to custom software.
Disclaimer
This article describes Polish law, is provided for information only, and does not constitute legal advice. Laws and their interpretation can change, and the right clauses depend on the specific project. Before signing a contract for a larger project, have it reviewed by a lawyer specializing in technology law.
Frequently asked questions
Does a contract with a software house have to be in writing?+
What are fields of exploitation?+
Is a license enough instead of a transfer of copyright?+
When does copyright in the code pass to the ordering company?+
Do I need a data processing agreement?+
What about open-source libraries used in the project?+
Have a project in mind?
We’ll help you design and deliver it — from strategy to a finished solution.
