IT & tech disputes: SaaS and software delivery conflicts, outsourcing breakdowns, escrow triggers & IP ownership

This page is for companies in SaaS, outsourcing and software development projects where “it does not work” must be translated into contract obligations and technical proof: acceptance criteria, change requests, SLA breaches, penalties, termination, source code escrow and IP ownership. We start with the contract pack and the technical timeline, then choose the proportional route: escalation notices, negotiation, interim measures for evidence or assets, arbitration or court litigation.

Informațiile sunt generale și nu înlocuiesc consultanța juridică. Contează faptele, actele și cronologia.

When you need this

Your SaaS does not meet the SLA (uptime, performance) and you need a remedy, price adjustment or exit route.
The dispute is about acceptance: UAT, bugs vs “defects”, unclear criteria, disputed sign-off.
Outsourcing delivery failed: delays, staffing instability, handover refusal or incomplete documentation.
Change requests escalated costs and timelines without control, and scope drift became a conflict.
You have an IP conflict: who owns source code, licences, reuse rights, open-source components.
You need to activate or negotiate a source code escrow mechanism (deposit/release triggers).
You must preserve technical evidence (logs, repositories, ticketing) before it is altered or deleted.
Confidentiality or trade secret concerns are present (data, algorithms, know-how, customer lists).

What we do in practice

Contract audit: scope, deliverables, acceptance, SLA, change control, penalties, liability limits, IP, confidentiality, dispute clause.
Timeline build: what was promised, delivered, tested, rejected, reworked and accepted, with dates and references.
Technical evidence organization: logs, repository history, issue trackers, release notes, access records and exports.
Escalation strategy: notices, cure periods, remediation plans, negotiation steps and settlement structure.
Remedy calibration: remediation, price reduction, termination, damages, retention, escrow release steps.
If needed, interim measures planning to preserve evidence or secure assets/receivables.
IP and compliance track: ownership vs licence wording, open-source obligations, trade secret handling and access control.

Documents/information useful for a first review

Document	Why it matters	Notes
Contract + annexes (SOW, SLA, DPA, terms)	Defines obligations, acceptance, remedies and liability	Include change request process and dispute clause
Specs/backlog/user stories and acceptance criteria	Shows what should have been delivered and how to test it	Keep version history and approvals
Project communications (emails, minutes, ticketing)	Fixes promises, delays, approvals and disputes	Export from Jira/Asana, chats, meeting notes
Technical evidence (logs, repo, CI/CD, release notes)	Proves failures, timing and causality	Preserve integrity and access trail
IP/licence documentation (including open-source inventory)	Clarifies ownership and infringement/compliance risk	Dependency list and licence mapping
Escrow agreement (if any)	Defines deposit/release triggers and verification steps	Check update frequency and deposit scope

Risks and common mistakes

Acceptance without objective criteria or without evidentiary sign-off trails.
Uncontrolled change requests that make scope and damages hard to prove.
Failure to preserve technical evidence (logs overwritten, repo rewritten, access revoked).
Unclear IP clauses (assignment vs licence) and no open-source inventory.
Late or incorrect notices (cure periods ignored), weakening the legal position.
Confidentiality treated as formality, without access controls and audit trails.

FAQ

How do I prove a SaaS breach of SLA?

Typically through logs, uptime reports, monitoring outputs, incident tickets and communications, correlated to the SLA definitions and notice timelines. The proof must match the SLA measurement method where the contract specifies one.

Why does acceptance matter so much in a software delivery dispute?

Acceptance often triggers payment, delivery completion and sometimes IP/licence consequences. If acceptance is unclear, the dispute usually turns on documents, technical proof and the parties’ consistent behaviour over time.

Can I terminate if delivery is delayed or defective?

It depends on termination clauses, cure periods, severity thresholds and the evidence trail. We assess whether remediation, price adjustment, partial termination or a structured exit is more defensible.

Who owns the code, and how do open-source components change the picture?

Ownership depends on the contract (assignment vs licence) and the applicable law, while open-source licences can impose obligations that affect distribution and reuse. We review the IP clause and map dependencies to reduce risk.

How does source code escrow work in practice?

Escrow involves depositing code with a neutral holder and releasing it upon defined triggers (for example, provider failure or support discontinuation). Triggers, verification and deposit updates must be handled exactly as written.

Contact

Email: alexandru@maglas.ro | Tel: +40 756 248 777