The application runs and invoices are paid, yet the business discovers it does not control the software: another supplier cannot develop it, source code is missing and support depends on programmers’ goodwill. Legally, this was decided long before launch, in the contract or what it omitted. Three things matter: rights to the work, measurable support and protection if the supplier ends operations.
Who controls software when the contract is silent?
Bespoke development operates as a contract for work (§ 536 et seq. of the Commercial Code), but Copyright Act No. 185/2015 Z. z. determines rights to the result. For software commissioned from its author, it provides a helpful rule.
Unofficial English translation:
The provisions on employee works apply to a computer program, a database under § 131 and a cartographic work created wholly or partly on commission; the commissioning party is treated as the employer, and § 90(9) does not apply. — § 91(4) of Act No. 185/2015 Z. z.
If the individual author directly creates the program under a work contract, the customer normally exercises the economic rights unless otherwise agreed. But bespoke software is usually ordered from a supplier company. Its employees write the code and the supplier exercises their economic rights as employer (§ 90(4)). The customer receives only what the supplier expressly grants. Silence leaves at most a right to use the program for the contract’s purpose. Modification, development by another supplier or selling the application with the business is open to challenge without supplier consent.
Licence, exclusive licence or assignment of exercise of rights
The customer’s position has three levels. A non-exclusive licence permits use, but the supplier may license the same or similar product elsewhere. An exclusive licence excludes that and must be written (§ 65(3)). Agree permitted uses, territory, duration and modification rights; otherwise only the scope necessary for the contract’s purpose applies (§ 66(1)). The strongest option is assignment of the exercise of economic rights (§ 90(5)), putting the customer in control, including granting licences to others. The choice depends on whether the application is core business or merely a supporting tool.
Source code: no entitlement without agreement
Copyright protects source and object code (§ 87(1)) but creates no duty to deliver source code. A lawful user may use the program, including error correction unless otherwise agreed (§ 89(2)), but without code this is a paper right. The contract should require ongoing delivery of current code and documentation to a customer-controlled repository, complete delivery within a short agreed period at termination and a meaningful penalty for breach. Code delivery is often where the relationship breaks down; a penalty makes withholding it a poor business decision.
SLAs: support must be measurable
“We will endeavour to respond promptly” is not a support agreement. A measurable SLA categorises defects by severity, from total outage to cosmetic issues, with separate response and resolution or workaround times for each. Add agreed availability, advance-notified maintenance windows and consequences: service credits or penalties for missed times. Without consequences, an SLA is a marketing table. Confidentiality and data protection usually accompany it; see do I need an NDA?.
Escrow: protection if the supplier fails
Even an honest supplier can become insolvent or close. Source code escrow places code and documentation with an independent third party for release on agreed triggers: insolvency, discontinued support or failure to update code. Regular deposit updates are essential; outdated escrow offers only apparent protection. For smaller projects, ongoing delivery to the customer’s repository serves a similar purpose.
Practical implications
Rights, source code delivery, measurable SLAs and escrow are negotiated before signing. After launch, leverage lies with the supplier. See copyright in commissioned software for different scenarios. We prepare or review software and licence agreements, service agreements with SLAs, IT work and agile development contracts and implementation agreements for third-party systems.
This article provides general legal information as at 5 September 2026. It does not constitute legal services or advice on your specific matter. Laws change and the details of your situation may differ. Check the appropriate course of action or contact us before making a decision.
