B2B agreement with a developer or software house: how to secure rights to the code

Payment for code does not automatically transfer copyright

Ownership of hardware, access to a repository and copyright are separate matters. Paying an invoice or receiving files does not by itself determine whether the customer can modify the program, license it to users, combine it with another product or transfer the rights to an investor.

If the agreement does not expressly provide for an assignment, Polish copyright law generally treats the arrangement as a licence. Its actual scope may be materially narrower than the customer's business model requires.

The employee rule does not automatically apply to B2B contractors

Economic rights to a computer program created by an employee in performing employment duties belong to the employer unless the agreement provides otherwise. That rule should not be assumed to cover an individual B2B developer or an external software house.

A B2B contract needs an express assignment or an appropriately broad licence. Where several people create the code, the chain of title must run from each author to the supplier and then to the customer.

Separate bespoke code from pre-existing components

The agreement should distinguish deliverables created specifically for the customer from tools, libraries, frameworks, modules and know-how that the supplier already owned or uses for several clients. An attempt to acquire the supplier's entire technology stack may be unrealistic, while a broad supplier carve-out may leave the customer without rights to a critical part of the product.

Bespoke code may be assigned. Standard components will often require a licence allowing use, modification, integration, group-company access and continued use by successors and replacement maintenance providers.

The scope should also cover technical documentation, interface designs, tests, data models, deployment scripts and other deliverables needed to develop the system independently.

Assignment or licence?

An assignment makes the customer the owner of economic copyright within the agreed scope. A licence leaves ownership with the supplier but may authorise broad use. The right model depends on whether the software is a core company asset or a standard business tool.

A supplier product used by many customers may not justify a full assignment. A startup building its own platform will usually need rights that do not restrict a funding round, white-labelling, sublicensing or a future company sale.

A licence should address exclusivity, duration, territory, sublicensing and transfer to a successor. Otherwise, statutory default rules may produce a result neither party intended.

Exploitation rights and contractual form matter

An assignment of economic copyright must be made in writing to be valid under Polish law. The same applies to an exclusive licence. An ordinary email, messenger approval or scan may not satisfy this requirement. If the parties sign electronically, the method must meet the required written-form standard.

An assignment or licence covers only the fields of exploitation expressly listed. For software, the agreement should address reproduction, installation, display, storage, modification, translation, integration with other systems and distribution of the program or its copies to the extent required by the product.

The agreement may cover only fields known when it is signed. It is also invalid to the extent that it purports to cover all future works, or all future works of a particular type, by the same author. Deliverables should therefore be linked to the defined engagement.

The software house should demonstrate chain of title

The customer signs with one company, but its employees, B2B contractors and further subcontractors may all create code. A warranty that the software house owns the rights should be supported by an obligation to enter into appropriate agreements with every project contributor.

The contract may require records of authors and subcontractors, evidence of rights if an audit is triggered and protection against third-party claims. The claims procedure, control of settlements and liability caps should remain commercially workable.

Consent to subcontracting should also address whether a subcontractor changes security standards, data-processing locations or the supplier's responsibility.

Open-source and third-party components require control

Most software uses third-party libraries and tools. This is not automatically problematic, but licence terms may affect distribution, notice obligations, source-code disclosure or commercial use.

The agreement should state whether open-source components may be used without approval, identify prohibited licence types and require the supplier to document dependencies and versions. For a material product, an up-to-date component list and information about known vulnerabilities may be appropriate.

Paid libraries, APIs, AI models, training data, stock assets and cloud services should be addressed separately. The customer needs visibility of recurring costs, licence restrictions and the risk of losing access after termination.

Repositories, documentation and accounts should remain accessible

Rights to code are of little use if the only current version is stored in a developer's private account. The agreement should identify the repository, delivery frequency, code-review process and the customer's right to retrieve a complete current version.

The customer should have access to technical documentation, deployment instructions, environment configurations, backups and dependency information. Domain, cloud, app-store and analytics accounts should ideally be created in the customer's name or be readily transferable.

Source-code escrow may be useful for certain critical systems, but ongoing repository and infrastructure access often provides stronger protection than an outdated copy released only after a dispute.

Acceptance, defects and copyright are separate mechanisms

Acceptance should be based on agreed requirements and tests rather than a general statement that the system must work correctly. Blocking, material and minor defects should be distinguished, with appropriate correction periods.

Rights may transfer on creation, acceptance or payment. Each option has different consequences. If transfer occurs only after full payment, the customer needs at least an interim right to use delivered versions during a dispute. If it occurs earlier, the supplier may need another payment protection.

Defect correction under the development agreement should be separated from later maintenance, development and service levels. Otherwise, the parties may disagree over whether a new request is a correction or additional work.

Security, data and AI tools

The contract should define minimum security measures, access management, incident reporting and the treatment of customer data. If the supplier processes personal data on the customer's behalf, data-processing terms may also be required.

The parties should regulate generative-AI tools. Uploading code, data or non-public documentation to an external service may breach confidentiality or security rules. The agreement can require approval of tools, prevent training on customer data and require review of generated code for security and third-party rights.

Termination should allow the project to be transferred

Exit arrangements should cover delivery of current code, documentation, data, keys and credentials, transfer of open tasks and reasonable support for a replacement team. The contract should state which activities are included in the price and which are charged separately.

It should also address data deletion, continuing confidentiality, termination of tool licences and account transfers. On a long project, the parties should periodically test whether the documentation and access would actually allow another team to operate the system.

Gaps in code ownership emerge during due diligence

An investor or buyer will usually examine who created the core software, how the company obtained the rights, which third-party components are used and whether the contracts permit a change of control and continued development.

A missing agreement with an early developer may affect valuation, require additional protections or delay the transaction. The chain of title is much easier to organise at the start than years later, when the original authors are no longer involved.