By Global Law Experts — Legal · Romania · Technology
A Romanian-law software development agreement stands or falls on three decisions made at the drafting stage: who owns the code, how deliverables are accepted, and how each party is protected against non-performance or non-payment. As custom builds and generative-AI development accelerate through 2026, these questions are no longer boilerplate, they determine whether a client actually receives usable, assignable intellectual property and whether a supplier is paid on time. They are also no longer the only questions: between September 2025 and December 2026 four EU instruments — the Data Act, the Cyber Resilience Act, the amended AI Act timetable and the new Product Liability Directive — moved obligations into the space these contracts occupy. This guide sets out the Romanian legal framework, the practical contract options, and copy-ready clause structures for founders, CTOs, procurement leads and in-house counsel negotiating Romania-governed custom software contracts.
Everything below is written for decision-makers who need positions they can defend at the negotiating table, grounded in Romanian copyright law, the Civil Code and EU harmonisation rules. Where Romanian law imposes a formal requirement that an English-language precedent will not satisfy, the article gives the article number.
Two forces have made contracting discipline more important than ever. The first is the rise of generative-AI and machine-learning builds, where deliverables are assembled from a mix of bespoke code, third-party models, open-source components and training data. Ownership boundaries blur quickly when a supplier fine-tunes an external model or embeds AI-generated code, and a poorly drafted contract leaves the client uncertain about what it can actually commercialise, license onward or protect against infringement claims. The AI Act adds a second layer to the same facts: the contract now has to say which party is provider and which is deployer, who holds the technical documentation, and how the upstream terms of a general-purpose model flow through to the client.
The second is procurement pressure. Both public bodies and private enterprises are running larger, more complex tenders, and buyers increasingly demand payment security, defined acceptance gates and enforceable performance guarantees before releasing funds. The projects most exposed to disputes tend to be those where IP assignment, acceptance criteria and payment triggers were left vague. A well-structured contract addresses all three before the first line of code is written.
There is now a third force, and it is the one most 2026 contracts have not caught up with: compliance obligations that attach to the software itself rather than to the transaction. Since 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents under the Cyber Resilience Act, with an early warning inside 24 hours and a notification inside 72. From 9 December 2026, once Directive (EU) 2024/2853 is transposed, software is a product for liability purposes and a missing security update can be a defect. Neither obligation is self-executing between supplier and client. Somebody has to be named as manufacturer, somebody has to deliver the bill of materials, and somebody has to answer the phone inside the 24-hour window.
Any contract sits on top of two statutory pillars, Romanian copyright law and the Civil Code, and is informed by EU harmonisation. Understanding how each operates prevents drafting mistakes that no amount of commercial goodwill can later cure.
Under Legea nr. 8/1996 privind dreptul de autor și drepturile conexe (the Romanian Copyright Law), computer programs are protected as literary works (art. 7 lit. a), with the specific regime for computer programs in Chapter IX, art. 72 and following). Protection arises automatically on creation, without any registration formality. This has an immediate practical consequence: in the absence of an express contractual transfer, the individual author, or their employer in some employment scenarios, holds the copyright. A client who commissions and pays for a bespoke build does not, by that fact alone, own the resulting code. Ownership must be transferred by an express, written contractual mechanism.
Automatic protection is not the same as no formalities at all. Under Ordonanța nr. 25/2006, economic operators that produce, import, rent, distribute or commercialise computer programs on Romanian territory must register those programs with the Romanian Copyright Office (ORDA) in the Registrul Național al Programelor pentru Calculator before they are placed into commercial circulation, on pain of administrative fines. It is a compliance step, not a protection measure, and it is routinely missed by foreign buyers of Romanian builds. Allocate it expressly in the contract.
The statute distinguishes between economic rights (the rights to reproduce, distribute, adapt and communicate the work) and moral rights. Economic rights (patrimonial rights) can be assigned or licensed. Moral rights, including the right of paternity (attribution) and the right to the integrity of the work, are treated as personal to the author, and the law restricts their transfer, treating the core of these rights as generally inalienable. This distinction is central to every assignment negotiation, because it defines the outer limit of what a supplier can validly promise to hand over.
Note also that, in the specific case of computer programs created by an employee in the exercise of their duties, art. 74 provides that the patrimonial rights belong to the employer unless the contract provides otherwise. Two limits on that presumption are worth stating to any client relying on it. It reaches programs written in the exercise of the employee’s duties or on the employer’s instructions, so a job description that never mentions software weakens it; and it is a default rule, which a legacy clause in the employment contract can reverse.
The Codul civil (Legea nr. 287/2009) governs how the agreement is formed, interpreted and enforced. It supplies the default rules on obligations, performance, assignment of contractual rights, remedies for breach, and limitation periods. When your contract is silent, the Civil Code fills the gap, and its defaults are rarely optimised for a complex software project. That is precisely why detailed acceptance, warranty, liability and payment provisions are worth drafting: they displace generic statutory defaults with commercially calibrated terms.
Two provisions deserve to be known by name before the liability section is negotiated. Art. 1355 C. civ. voids any clause excluding or limiting liability for material damage caused intentionally or through gross negligence, while expressly permitting clauses that exclude liability for damage caused to property by simple imprudence or negligence. Art. 1203 C. civ. provides that unusual clauses in standard terms — limitation of liability among them — take effect only if expressly accepted in writing by the other party. In a business-to-business software contract these are the levers that matter; consumer legislation is not.
Directive 2009/24/EC of the European Parliament and of the Council harmonises the legal protection of computer programs across the EU, confirming that programs are protected as literary works and setting common rules on authorship, restricted acts and permitted exceptions such as decompilation for interoperability. For cross-border builds, a Romanian supplier serving an EU client, or a Romanian buyer engaging developers in another member state, the directive provides a shared interpretive baseline that reduces the risk of divergent national outcomes. It reinforces, rather than replaces, the domestic framework in Legea nr. 8/1996.
Directive 2009/24/EC is, however, seventeen years old and settles only the copyright question. The EU layer that has actually changed the drafting is more recent, and four dates carry it:
12 September 2025 — the Data Act (Regulation (EU) 2023/2854) applies. Where the deliverable is provided as a data processing service, switching and egress duties attach, and Chapter IV introduces a genuine business-to-business unfair-terms regime over unilaterally imposed clauses, including on liability and termination.
11 September 2026 — reporting obligations under the Cyber Resilience Act (Regulation (EU) 2024/2847) begin, covering products already on the market as well as new ones. The Act’s main obligations follow on 11 December 2027.
2 December 2026 — the AI Act obligation to mark AI-generated output under art. 50(2) applies, following the Digital Omnibus on AI. That instrument deferred the Annex III high-risk obligations to 2 December 2027 and the Annex I obligations to 2 August 2028; transparency and general-purpose AI duties were not deferred.
9 December 2026 — the transposition deadline for the new Product Liability Directive (EU) 2024/2853, which treats software as a product and applies to products placed on the market after that date.
Where the client is an entity in scope of NIS2, supply-chain security requirements descend into the development contract through the client’s own obligations; where the client is a financial entity, the mandatory contractual content in art. 30 DORA has applied since 17 January 2025.
This is the question clients ask first and the one most often mishandled. Because copyright vests in the author by default, the client must actively acquire rights. There are four principal contractual models, and the right choice depends on how the client intends to use, resell and protect the software.
Full assignment of economic rights. The supplier assigns to the client, in writing, all transferable economic rights in the bespoke deliverables. This is the recommended default for commissioned, commercially significant builds where the client needs to own, license, modify and sublicense freely. Under Legea nr. 8/1996 the assignment must specify, for each right transferred, the modes of use, the duration and the scope of the assignment — and the remuneration of the rightholder. Art. 41(1) makes the absence of any one of those elements a ground for the interested party to seek termination of the contract, which is why “for good and valuable consideration” is not a safe import here.
Exclusive licence back to the client. The supplier retains title but grants the client an exclusive, perpetual, worldwide, sublicensable licence. This is a fallback where a supplier resists assignment, for example, a product vendor building on a proprietary framework, but it is weaker than ownership and complicates enforcement against third-party infringers.
Work-for-hire model and its limits. Anglo-American “work made for hire” concepts do not map cleanly onto Romanian law. Where an employee creates software in the course of employment, the employer’s rights arise under art. 74, but for independent contractors ownership does not automatically pass to the commissioning party. Relying on an imported “work-for-hire” label without an express Romanian-law assignment is a common and serious error.
Hybrid model. The supplier assigns the bespoke foreground deliverables while licensing pre-existing background IP and open-source components. Most real-world builds use this structure, because no non-trivial project is written entirely from scratch.
|
Feature |
Full assignment of economic rights |
Exclusive licence back |
|
Who holds title |
Client |
Supplier |
|
Right to modify and sublicense |
Unrestricted (client controls) |
Per licence terms; can be broad but derivative |
|
Standing to sue infringers |
Client, directly |
Often requires supplier cooperation |
|
Suitability for resale / M&A |
Strong, clean chain of title |
Requires diligence and consents |
|
Typical use case |
Bespoke commercial builds |
Product-based or framework-dependent builds |
|
Statutory formality |
Art. 41(1) elements, remuneration included; writing needed to prove the assignment |
Written licence with defined scope |
Clear definitions do most of the heavy lifting in a contract. Distinguish:
Deliverables. The specified outputs the supplier must produce and hand over, source code, object code, documentation, configuration and, where relevant, trained model artefacts.
Background IP. Pre-existing materials the supplier brings to the project (libraries, frameworks, internal tooling). These are typically licensed, not assigned, and the licence must be broad enough for the client to use and maintain the deliverables indefinitely.
Foreground IP. IP created specifically in the course of the project. This is what the client should acquire by assignment.
A sample assignment clause, for discussion only, might read: “The Supplier hereby assigns to the Client, to the maximum extent permitted by Legea nr. 8/1996, all economic rights of any kind in the Foreground IP and the Deliverables, worldwide and for the entire duration of protection, together with the right to modify, adapt and sublicense.” Drafted that way it satisfies scope and duration and satisfies neither remuneration nor modes of use. A version that engages with art. 41(1) reads closer to: “The Supplier assigns to the Client the economic rights in the Foreground IP and the Deliverables listed in Schedule [X], namely the rights of reproduction, distribution, adaptation, translation and communication to the public, for all modes of use set out in Schedule [X], for the entire term of protection, worldwide, in consideration of [RON …] of the Fees, which the parties allocate to this assignment.” Pair this with a positive obligation on the supplier to procure equivalent assignments from every individual developer and subcontractor, the single most overlooked step in Romanian software contracting.
Draft that flow-down with care. Art. 41(2) strikes with absolute nullity the assignment of the economic rights over the totality of an author’s future works, whether named or unnamed — which is precisely the shape of the blanket forward assignment most master agreements ask a developer to sign on day one. The workable structure is a per-project, per-deliverable assignment, supported by a contractual undertaking to execute confirmatory assignments as each deliverable is produced.
Because the core of moral rights under Legea nr. 8/1996 is generally inalienable, a supplier cannot validly promise to extinguish them. What is achievable is a practical arrangement: the author may agree not to exercise certain moral rights in ways that would disrupt normal commercial use, for example, agreeing that the client need not name individual developers in the product, or that reasonable modifications to the software will not be treated as violations of the right of integrity. Draft these as covenants regarding the manner of exercise rather than as outright assignments, because an assignment of the core moral right itself would be unenforceable. Check the covenant against Chapter IX before it is signed: the regime the statute applies to computer programs is not identical to the general regime, and the drafting should track the specific provisions rather than the general ones.
Where the client’s own staff contribute code alongside the supplier’s team, ownership can become jointly held unless the contract allocates it clearly. Specify in advance who owns jointly developed foreground IP, whether either party can exploit it independently, and how contributions are recorded. In AI-augmented builds, address who owns fine-tuned model weights, prompt libraries and generated code separately from conventional source code. In the same clause, settle the AI Act positions the ownership question hides: which party is the provider and which the deployer of any AI system in or around the deliverable, who compiles and retains the technical documentation, and what happens to the allocation if the client later puts its own name on the system.
Almost every build integrates open-source software (OSS). Each OSS licence carries obligations, attribution, source disclosure for copyleft licences, or restrictions on combination with proprietary code. Require the supplier to maintain a complete bill of materials listing every OSS component and its licence, and to warrant that no component’s licence conflicts with the client’s intended commercial use. Copyleft components inadvertently linked into proprietary deliverables can compromise the client’s ability to keep the codebase closed, so this warranty is not a formality.
That bill of materials now has a second job. The Cyber Resilience Act expects manufacturers of products with digital elements to know and document their components, so the OSS schedule and the software bill of materials should be drafted as one deliverable, updated on each release, and tied to the security update support period the parties agree.
Acceptance is where payment obligations and quality expectations meet. A vague “the client shall accept the software when satisfied” clause invites dispute; a well-drafted acceptance regime creates objective, testable gates. In any serious contract, acceptance testing deserves its own detailed schedule.
Distinguish functional criteria (does the software do what the specification says?) from non-functional criteria (performance under load, security, availability, accessibility). Both should be expressed as measurable, testable statements tied to the agreed specification. The more objective the criteria, the less room there is for a supplier to claim acceptance by conduct or for a client to reject arbitrarily to delay payment.
Specify:
Test data deserves its own line. Where production or production-like data is used for testing, the supplier is almost always processing personal data on the client’s behalf, which makes a data processing agreement under art. 28 GDPR a condition of the test phase rather than an annex somebody chases afterwards. The cleaner position is to require synthetic or pseudonymised test data and to say so in the acceptance schedule.
Build a defect severity matrix, critical, major, minor, cosmetic, with different consequences for each. Critical and major defects justify rejection; minor and cosmetic defects should not block acceptance but should be logged for remediation. Define the rejection-and-rework cycle: the supplier fixes the defects within a stated cure period, resubmits, and the client re-tests against the same criteria. Cap the number of cycles so the process cannot loop indefinitely.
Remedies on persistent failure should escalate. Typical constructs include:
For higher-risk builds, place the source code into escrow during the acceptance phase, so that even if the supplier fails or becomes insolvent mid-process, the client can obtain the code needed to complete or maintain the work. A sample acceptance sign-off should be a short formal document recording the deliverable accepted, the test results, any waived minor defects and the date, because the acceptance date typically triggers warranty periods and milestone payments.
Payment security protects both sides: the client wants assurance that money is released only against delivered, accepted work, and the supplier wants certainty of payment for work performed. A mature contract combines a milestone payment schedule with one or more security instruments.
Structure the fee around defined milestones, each tied to an acceptance gate rather than to elapsed time. A typical schedule releases a modest mobilisation payment on signature, staged payments on acceptance of defined deliverables, and a final payment on overall acceptance. Retention, holding back a percentage of each milestone until final acceptance or the end of a warranty period, gives the client leverage to secure defect remediation without resorting to litigation. Define invoicing mechanics, payment terms and the precise link between acceptance sign-off and the right to invoice.
Escrow places a copy of the source code, build instructions and documentation with an independent agent, to be released to the client on defined trigger events, typically supplier insolvency, cessation of business, or persistent failure to provide agreed support. Escrow instructions must specify the deposit obligations (including a duty to update the deposit as the code evolves), the release triggers, the release mechanics, and any obligation to verify that the deposited materials actually build. Escrow is widely used in Romania and is particularly valuable for mission-critical or long-lived software, but it rests on general contract law rather than on any dedicated statutory regime. Test the insolvency trigger before promising a client that the fallback works: a release keyed to the supplier’s insolvency has to survive the judicial administrator’s powers over ongoing contracts under Legea nr. 85/2014, and that is precisely the moment the client will be relying on it.
A performance bond or bank guarantee is a bank’s independent undertaking to pay the beneficiary a stated sum if the counterparty fails to perform. These instruments are commonly used and enforceable in Romania when drafted properly, and they are standard in public procurement. The critical drafting point is the call condition: specify exactly what documents the beneficiary must present to trigger payment, and whether the guarantee is on-demand or conditional. In public procurement the shape of the instrument is fixed rather than negotiable. Art. 154 of Legea nr. 98/2016 caps the performance security at 10% of the contract price without VAT, requires it to be constituted within five working days of signature, and allows it to be constituted by bank transfer or by an instrument issued in accordance with the law by a credit institution or by an insurance company, which then becomes an annex to the contract; the mechanics sit in HG nr. 395/2016. An insurer-issued instrument is a surety product written under ASF supervision, and whether it is drafted as an autonomous, on-demand undertaking or as an accessory guarantee decides how the call actually behaves. Beneficiaries in Romania lose calls on the documents clause far more often than on the merits, so draft the call condition with the same care as the amount, and align the wording with the applicable regime and with ANAP guidance before the tender goes out.
Where a supplier is a thinly capitalised subsidiary, a parent company guarantee gives the client recourse against a stronger balance sheet. For international suppliers or cross-currency deals, a letter of credit provides bank-backed payment assurance, though it involves more banking formality. Choose the instrument that matches the counterparty risk and the transaction’s value and cross-border character.
|
Instrument |
Enforceability in Romania |
Typical cost & setup time |
Best for |
|
Source-code escrow |
Contractual; no dedicated statutory regime — test the insolvency trigger |
Moderate cost; medium setup |
Client wanting a fallback if the supplier fails or becomes insolvent |
|
Bank guarantee / performance bond |
Commonly used; in public procurement, art. 154 L. 98/2016 and HG 395/2016 apply |
Bank fee (rate varies by bank and risk); quick to call if trigger documents are in place |
Public procurement and high-value private projects |
|
Insurer-issued surety instrument |
Accepted in public procurement alongside bank instruments; ASF-supervised issuer |
Premium-based; often faster to obtain than a bank line |
Suppliers without spare bank credit lines |
|
Retention / holdback |
Simple contractual device |
Low cost; immediate |
Smaller projects or final-acceptance risk |
|
Escrow combined with milestone payments |
Combines protections; contractually enforceable |
Higher cost |
Complex or AI-enabled builds with IP concerns |
|
Letter of credit |
Enforceable but more banking formalities |
Moderate to high cost; fast payment enforcement |
International suppliers and multi-currency deals |
Risk allocation is where sophisticated parties earn their fees. The Civil Code supplies default rules on liability and remedies, but commercial parties routinely tailor these to the realities of software.
Conventional practice is to grant a defect-warranty period running from acceptance, during which the supplier must correct defects at its own cost. Align the warranty period with the acceptance cycle so that latent defects surfacing shortly after go-live remain the supplier’s responsibility. Distinguish the warranty (a fix obligation) from any separate paid support and maintenance arrangement, which usually operates as a distinct service with its own service levels. From December 2026 the warranty conversation acquires a neighbour: under the new Product Liability Directive a failure to supply security updates can render a product defective, so the support period and the update commitment are no longer purely commercial variables.
The most common construct caps aggregate liability at a multiple of the fees paid, for example, total contract value, or fees paid in the twelve months preceding the claim. The cap is a negotiation point: clients push for a higher multiple, suppliers for a lower one. Note that under art. 1355 C. civ. a contractual limitation of liability will not shield a party in cases of intent (dol) or gross negligence where material damage is concerned, although the same article expressly validates clauses excluding liability for damage caused to property by simple imprudence or negligence, and that a cap sitting in standard terms engages art. 1203 C. civ., under which unusual clauses — limitation of liability among them — take effect only if expressly accepted in writing. Consumer legislation is not the reference point in a business-to-business build; where the deliverable is a data processing service, Chapter IV of the Data Act supplies a further, genuinely B2B, unfair-terms control over unilaterally imposed liability and termination clauses. Whatever level is agreed, carve out the categories where a cap is inappropriate:
Parties commonly exclude indirect and consequential losses, lost profits, lost business, loss of anticipated savings, so that the supplier’s exposure is bounded and quantifiable, subject to the statutory limits above. A sample cap clause, for discussion only: “Save for the Excluded Matters, each party’s aggregate liability arising under or in connection with this Agreement shall not exceed [the total fees payable under this Agreement / the fees paid in the twelve months preceding the event giving rise to the claim].” Pair this with a defined IP indemnity requiring the supplier to defend and settle infringement claims and to procure a right to continue use, replace the infringing component, or refund.
Bring the pieces together into a single, reviewable checklist. Every contract should address each of the following, and each item below corresponds to a drafting decision made earlier in this guide (all sample clauses are for discussion only and are not legal advice):
Common red flags to watch for: an imported “work-for-hire” label with no Romanian-law assignment; an assignment clause with no remuneration element; a developer flow-down drafted as a blanket assignment of future works; acceptance defined by client satisfaction rather than objective criteria; a performance bond whose call conditions are impractical to satisfy; and a liability cap that swallows the IP indemnity. Each of these routinely surfaces in disputes.
A well-drafted contract turns three high-risk questions into settled positions: the client acquires clean, assignable IP through a written assignment that flows down to every contributor; deliverables pass through an objective, testable acceptance regime with proportionate remedies; and payment is secured through milestones, retention and the right combination of escrow, guarantees or bonds. Ground each of these on the correct statutory footing, Legea nr. 8/1996 for copyright and moral rights, the Civil Code for contract mechanics, and Directive 2009/24/EC for cross-border harmonisation, and the agreement will hold up when a project runs into trouble.
What has changed is that those three questions are no longer the whole brief. A contract signed in late 2026 also has to say who reports a vulnerability inside 24 hours, who is the manufacturer for the purposes of the Cyber Resilience Act, who bears the consequences when software is treated as a product under the new liability regime, and which party carries the AI Act roles. None of that fits in a boilerplate schedule.
As AI-augmented builds and demanding procurement processes define the market through 2026, the parties that draft with this discipline will be the ones who avoid disputes, protect their commercial position, and complete their projects on terms they can rely on.
This article is general information about the law in Romania as at the last update and is not legal advice. Sample clauses are provided for discussion only. Seek qualified counsel for any specific software development agreement.
This article was produced by Global Law Experts. For specialist advice on this topic, contact Razvan Alexandru Olaru at olawru.com, a member of the Global Law Experts network.
posted 18 minutes ago
posted 1 hour ago
posted 2 hours ago
posted 2 hours ago
posted 3 hours ago
posted 3 hours ago
posted 3 hours ago
posted 4 hours ago
posted 4 hours ago
posted 5 hours ago
posted 5 hours ago
posted 6 hours ago
Find the right Legal Expert for your business
Send welcome message