Payment alone does not decide who holds the rights
An invoice for an “additional module” is no substitute for an agreement on software rights. The customer may be paying to bring forward a product improvement, configure the service for its needs or commission a solution in which it will receive specified rights. Each arrangement calls for different terms.
I therefore start with the agreement as a whole: the main contract, the order, the accepted proposal, the specification and the correspondence. Interpreting a contract also involves the circumstances in which it was made, the parties' common intention and the purpose of their arrangement. The document's title is not enough.
That does not mean correspondence will always transfer rights effectively. Under Polish law, an assignment of economic copyright and an exclusive licence require written form to be valid. Article 65 of the Polish Copyright Act provides for a licence where there is no express provision assigning copyright. A licence that does not reserve exclusivity is non-exclusive. These rules do not, however, mean that other agreed restrictions cease to bind you.
Copyright protects code, not functionality itself
Copyright can protect an original, individual expression of a computer program, including its code. A program's functionality, ideas and underlying principles are not, as such, protected by copyright. The distinction matters when a customer assumes that funding a feature gives it exclusivity over every way of achieving the same result.
This is not permission to copy someone else's code or disregard your contract. Rights in a particular implementation and a promise not to offer similar functionality to others are separate questions.
How the issue appears in practice
Hypothetical example.
A customer funds an integration between your SaaS and a popular accounting system. From the outset, the order states that the customer is paying for earlier delivery, you retain the rights to the new code, and you may offer the integration to others without sharing the customer's data, individual settings or confidential accounting workflows. When a second customer asks for it, you can offer the integration within those agreed limits. Had you instead promised not to offer that functionality to others, simply writing new code would not be enough to get around the restriction.
Separate the new module from your existing SaaS
Before agreeing on rights, identify what the order will actually produce. The new feature may rely on an existing login system, data model, libraries and processing mechanisms. Those elements do not automatically become customer-specific deliverables simply because the module needs them to work.
I suggest distinguishing the existing product, new code developed under the order, changes shared across the SaaS and materials supplied by the customer. The specification should make those boundaries identifiable even after later updates. A broad reference to “all deliverables” will rarely explain how to treat a product that continues to evolve alongside the commissioned work.
Check dependencies on third-party libraries and systems as well. You can only promise rights that you are entitled to grant. If you assign rights in the module, you need an appropriate legal basis to keep using it as required to provide and maintain the SaaS. Your maintenance obligation should not leave that permission unresolved.
Rights to code and commercial exclusivity are different arrangements
An assignment of economic copyright concerns an identified work and the fields of exploitation expressly specified in the contract. An exclusive licence does not transfer copyright, but reserves exclusive use within its agreed scope. You also need to establish which rights you retain as the provider.
Separately, you may promise not to offer similar functionality to other customers for a specified period. That restriction can reach beyond copyright protection for the particular code. Writing a different implementation will not automatically resolve the issue.
A statement that “rights remain with the provider” is therefore insufficient if another provision prevents you from selling similar solutions. Conversely, assigning rights in specific code does not, by itself, give the customer exclusivity over every feature that performs the same function. The validity and effect of restrictions require an assessment of the particular contract, including the legal limits on freedom of contract.
Define exclusivity before you price it
First establish what the customer wants to prevent. Is it the availability of a specific module, similar functionality or a solution that uses its confidential requirements? Without a clear definition, the word “similar” may cover much more than you allowed for in your quotation.
Then identify the customers and market covered by the restriction. Exclusivity for one company does not necessarily mean protection for its entire corporate group. A promise not to offer the feature to “competitors” needs a workable way of identifying them and addressing changes in the customer's business. The sector and territory may matter too.
The cost of programming does not capture the cost of forgoing future orders. Consider the expense of maintaining a separate version, additional testing and restrictions on further development as well.
Ending the subscription may not end exclusivity
Agree when the restriction begins and ends, and how it relates to the subscription. Do not assume that ending a subscription automatically releases you from every obligation arising from the development order. Equally, the expiry of commercial exclusivity does not, by itself, transfer previously assigned copyright back to you.
Address existing customers and earlier product versions separately. Can you continue providing their service, fixing bugs and delivering updates? Does the restriction affect new deployments or also improvements to existing ones? The answers should reflect what you can realistically maintain from a technical perspective.
Also agree how the customer's module will be maintained and who will pay for changes required by the system it integrates with. A one-off development fee does not explain who will be responsible for future work and its costs. Those arrangements need to be consistent with the agreed rights and the duration of exclusivity.
Reuse also requires a confidentiality review
Even if you retain rights to the code and grant no exclusivity, check what information you are using. Customer data, non-public processes, accounting rules and documentation may be covered by confidentiality obligations. Not every piece of information is a trade secret: relevant factors include its economic value, its non-public nature and the steps taken to keep it confidential.
A contract can also protect information that does not meet every statutory requirement for a trade secret. I therefore do not treat a general reservation of the right to use “knowledge and experience” as permission to reuse customer materials without restriction.
When developing the feature for other customers, distinguish a general technical solution from protected third-party materials and confidential information. Rewriting the code is not enough if you still use information in breach of restrictions that bind you.
Legal basis
- Polish Act on Copyright and Related Rights: Article 1(2¹), Article 41(2), Article 53, Article 65, Article 67(2) and (5), and Article 74(2) and (4).
- Polish Civil Code: Articles 65 and 353¹.
- Polish Act on Combating Unfair Competition: Article 11.
This article provides general information and does not constitute legal advice for a specific matter. The appropriate solution depends on the facts, documents and business objective.
Summary
Whether you can offer a commissioned feature to other customers depends on the rights in the particular solution, your contractual commitments and restrictions on information. An invoice alone does not answer the question. Before accepting the order, establish what the customer is funding, which rights it will receive and precisely how any exclusivity will work.