Buy or Build? Licensing Versus Custom Software in Romania — A Legal Guide for 2026

Sooner or later, every company with a technology roadmap has the same argument in the same meeting room. Do we buy something that already works, or do we build something that is ours? The CTO wants control, the CFO wants a predictable number, and whoever is responsible for legal usually walks in at the end and is asked to “just check the contract”.

That is the wrong moment. Whether you license an off-the-shelf platform, subscribe to a SaaS product or commission bespoke code from a development house, the choice decides three things that are expensive to undo later: what you actually own, where your data goes, and how easily you can leave.

This guide is written for the people in that room in Romania — CTOs, general counsel, procurement leads and founders. It deals with private commercial projects only; public procurement has its own rules and is not covered here.

Who this guide is for: CTOs, general counsel, procurement leads, founders and in-house counsel in Romania deciding whether to license a product (including SaaS) or commission custom software.

What you will get: a practical legal decision framework, a contract drafting checklist, an overview of regulatory risks and mitigations, and model clause prompts for counsel to adapt with local advice.

Introduction: scope and how to use this guide

There is rarely one right answer to the buy-or-build question. It depends on how fast you need the thing, how close it sits to what makes your business different, whether you need to own the code, and how sensitive the data running through it will be. What follows turns those commercial instincts into legal questions you can actually answer.

Read it as a working checklist rather than front to back. Start with the decision framework, then go to the parts that match your project: IP ownership if you are building, licensing and exit if you are buying, data protection if personal data is anywhere near it (it usually is). Statutory references point to the text in force, and every sample clause is a starting point for discussion, not a finished draft. None of this is legal advice — have local counsel look at your contract before you sign it.

Decision framework: buying or building software in Romania (business and legal checklist)

Before anyone drafts anything, put the project through a filter. The commercial side — cost, speed, control — and the legal side — ownership, regulation, exposure — have to be looked at together. A team that chooses a product because it can be live in six weeks has made a legal decision too, whether or not anyone noticed: it has accepted whatever rights that licence gives, and nothing more.

Quick checklist for CTO and CFO

• Time to market. Off-the-shelf and SaaS products go live fastest. Custom builds take longer, but they fit.
• Cost profile. Licences and subscriptions tend to sit in operating expenditure and are easy to forecast. A build is a larger upfront investment, and change requests have a way of moving the number.
• Total cost of ownership. The price on the proposal is the smallest part of it. Add maintenance, support, integration, migration and, eventually, replacement.
• Competitive differentiation. If the software carries a process or a model that is genuinely yours, owning the code may be the whole point.
• Roadmap control. Buy, and the vendor decides what comes next. Build, and you decide — and you pay to keep it running.
• Internal capability. Be honest about whether you have, or can keep, the people who will maintain this in year four.

Legal decision triggers

Some facts should tip the scales on their own. When any of these is present, the legal analysis stops being a footnote and starts driving the decision.

• Do you need to own the IP? If you must stop competitors using the software, license it onward, or show investors a clean chain of title, you will usually need to commission it under a written assignment. A licence, however generous, does not make you the owner.
• Is personal data involved? GDPR applies whether you buy or build. What changes is who is controller, who is processor, and who answers to the authority when something goes wrong.
• Is the system critical? If an outage would seriously hurt the business, exit rights, source-code access and lock-in stop being negotiable.
• Will data leave the EU? Many SaaS platforms process data outside the EEA. That triggers transfer rules you need to check before you commit, not after.

A simple way to run this is as a sequence of questions: Is time critical? Do we need to own the IP? Is personal data involved, and where will it sit? Can we get out cleanly if we need to? The answers usually point to the right vehicle — licence, subscription or commissioned build — and, just as usefully, to the clauses you cannot give up.

Key legal differences: licensing (buy) versus commissioning (build)

Strip away the commercial language and the difference is simple. When you buy, you acquire a right to use. When you build, you commission a work. That distinction decides what you own, what you are allowed to do with it, and what is left in your hands when the relationship ends.

Licensing models when you buy

A licence gives you exactly what its text says, and not a line more. The grant and its restrictions are the whole deal. The common shapes are:

• Perpetual licences. One fee, indefinite use, with maintenance usually sold separately.
• Subscription and SaaS. Recurring fees for access to software the vendor typically hosts. When the subscription ends, so does your access.
• Usage-based licences. Fees that move with seats, transactions or capacity.

The protection of computer programs is harmonised across the EU by Directive 2009/24/EC, which Romania implements through Law No. 8/1996 on copyright and related rights. One Romanian detail is worth knowing before you read any licence: where a software use contract is silent, art. 76 of the law presumes that the user receives a non-exclusive right of use that it cannot pass on to others. If you need more — affiliates, contractors, a future buyer of your business — the licence has to say so.

For perpetual licences there is also the question of resale. In UsedSoft v Oracle (Case C-128/11), the Court of Justice held that the distribution right in a copy of a program is exhausted where the rightholder authorises its download and grants a right to use it for an unlimited period in return for a fee corresponding to the economic value of the copy. In practice that opened a market for second-hand licences. The Court has kept that reasoning tied to software: in Tom Kabinet (Case C-263/18) it declined to extend it to e-books. And it offers nothing to a SaaS customer, who never receives a copy in the first place.

Commissioning custom development when you build

When you commission software, what you are paying for is a work: source code, object code, documentation and everything around them. Here is the point that surprises clients most often. Paying for that work does not, by itself, make it yours. Under Romanian law the economic rights start with the author, and the commissioning party acquires them only if the contract transfers them — in the form the statute requires. This is the single most important legal difference between buying and building, and it is exactly where weak contracts let their clients down.

IP ownership and assignments in Romania

If you are building, IP ownership is the centre of gravity. Get it wrong and you can pay in full for software you do not own, cannot sell and cannot freely change. The rules are Romanian, set against an EU background.

Copyright basics: Law No. 8/1996 and Directive 2009/24/EC

Copyright in computer programs is governed by Law No. 8/1996, republished in the Official Gazette No. 489 of 14 June 2018. The republication renumbered the articles, and a surprising number of commentaries still cite the old numbers, so check any reference you are given. Computer programs are protected as works under art. 7, and the specific rules for software sit in Chapter IX (art. 73–82).

Protection arises the moment the code is written. There is nothing to register for a bespoke build: the software register kept by the Romanian Copyright Office (ORDA) under art. 17 of Government Ordinance No. 25/2006 concerns programs sold through retail channels, not a system built for one client. Copyright protects the expression of the program — the code — not the ideas, procedures or algorithms behind it.

Commissioned works: assignment versus exclusive licence

Because economic rights begin with the author, a company commissioning software has to acquire them by contract. There is one important exception: under art. 75, economic rights in programs written by employees in the exercise of their duties, or on the employer’s instructions, belong to the employer unless the contract says otherwise. That rule does not reach a freelancer working through a PFA, or an outsourcing agency, or an employee whose duties never covered software. For all of them, nothing passes unless it is assigned.

Romanian law frames the transfer as an assignment (cesiune) of economic rights, which can be exclusive or non-exclusive. In practice the choice looks like this:

• Assignment. The developer transfers the economic rights to you. This is where Romanian formalities bite, and where translated English precedents most often fail. Under art. 42(1), the contract must list the rights transferred and, for each one, the modes of use, the duration and the scope of the assignment — and the author’s remuneration. If any of those is missing, the other side can ask the court to terminate the contract. “For good and valuable consideration” does not do the job. Under art. 43, the assignment can be proved only in writing. If you want full ownership, the assignment should cover source code, object code and documentation, backed by a warranty that the developer actually holds the rights it is assigning.
• Exclusive licence. The developer keeps title and gives you exclusive rights of use. That can meet many commercial goals, but it is weaker than ownership if you plan to license the software onward, sell it, or sue an infringer without asking the developer to join you.

A short sample assignment clause, for discussion only, might read: “The Developer assigns to the Customer the economic rights in the Deliverables listed in Schedule [X], namely the rights of reproduction, distribution, adaptation, translation and communication to the public, for the modes of use set out in Schedule [X], worldwide, for the entire term of protection, including all source code, object code and documentation, in consideration of [RON …] of the Fees, which the parties allocate to this assignment.” Notice what is in it: named rights, modes of use, territory, duration and a remuneration figure. Local counsel should still adapt it to the deal.

Then look at the flow-down, because that is where the chain of title usually breaks. Art. 42(2) makes an assignment of all of an author’s future works absolutely void. Yet the standard master agreement asks every developer to sign exactly that on day one. The workable version assigns per project and per deliverable, with an undertaking to sign confirmatory assignments as the work is produced.

Moral rights and the limits of waiver

Beyond the economic rights, the author keeps moral rights — attribution, integrity of the work and others listed in art. 10. Art. 11(1) is blunt: moral rights cannot be waived or transferred. The software chapter contains no exception to that.

So a contract cannot make moral rights disappear. What it can do is secure practical undertakings about how they are exercised — for example, that individual developers need not be named in the product, and that ordinary maintenance and modification will not be treated as an attack on the integrity of the work. Be realistic about such a covenant: the statute does not guarantee that a court will enforce it, so draft the rest of the contract so that it still holds if the covenant does not.

Contracting essentials for custom development in Romania

Once you decide to build, the contract becomes your main risk-management tool. It allocates ownership, holds scope in place, defines what “done” means and tells you what happens when it is not. These are the clauses no serious commissioned build should go without.

Scope, deliverables and acceptance tests

Acceptance testing is the strongest lever a customer has, because it ties money to proof. Define the deliverables precisely, attach the specification and agree objective acceptance criteria. A workable acceptance regime covers:

• test plans and acceptance criteria agreed before development finishes, so the target does not move;
• a defect classification — critical, major, minor — with different consequences for each;
• clear timeframes for the customer to test and for the developer to fix;
• staged, module-by-module acceptance rather than one big sign-off at the end;
• escalation and rejection rights, and a cap on rework cycles, so the process cannot loop forever.

Tie the final milestone to successful acceptance and the developer stays motivated right up to delivery. And if real or realistic data is used in testing, remember that the developer is processing personal data on your behalf — which means the data processing agreement has to be in place for the test phase, not chased afterwards.

Payment, milestones and change control

Pay against accepted deliverables, not against the calendar. Custom projects almost always change shape along the way, so change control needs discipline: every change described, priced and approved in writing before work starts. A fixed-price envelope for defined scope, or a cap on change orders, helps keep the budget honest.

Warranties, indemnities and limitation of liability

The core warranties are conformity with the specification, non-infringement of third-party IP and, where it fits, fitness for a stated purpose. The IP indemnity matters most: the developer should defend infringement claims and bear the cost of them.

On liability caps, two Romanian rules shape what will actually survive. Art. 1355 of the Civil Code prevents a party from limiting liability for material damage caused intentionally or through gross negligence. And art. 1203 provides that certain clauses in standard terms — limitation of liability among them — take effect only if the other party expressly accepts them in writing. Set the cap so that it does not leave you carrying the full cost of an infringement or a data breach.

Maintenance, updates and SLA

Owning custom software means owning its upkeep. The maintenance contract should define support windows, response and resolution times, update and security-patch obligations, and what happens when service levels are missed. Two points are often forgotten. First, make sure maintenance survives delivery and can be moved to another provider, which is why source-code access matters. Second, updates are no longer purely a commercial matter. The Cyber Resilience Act’s reporting obligations for actively exploited vulnerabilities and severe incidents have applied since 11 September 2026, and the new Product Liability Directive, due for transposition by 9 December 2026, treats software as a product — a missing security update can make it defective. The contract should say who is the manufacturer, who keeps the software bill of materials, and how long security updates will run.

Licensing and SaaS: negotiating vendor lock-in and exit in Romania

On the buy side, the long-term risk is lock-in: becoming so dependent on a vendor’s platform, formats or hosting that leaving is theoretically possible and practically out of the question. Odysseus had himself tied to the mast before he heard the sirens. Exit terms work the same way — they have to be agreed while you still have the will, and the leverage, to insist on them.

Licence scope, sublicensing and source code escrow

Read the grant closely. Who may use the software, for what purposes, and can you extend it to affiliates or contractors? Remember that a silent licence is presumed non-exclusive and non-transferable. For bespoke or business-critical systems, negotiate source-code escrow: the vendor deposits the code with an independent agent, to be released on defined events such as insolvency or an unremedied breach. Insist on verification that the deposited code actually builds, or you may inherit an archive nobody can compile. Test the insolvency trigger in particular — whether a release keyed to the vendor’s insolvency survives the judicial administrator’s powers under Law No. 85/2014 is an open question worth discussing with counsel before you rely on it. Where escrow is not available, open standards or shared IP arrangements can do part of the work.

Exit and transition assistance

Every SaaS or licence agreement needs an exit plan. That means transition assistance, guaranteed export of your data in a usable, non-proprietary format, and reasonable cooperation in moving to the next provider.

For cloud and SaaS services, EU law now does some of this for you. The Data Act has applied since 12 September 2025, and for data processing services it caps the notice period for starting a switch at two months, sets a maximum transitional period of 30 calendar days, and requires at least 30 days afterwards to retrieve your data. Reduced switching charges are allowed only until 12 January 2027; after that date, providers may not charge for switching at all. The rules on switching charges, and some of the interoperability duties, do not apply to a service built mostly around a single customer’s needs and not offered at broad commercial scale, so check how your contract describes the service. Data portability is a commercial protection and, for personal data, a regulatory one too.

Pricing and auto-renewal traps

Watch for automatic renewals, uncapped price increases and notice periods short enough to miss. Negotiate a renewal window you can actually act on, a cap on price rises and clear termination rights. Romanian law helps here too: under art. 1203 of the Civil Code, a tacit renewal clause buried in a vendor’s standard terms takes effect only if you expressly accepted it in writing. That is a useful argument; it is no substitute for a diary reminder.

Data protection and security: GDPR and ANSPDCP considerations

Any software that processes personal data brings GDPR with it, supervised in Romania by the National Supervisory Authority for Personal Data Processing (ANSPDCP). Buying or building changes how those obligations are shared out.

Controller versus processor

With SaaS, the vendor usually acts as your processor — or, for some of its own purposes, as a separate controller. With custom software you host yourself, you generally remain the controller and carry full responsibility for the environment. Settle the roles at the start, because they decide who owes what, and to whom.

Data processing agreements and cross-border transfers

Where a vendor or developer processes personal data on your behalf, a data processing agreement meeting art. 28 GDPR is mandatory. It should bind the processor to your instructions, impose confidentiality and security obligations, list authorised sub-processors and give you audit and assistance rights.

If data goes outside the EEA to a country without an adequacy decision, you need appropriate safeguards — typically the Commission’s Standard Contractual Clauses — together with a transfer risk assessment. For US providers, check whether the recipient is certified under the EU-US Data Privacy Framework. Whichever route you take, build security in from the start and align your technical and organisational measures with GDPR and ANSPDCP guidance.

Tax, grants and R&D incentives: a practical note

Building in-house may qualify for Romanian research-and-development tax incentives, available under specific conditions. Eligibility usually turns on how the activity is classified and on keeping proper documentation from the start. These incentives can change the economics of a build meaningfully, but the rules are detailed and have been amended repeatedly in recent years. Treat this as a flag, not a figure: confirm current eligibility with a tax adviser and the official guidance before it goes into your business case.

Risk matrix and decision checklist: buy or build at a glance

The table below sets the main legal and commercial factors side by side, with the contractual protections that answer each risk.

Practical next steps and contract negotiation tips

Whichever way the analysis points, disciplined execution is what protects the result. Before you sign:

• Do the due diligence. Look at the vendor’s or developer’s financial stability, references and security posture.
• Audit the IP. Confirm the developer owns, or is licensed to use, any pre-existing components, check every open-source licence in the stack, and ask for a software bill of materials.
• Treat the basics as baseline. IP assignment, acceptance testing, IP indemnity, a DPA and exit assistance are starting positions, not favours.
• Use escrow for anything critical. With defined triggers and verification of what is deposited.
• Stage acceptance and payment. Money follows accepted work.
• Look at insurance. Professional indemnity and cyber cover can back up what the contract promises.

Case study and worked example

Take a hypothetical Bucharest fintech that needs a lending-decision engine built around its own risk model. An off-the-shelf platform would be live in weeks. But the company would not own the logic that sets it apart, and sensitive personal and financial data would sit on a vendor’s infrastructure abroad.

So it builds. The development contract assigns the economic rights in the engine — source code and documentation included — naming the rights, the modes of use, the duration, the territory and the part of the fee paid for the assignment. The developer warrants that it can assign, gives an IP infringement indemnity, and undertakes to obtain per-deliverable assignments from each of its own developers rather than a blanket assignment of future works. Acceptance runs module by module against objective criteria, and the final payment is released only when the whole system passes.

Because the fintech will host the data and remain controller, it signs an art. 28 DPA with the developer for any processing during development and testing, and aligns its security measures with GDPR and ANSPDCP guidance. A maintenance SLA with defined response times, a security-update commitment and the source code held in-house keep the system alive if the relationship ends.

Two regulatory questions sit alongside the contract. If the company is a financial entity within the scope of DORA, the mandatory contractual terms for ICT services in art. 30 have applied since 17 January 2025. And if the engine evaluates the creditworthiness of individuals, it is a high-risk AI system under the AI Act; following the Digital Omnibus on AI (Regulation (EU) 2026/1744), those high-risk obligations apply from 2 December 2027. Building the documentation now is far cheaper than reconstructing it later.

The outcome: the fintech owns what makes it different, controls its data and remains free to take the product wherever it wants.

Conclusion: buying or building software in Romania, and when to get legal advice

Buy or build is as much a legal question as a technical one. Buying gives you speed and predictability, but ownership and control stay with the vendor. Building gives you ownership and your own roadmap, but only if the contract gets the assignment, acceptance, warranties and maintenance right. Either way, IP, data protection and exit rights decide your exposure for years to come.

The details that make or break those protections — the elements of a valid assignment, the treatment of future works, the limits on moral-rights covenants, escrow triggers and data transfers — turn on precise drafting under Romanian and EU law. Bring in qualified local counsel before you commit, not after the first dispute. This guide is for general information only and does not constitute legal advice.

Need Legal Advice?

This article was produced by Global Law Experts. For specialist advice on this topic, contact Razvan Alexandru Olaru at Olawru, a member of the Global Law Experts network.

Sources

• Portal Legislativ, Law No. 8/1996 on copyright and related rights, republished (Official Gazette No. 489 of 14 June 2018) — art. 7, 10, 11, 42, 43, 73–82
• Portal Legislativ, Civil Code (Law No. 287/2009) — art. 1203, 1355
• Portal Legislativ, Government Ordinance No. 25/2006 — art. 17
• EUR-Lex, Directive 2009/24/EC on the legal protection of computer programs
• CURIA, Case C-128/11 UsedSoft GmbH v Oracle International Corp
• CURIA, Case C-263/18 Nederlands Uitgeversverbond and Groep Algemene Uitgevers v Tom Kabinet
• EUR-Lex, Regulation (EU) 2016/679 (GDPR)
• EUR-Lex, Regulation (EU) 2023/2854 (Data Act)
• EUR-Lex, Regulation (EU) 2024/2847 (Cyber Resilience Act)
• EUR-Lex, Directive (EU) 2024/2853 on liability for defective products
• EUR-Lex, Regulation (EU) 2022/2554 (DORA)
• EUR-Lex, Regulation (EU) 2026/1744 (Digital Omnibus on AI)
• ORDA, Romanian Copyright Office
• ANSPDCP, Romanian Data Protection Authority
• Monitorul Oficial, Romanian Official Gazette