#Blog

Software Licensing and SaaS Contracts in Nepal — IP Ownership, SLAs & Legal Risks

October 29, 2025 Uncategorized by admin_lawsagar

Table of Contents

Introduction

Software licensing and SaaS contracts are not the same animal. For Nepalese software businesses, the central legal issues are: (1) who owns the intellectual property (IP) — the vendor, the customer, or a third party; (2) whether the arrangement is a license, assignment or a hybrid; (3) how service level agreements (SLA) allocate operational risk (uptime, incident response, credits); (4) data governance and cross-border data issues; and (5) where disputes are resolved and how damages are quantified. This guide explains the legal mechanics, practical contract language you should insist on or avoid, regulatory flags in Nepal (copyright, electronic transactions and privacy), and negotiation tactics that protect both vendors and customers.

1. Foundations: What is a software license and what is a SaaS contract?

A software license traditionally is a contractual grant by the IP owner (licensor) permitting another party (licensee) to use the software under defined conditions (scope, users, territory, duration). Licenses may be perpetual, term-based, exclusive or non-exclusive, and can be coupled with maintenance and support.

A SaaS contract, by contrast, grants access to software hosted by the vendor (provider) over a network — typically on the vendor’s infrastructure or cloud provider — on a subscription basis. The customer consumes functionality but does not receive code or copies of the software in the ordinary course. SaaS contracts combine licensing-like access rights with service delivery promises and data-processing obligations.

In negotiating either, the two issues that repeatedly determine value and risk are IP ownership (who can reuse or sell the code) and service level agreement (SLA) commitments (how reliably the service is provided and what remedies exist when the service fails).

2. IP ownership: why it matters and the common models

Why it matters. IP ownership determines who controls future development, who can re-license, and who benefits from monetisation. It also affects dispute remedies and insolvency outcomes.

Common models:

Vendor retains IP; customer receives license. Standard for SaaS. Customer gets rights to use the service; vendor keeps source code and development rights. For many customers, this is acceptable if the SLA, data portability and exit terms are strong.
Customer owns the deliverables (work-for-hire or assignment). Frequently used for bespoke development or when the customer pays for bespoke modules. Requires clear assignment language and transfer of all necessary moral/economic rights.
Split model (background vs foreground IP). Vendor retains background IP (platform, libraries) while the customer gets ownership or exclusive rights in foreground IP (customizations, add-ons) created specifically for the customer — usually via an assignment or exclusive license.
Escrow or conditional ownership. Source code escrow is common in high-value deployments: vendor retains IP but places source code with an independent escrow agent with release triggers (bankruptcy, prolonged breach, failure to meet SLA). Escrow reduces vendor lock-in risk for customers.

Contract clauses that define ownership

IP assignment clause: must expressly transfer all rights, titles and interests (including moral rights if possible in the jurisdiction) from developer to customer. In Nepal, copyright vests automatically with the author but assignment in writing evidences transfer and is essential for enforcement.
License grant clause: define license type (non-exclusive, revocable/irrevocable), scope (users, modules), territory, and sublicensing rights.
Reservation of rights: vendor’s boilerplate reserving rights in background code must be carefully scoped.
Third-party components: identify open-source or third-party components and include compliance responsibility (vendor vs customer). Failure to disclose OSS or GPL components can create downstream licensing obligations and infection risk.

Practical negotiation points

If you’re the customer and cannot buy assignment, insist on:
- Broad, irrevocable license rights (including right to run, modify, and create derivative works if needed).
- Source code escrow with clear release events.
- Data portability and export formats at termination.
If you’re the vendor, avoid blanket assignment of platform code. Limit assignment to customer-specific customisations and retain the reusable platform code. Use a defined deliverables list.

3. Distinguish license vs assignment vs service delivery

A surprising number of disputes stem from confusion over whether the contract transferred IP or merely granted access. Clause drafting must be precise:

Assignment = transfer of ownership. Use if customer funds bespoke development and wants full control.
Exclusive license = customer gets monopoly rights but original owner remains the titular holder.
Non-exclusive license = vendor can license same software to others.
SaaS access right = often labeled a license but functionally is access: careful drafting should avoid implied transfer of code or ownership unless intended.

In Nepal, copyright protection is automatic on creation but contracts remain central to clarify rights, assignments and moral rights. Always document assignments in writing and record the scope of rights in the contract.

4. Service Level Agreements (SLA) — the operational backbone

An SLA translates operational expectations into measurable KPIs and remedies. Typical SLA components:

Service availability / uptime (e.g., 99.9% monthly uptime).
Response and resolution times for incidents (P1, P2, P3 categorisation).
Mean time to acknowledge (MTTA) and mean time to repair (MTTR).
Performance metrics (API response times, throughput).
Reliability and redundancy commitments (multi-AZ deployments, backups).
Data backup and restore procedures, RTO (recovery time objective) and RPO (recovery point objective).
Security incident reporting timelines and obligations.
Remedies: service credits, termination rights (material breach), limited liability carveouts.
Exclusions (force majeure, customer misconfiguration, scheduled maintenance).

Uptime math example
A 99.9% monthly uptime guarantee allows for up to ~43.2 minutes of downtime per month. A customer buying critical خدمات should push for 99.95% or better, paired with robust incident response.

Remedies: service credits vs termination
Service credits are common but often insufficient for catastrophic failure. Negotiate:

A tiered credit schedule (0.25x monthly fee for 99.0-99.5% uptime; 0.5x for lower).
A termination right if uptime falls below a threshold for two consecutive months or three months in a rolling 12-month period.
Limitations on credits being the sole remedy are negotiable for high-risk systems.

SLA governance

Measurement and reporting: define the monitoring mechanism (vendor’s metrics, third-party monitoring) and dispute resolution for measurement discrepancies.
Change management: procedure for SLA amendments, planned maintenance windows, and customer notifications.

Sources on SLA metrics and best practice are well-established; include uptime, error rates and security metrics in every SaaS agreement.

5. Data protection, privacy and cross-border issues (a Nepalese lens)

Software (and particularly SaaS) frequently processes personally identifiable information (PII). While Nepal currently lacks a single comprehensive data protection statute comparable to GDPR, there are constitutional privacy protections, the Individual Privacy Act and the Electronic Transaction Act which affect data handling. Drafting must therefore be defensive:

Key contractual clauses:

Data processing schedule: define categories of personal data, purpose, processing activities, retention periods, and deletion rules.
Data controller vs processor: specify respective roles and obligations.
Cross-border transfer clause: identify permitted transfer countries and the security safeguards required (e.g., model clauses, standard contractual clauses where appropriate).
Security standard commitments: minimum technical and organisational measures (encryption at rest/in transit, access control, vulnerability testing).
Breach notification: vendor must notify within a short timeframe (e.g., 72 hours) and cooperate with investigation and regulatory requirements.
Sub-processors: vendor must disclose sub-processors and require them to meet equivalent standards.

Because Nepalese data-protection law is evolving and the Electronic Transaction Act recognises electronic records and signatures, prudent contracts use international standards (ISO 27001, SOC2) as benchmarks and build in compliance with future law. For cross-border SaaS used by Nepali customers, ensure local regulatory reporting obligations are understood and accounted for.

6. Open source, third-party libraries and licence contamination

SaaS and software stacks often use open-source components with various licences (MIT, Apache, GPL). Licensing obligations can “infect” proprietary software (e.g., GPL). Contracts should:

Require vendor to provide a software bill of materials (SBOM) listing third-party components and their licenses.
Allocate responsibility for license compliance and indemnities for third-party claims.
Reject “secret” use of restrictive OSS without customer consent.

WIPO and industry guidance stress transparency and disclosure of third-party components in procurements.

7. Warranties, indemnities and liability caps

Warranties typically include: performance (conformance to documentation), non-infringement of third-party IP rights, and security obligations.

Indemnities: customers often require vendors to indemnify against IP infringement claims, costs of defense and damages. Vendors push back, limiting indemnity to direct damages and requiring prompt notification and control over defense.

Liability caps: vendors seek to cap liability to a multiple of fees (e.g., 3× annual fees) or the fees paid in the prior 12 months. Customers should try to carve out exceptions for willful misconduct, gross negligence, or IP indemnity obligations.

In Nepal, civil remedies for IP infringement exist under the Copyright Act and related statutes — contractual clauses should align remedies with statutory rights.

8. Termination, transition & exit management

Customers must negotiate robust exit clauses:

Data return & deletion: upon termination, vendor must export customer data in a usable format and delete residual copies after a grace period.
Transition assistance: vendor provides migration assistance for reasonable fees or included in initial contract for a defined period.
Continuation rights: in some assignments (disaster), customers seek a perpetual right to continue using the last functional version if vendor becomes insolvent.

Escrow (source code and configuration) is a practical safety valve for customers buying critical services. Release triggers should be objective (bankruptcy, failure to cure material breach, prolonged SLA non-performance).

9. Pricing models and commercial structures

Common SAS pricing and contract features:

Subscription pricing (per user/per month, tiered).
Usage-based pricing (API calls, storage).
Overage charges and elastic scaling terms.
Annual renewals with automatic renewal: watch auto-renewal and termination notice periods.
Volume discounts and minimum commitment.

From a legal perspective: define billing cycles, dispute mechanics, late-payment interest, and suspension rights (with clear cure windows). Avoid indefinite auto-renewal traps without customer notice windows. Also ensure price increase mechanics are spelled out.

10. Negotiation checklist — top 12 clauses to negotiate

IP ownership / assignment clause — define foreground/background IP.
License grant & scope — users, modules, geo.
SLA: uptime, MTTR, credits and termination triggers.
Data protection schedule — roles, transfers, breach response.
Source code escrow — agent, triggers, access process.
Third-party components / SBOM — disclosure obligations.
Warranties & indemnities — especially IP indemnity.
Liability cap & exceptions — carve outs for willful misconduct.
Change management — version upgrades and backward compatibility.
Termination & transition assistance — data export and migration terms.
Audit rights — security and compliance audits (frequency, scope).
Governing law & dispute resolution — courts, arbitration, seat and enforcement.

11. Governing law and dispute resolution: Nepal considerations

When parties include cross-border participants, governing law and seat matters. Many SaaS agreements prefer English law or Singapore law with arbitration (SIAC, ICC) for neutral enforcement. For purely Nepal parties, Nepali governing law and Kathmandu courts or Nepalese arbitration may be appropriate.

Practically: ensure chosen dispute-resolution route provides enforceable interim relief (injunctions), and understand enforcement mechanics for foreign awards in Nepal. Nepal is a party to the 1958 New York Convention? (verify for specific enforcement needs). If you will hold IP in Nepal or rely on local court enforcement, ensure local remedies and injunctive relief are available under the Copyright Act and Electronic Transaction Act.

12. Practical drafting samples

a) IP assignment (customer bespoke module):

Subject to payment in full, Vendor hereby assigns to Customer all right, title and interest worldwide in and to the Deliverables created for Customer under this Agreement, including all copyright and moral rights necessary to exploit such Deliverables.

b) SaaS license grant (vendor retains platform):

Vendor grants Customer a non-exclusive, non-transferable, revocable right to access and use the Service during the Term for Customer’s internal business purposes only, subject to permitted Users and usage limits set forth in Schedule A.

c) SLA uptime & remedy:

Vendor warrants 99.9% Monthly Availability. If Monthly Availability falls below the thresholds in Schedule B, Customer shall be entitled to a service credit equal to the percentage of monthly fees set out in Schedule B. Repeated failures for two consecutive months shall entitle Customer to terminate for material breach.

d) Source code escrow:

Vendor shall deposit the source code with Escrow Agent and enter an escrow agreement in form acceptable to Customer. Escrow shall be released to Customer upon Vendor’s insolvency, or Vendor’s material breach not cured within sixty (60) days.

These are starting points — localize language to Nepal legal conventions and translate if you intend to file or rely on statutory protections locally.

13. Implementation checklist for in-house counsel / founders (practical)

Map IP ownership across all vendor contracts (SBOM + license types).
For mission-critical SaaS: insist on SLA 99.95% or stronger, escrow, exit data portability and clear remedies.
Add audit rights for security and compliance (reasonable scope and frequency).
Document third-party code licenses and indemnity coverage.
Build an internal IT recovery plan and map contractual obligations to RTO/RPO.
Review auto-renewal and termination windows annually.

14. Closing notes — legal risk priorities in Nepal

IP protection for software exists under Nepal’s Copyright Act; contract evidence is crucial for commercial certainty.
Electronic Transaction Act supports e-contracting and digital signatures — useful when contracting for SaaS or remote software licensing.
Data protection is evolving — use international best practice clauses now to reduce regulatory risk and prepare for future Nepalese data laws.

FAQs

Q1: Does Nepal law protect software as copyright?
A1: Yes. Software is treated as a literary work under Nepal’s Copyright Act; protection arises automatically upon creation though registration is available as evidence. Contracts should clearly state assignment or licensing terms to avoid disputes.

Q2: If I use SaaS, do I own my data?
A2: Data ownership and processing rights are contractual. Insist on specific data ownership, export and deletion clauses in the SaaS contract.

Q3: Is source code escrow necessary for SaaS?
A3: Not always, but essential for mission-critical systems or where vendor insolvency poses systemic risk. Escrow provides a safety valve allowing customers to maintain operations in a vendor failure.

Q4: How to handle open-source libraries in SaaS?
A4: Require a Software Bill of Materials (SBOM), disclosure of licenses, and vendor indemnity against OSS compliance claims.

Q5: What SLA should startups demand?
A5: For non-critical services, 99.5% may suffice. For customer-facing, revenue-critical systems, aim for 99.95+ with solid incident response times and termination triggers.

Write a comment