A small company in Naraina sells billing software to shopkeepers across North India. Within a year, cracked copies are circulating on messaging groups, one distributor is installing a single licence on forty machines, and a customer whose hard disk failed is demanding a free reinstallation the licence never mentioned. At the other end of the market, a hospital buying laboratory software from a foreign vendor is handed a forty-page licence that lets the vendor audit its systems at will and caps the vendor’s liability at the price of one year’s support. Both problems are about the same document. This page explains how to write it, and how to read one before you accept it.
A licence is permission. Without it, doing something that belongs exclusively to someone else is a wrong; with it, the same act is lawful. When you install software, your computer makes copies of it — on the disk, in memory — and copying a computer programme is one of the acts that the Copyright Act reserves to the owner of the copyright. So every lawful use of software rests on some permission from the owner, whether it is written in a formal agreement, shown on a screen at installation, or implied from the circumstances in which the copy was supplied.
An end user licence agreement turns that permission into a clear set of terms. For the licensor, it is how the business model is expressed: how many people may use one purchase, for how long, on how many machines, and what they must pay for more. It is also how the licensor protects its code from being copied, resold or turned into a competing product, and how it limits its exposure if the software fails. For the user, it is the only document that says what was actually bought.
The Copyright Act adds a formal point. A licence of copyright is to be granted in writing by the owner or an authorised agent. Electronic records and electronic acceptance satisfy that requirement in the right conditions, which is why a well-presented click-to-accept licence can work, but it also explains why software owners should not rely on a vague statement on a website that “all use is subject to our terms”.
This page is written for both sides: the Indian software business writing its own licence, and the Indian buyer asked to accept someone else’s.
People speak of “buying” software, and shops and marketplaces describe it that way. Legally, three different things can be involved, and they should not be confused.
| What passes | Example | What the buyer gets |
|---|---|---|
| Ownership of a physical medium | A disc or USB drive in a box | The object itself; not the copyright in what is on it |
| A licence to use a copy | Almost every software purchase, download or app installation | Permission to use on the licence’s terms |
| An assignment of copyright | Custom software built for a client and assigned to it | Ownership of the code itself |
An EULA deals with the middle case. Ownership of the code stays with the licensor, and the licensee receives rights to use a copy. Custom work where the client is meant to own the code is a different transaction, dealt with in our software development agreement guide.
Indian law has, however, treated standard software as a commodity for some purposes. In Tata Consultancy Services v State of Andhra Pradesh (2004), the Supreme Court held that off-the-shelf software sold on media was “goods” for the purposes of sales tax, even though what the buyer really wanted was the programme, not the disc. The decision concerned tax, not copyright, and it does not mean that the buyer owns the copyright; but it is one reason why consumer and sale of goods principles can be relevant to software supplied to the public.
Software businesses often need several documents, and choosing the wrong one leaves gaps.
| Document | Use it when | Main focus |
|---|---|---|
| End user licence agreement | The user runs a copy on its own device or servers | Grant, restrictions, keys, updates, liability |
| SaaS subscription agreement | The provider runs the software and the user accesses it online | Availability, data held by provider, support, exit |
| Website terms | People use a website or online platform | Use of the site, content, platform rules |
| Software development agreement | Software is being built to order | Requirements, acceptance, ownership of new code |
| Privacy policy | Always, if personal data is collected | What data, why, rights, retention |
Hybrid products are common. A mobile app that syncs with the licensor’s cloud needs an EULA for the app and service terms for the cloud; an on-premise product with a subscription for updates needs an EULA and support terms. The documents should cross-refer, use the same definitions and say which prevails in a conflict.
A licence binds only if the user agreed to it, and the way it is presented is the evidence of agreement. There are four common forms:
The principles for presenting terms online and proving acceptance — unticked boxes, terms reachable at the moment of acceptance, logging the version and time — are set out in our website terms guide, and apply equally to installers and apps. Two points are specific to software. First, acceptance should be requested before the software is used, and ideally before payment is taken, so that the user can decline and obtain a refund. Second, where software is installed by an administrator for many users in a business, the licence should say that the administrator accepts on behalf of the business and warrants authority to do so.
The licensor should be the legal entity that owns the copyright or holds the right to sublicense it, named precisely. A common problem in Indian software businesses is that the code was written before the company was formed, by founders or freelancers who never assigned it, so the company licenses software it does not own. That gap should be closed before licences are issued; see our co-founder guide and development guide. Distributors and resellers should either sublicense under a written distribution arrangement or simply pass on the licensor’s own EULA to the end user.
The licensee should be clear too. A consumer licence is personal to the individual. A business licence should name the company and say whether its group companies, contractors and outsourced service providers may use the software on its behalf, which is a frequent source of audit claims in larger organisations.
The licence model is the commercial heart of the EULA. It decides how use is counted and therefore what the licensee must pay for.
| Model | What is counted | Watch for |
|---|---|---|
| Perpetual | A one-time fee for use without time limit, often with paid annual updates | Whether updates and support are included, and for how long |
| Term or subscription | Use for a period, renewed on payment | What happens to the software and data if payment stops |
| Named user | Each identified person who may use it | Whether licences can be reassigned when staff leave |
| Device or node-locked | Each computer on which it is installed | Replacement of failed hardware, virtual machines |
| Concurrent | The number of people using it at the same time | How usage is measured |
| Site or enterprise | All users at a location or in an organisation | Definition of site or organisation, acquisitions |
| Processor, core or server | Computing capacity used to run it | Cloud and virtualised environments |
| OEM or embedded | Units of a device or product that include it | Reporting and royalties |
| Evaluation or trial | Free use for a limited time or with limited features | No production use, no warranty, what happens to data at the end |
| Freemium | Basic features free, advanced features paid | Clear line between free and paid |
The definitions do the work. “User”, “device”, “installation” and “production use” should be defined so that both sides count the same way. Virtualisation deserves particular care: if a device licence is installed in a virtual machine that can move across dozens of physical servers, a strict reading could require a licence for each server. A modern EULA should say how virtual and cloud deployments are counted.
Free software still needs a licence. A free app, a community edition or a public beta is copied and used like any other programme, and without terms the licensor has no clear basis to restrict commercial use, redistribution or misuse. What changes is the balance of the terms.
Warranties can be disclaimed more fully for free and pre-release versions, but a licensor should still not exclude liability for deliberate harm or for hidden functions.
The grant clause is the sentence that gives permission, and every word in it limits or widens what the licensee may do. A well-drafted grant answers these questions:
The purpose limit matters more than people expect. A licence for “internal business purposes” does not allow a licensee to use the software to process data for its own customers as a paid service. A licence for “personal, non-commercial use” does not allow use in a shop or office. Academic and student licences are often priced on that basis, and using them in business is a common audit finding.
The grant should end with a reservation: all rights not expressly granted are reserved by the licensor. That sentence, standard as it is, prevents arguments that a right was granted by implication.
The restrictions clause lists what the licensee may not do. Typical restrictions are:
Restrictions should be written in plain terms and should match the product. A restriction on commercial rental, for example, reflects the copyright owner’s statutory right; a ban on benchmarking may be sensible for enterprise databases and pointless for a photo editing app. Above all, restrictions should be written with the statutory user rights in mind, which is the subject of the next section.
Section 52 of the Copyright Act lists acts that do not infringe copyright. Several are specific to computer programmes, and they are often ignored by EULAs copied from foreign templates. In summary, the following are not infringement:
| Provision | What the lawful possessor of a copy may do |
|---|---|
| Section 52(1)(aa) | Make copies or adaptations in order to use the programme for the purpose for which it was supplied, and make back-up copies purely as temporary protection against loss, destruction or damage |
| Section 52(1)(ab) | Do what is necessary to obtain information essential for making an independently created programme interoperate with other programmes, if that information is not otherwise readily available |
| Section 52(1)(ac) | Observe, study or test the programme’s functioning to determine the ideas and principles underlying it, while doing what is needed for the purpose for which it was supplied |
| Section 52(1)(ad) | Make copies or adaptations from a personally, legally obtained copy for non-commercial personal use |
The exact words of the Act should be checked for any particular case; the table summarises them. The important question for drafting is whether a contract can take these permissions away. The Act says these acts are not infringement; it does not expressly say that a contract cannot forbid them, and Indian courts have not settled the question clearly. A licensor who writes an absolute ban on all copying and all reverse engineering therefore risks two things: a clause that may not be enforced as written, and a licence that looks unreasonable to a consumer commission or court.
The safer drafting is to prohibit reverse engineering “except to the extent that applicable law expressly permits it despite this restriction”, to permit a reasonable number of back-up copies, and, for interoperability, to invite the licensee to ask the licensor for the information it needs before attempting to extract it. For licensees, the table is a reminder that some acts remain lawful even when a licence appears to forbid them — though it is wise to take advice before relying on that against a licensor.
Most commercial software enforces its licence model technically, through licence keys, online activation, hardware binding, dongles or periodic check-ins with a licence server. The EULA should explain these mechanisms honestly, because a user who discovers an undisclosed control feels deceived, and a court or consumer commission may agree.
The clause should say what the user must do to activate the software, whether an internet connection is needed and how often, what data the activation sends, how many activations a key allows, how the user can move a licence to a new device, and what happens if the licensor’s activation service is unavailable. Businesses in areas with unreliable connectivity, and those with secure networks cut off from the internet, should ask for an offline activation method.
Licensors should also plan for their own disappearance. If the licensor shuts down its activation servers, perpetual licensees may find their software unusable. A responsible EULA commits to providing a final unlock or a key that does not need activation if the service is discontinued, or at least to giving long notice.
The Copyright Act protects the technical measures that licensors use. Circumventing an effective technological measure applied to protect copyright, with the intention of infringing, is an offence under Section 65A; removing or altering rights management information without authority is an offence under Section 65B. Separately, Section 63B makes it an offence knowingly to use an infringing copy of a computer programme on a computer. Criminal remedies sit alongside civil ones: an injunction, damages or an account of profits, and delivery up of infringing copies.
For a licensor, the EULA does not create these rights — the Act does — but it supports them. It should prohibit circumvention, state that licence screens and notices are rights management information, and set out what the licensor will do when it detects misuse: suspend the key after notice, offer the user the chance to buy the correct licence, and reserve its legal remedies. Many software businesses find that an offer to regularise, followed if necessary by a copyright infringement notice, recovers more revenue than litigation.
Registration helps enforcement. A copyright registration of the software, and a trade mark for its name, make it easier to act against sellers of cracked copies on marketplaces and to prove ownership quickly. Our copyright infringement notice guide explains the enforcement route in general.
Business licences commonly give the licensor a right to verify that the licensee is using no more than it paid for. For the licensor, audits are the only practical way to enforce per-user and per-device models inside a customer’s network. For licensees, audits can be disruptive and are sometimes used to extract large payments. A balanced audit clause provides:
Licensees should keep their own records of installations, users and keys, ideally through a software asset management tool, and should check how the licensor defines each counted unit before the audit begins. Many audit disputes are really disputes about definitions written years earlier.
Software changes after it is sold, and the EULA should say how. The key questions are:
A published support lifecycle, even a simple one — “each major version receives security updates for at least three years after its release” — is valuable to business buyers, who must plan replacements, and to the licensor, who can stop supporting old versions without argument.
A licence to use software is not a promise to help anyone use it. Support is a separate service, and for business software it is often the larger part of the licensor’s revenue after the first year. The EULA should say whether any support is included — for example, email support for the first year — and point to a separate support or maintenance agreement for anything more.
That agreement should state the channels and hours, the classes of problem and how quickly each is answered, whether remote access to the licensee’s systems is needed and on what conditions, what is excluded, and the annual fee and how it changes. If the licensee wants measurable commitments with a remedy when they are missed, a service level agreement is the right tool. Support fees for perpetual licences are commonly a percentage of the licence price each year; whatever the formula, a buyer should know before signing how the fee can rise.
Software that runs on a user’s device may still send data to its licensor: crash reports, usage statistics, activation details, device identifiers, sometimes documents or files if cloud features are used. Under the Digital Personal Data Protection Act, 2023, where that data is personal data, the licensor needs a lawful basis to process it and must give a proper notice. The EULA is the wrong place to bury this; it should point clearly to a privacy policy that explains it, and the software should ask for consent in the interface where consent is the basis.
Three practical rules follow. Collect no more than is needed, and make optional telemetry genuinely optional. Keep business licensees’ data separate: when software installed in a company processes its employees’ or customers’ data and sends some of it to the licensor, the licensor may be acting as the company’s processor, which calls for the contract terms described in our DPDP guide on processors. And never include hidden functions that collect data the user has not been told about; that is both a privacy breach and a trust breach. Our DPDP compliance review can check a product end to end.
Installed software increasingly includes AI features — writing assistants, image generation, transcription, prediction — some running on the device and some calling a model in the cloud. These features raise questions that older licences never addressed, and the EULA should answer them:
Rules on AI-generated content and deepfakes are developing quickly in India, including through amendments to the intermediary rules, so this part of the licence should be reviewed regularly.
Almost every software product includes components written by others: open source libraries, commercial engines, fonts, maps, codecs. The licensor can pass on only the rights it has. Each third-party component comes with its own licence, and some of those licences require notices to be shown to end users, source code to be offered, or the end user to be allowed to modify or replace the component.
The EULA should therefore say that third-party and open source components are licensed under their own terms, which prevail for those components; it should point to a list of them with their licences, usually in an “about” or “legal notices” screen and in the documentation; and it should not impose restrictions on those components that their licences forbid. Some copyleft licences, for example, do not permit a distributor to prohibit reverse engineering of the component for the purpose of debugging modifications. How to choose and track components during development is explained in our development guide’s open source section; the EULA is where the resulting notices reach the user.
Commercial components need the same care. A licensor that has embedded a paid engine or library under a licence that limits the number of end users, or the territories in which it may be distributed, must make sure its own EULA does not grant more.
Apps distributed through the major app stores sit inside two layers of contract. The developer has agreed to the store’s developer terms, which impose rules on content, payments, privacy disclosures and the relationship with users. The user has agreed to the store’s own terms of service. The app’s EULA must fit within both.
Store practice differs. At least one major store supplies a standard end user licence that applies to apps whose developers do not provide their own, and requires any custom EULA to include certain minimum terms about the store’s own position; others leave the licence entirely to the developer. Store rules change, and the current developer terms should be checked when the EULA is written. The practical points are the same everywhere:
Our app store compliance documents service prepares the full set that stores ask for, including the EULA, privacy policy and data safety answers.
What each store checks at review — data safety forms, privacy labels, sensitive permissions, account deletion, children’s apps and financial apps — is explained step by step in our app store compliance guide.
Many EULAs were written as if every user were a large company with lawyers. When software is licensed to consumers in India, consumer law applies. The Consumer Protection Act, 2019 empowers consumer commissions to declare unfair contract terms void and to act against unfair trade practices, and the Central Consumer Protection Authority has issued guidelines against dark patterns, which include subscription traps and hidden costs. Our SaaS guide on consumers discusses these rules for subscriptions; for a licence, the terms most likely to be attacked are:
A consumer EULA should instead be short, readable and honest: what the user gets, what they may not do, what data is collected, how refunds work, and whom to contact. A refund policy that matches the store’s or website’s actual practice avoids arguments. Business-to-business licences have more freedom, but Indian courts still read exclusion clauses strictly against the party relying on them.
Software used by children raises three separate issues. First, contract: a person under eighteen generally cannot make a binding contract under Indian law, so a licence “accepted” by a child is weak, and purchases should require an adult. Second, data: the DPDP Act requires verifiable consent of a parent or lawful guardian before a child’s personal data is processed, and prohibits tracking, behavioural monitoring and targeted advertising directed at children, subject to exemptions in the rules; see our DPDP guide on children. Third, purchases: in-app purchases in games have led to disputes when children spent large sums, and clear parental controls and purchase confirmations protect both families and developers.
Games need further care. Virtual currencies, items and characters are usually licensed, not owned, and the EULA should say so, along with what happens to them if an account is closed or the game shuts down. Real-money gaming has been subject to major legislative change: Parliament passed the Promotion and Regulation of Online Gaming Act in 2025, which prohibits online money games and their promotion while providing for e-sports and social games. Any game involving stakes, prizes or paid entry should be reviewed against that Act and the rules made under it before launch.
Licensors naturally want to disclaim all warranties, and many EULAs say the software is provided “as is”. For free software and trials, that is reasonable. For paid software, a total disclaimer is commercially unattractive and, for consumers, vulnerable. A balanced paid licence gives a limited warranty:
The remedy is usually a fix, a replacement or a refund of the licence fee, at the licensor’s choice. All other warranties, including fitness for a particular purpose, are then disclaimed to the extent the law allows. The disclaimer should be in plain words and prominently placed. It should also say that the software is not designed for high-risk uses unless it expressly is, so that a general accounting product is not blamed for a failure in an application for which it was never intended.
Liability caps in software licences are usually set at the fees paid for the licence, or the fees paid in the preceding twelve months for term licences, with exclusions for indirect loss, loss of profit and loss of data. Two points deserve thought.
First, loss of data. For software whose purpose is to create and store the user’s records — billing, accounting, clinical records — a total exclusion of data loss can look unreasonable, especially if the loss results from a defective update. A fairer approach is to require the user to keep back-ups, and to limit the licensor’s liability for data loss to the cost of restoring from the latest back-up.
Second, intellectual property. Business licensees will ask the licensor to defend them if a third party claims that the software infringes its rights, and to modify, replace or refund the software if needed. This indemnity is standard in business licences and is often outside the general cap. The licensee, in turn, indemnifies the licensor against claims arising from its misuse of the software or from content it processes with it.
A licence may end when its term expires, when the licensee stops paying, when it commits a material breach and fails to remedy it, or when the licensor discontinues the product under a clause that allows it. The EULA should say, for each case, what the licensee must do and what it keeps:
Remote deactivation on termination is lawful where it is disclosed in the licence, limited to disabling the software, and preceded by notice. Mechanisms that delete a user’s data, or that act without notice, are not; damaging a computer system or data without permission can create liability under the Information Technology Act.
Large organisations do not usually accept a vendor’s standard EULA without change. When an Indian business, hospital, school or government body licenses important software, the points worth negotiating are:
Where the software will be customised for the buyer, the customisation should be covered by a separate development contract, or at least a statement of work, so that ownership of the custom work is clear.
Software, particularly software with strong encryption or security functions, can be subject to export control laws. India controls the export of listed dual-use items, including certain information security technology, under its SCOMET list; the United States controls the export and re-export of many US-origin products and technologies, including software that contains US-origin encryption components, wherever the software is distributed. Sanctions regimes restrict dealings with particular countries and persons.
For most consumer and business applications, these rules create no practical obstacle, but an EULA commonly contains a clause requiring the licensee to comply with export laws and not to use or transfer the software in breach of them. Indian developers building security, cryptography or surveillance-capable products, or selling to defence and government customers abroad, should take specific advice rather than rely on a standard clause.
Supplies of software licences by a registered Indian business are subject to GST, and whether a particular supply is treated as goods or as a service depends on how it is delivered and licensed; the rate and classification should be confirmed with a chartered accountant. Licence prices in the EULA or order form should say whether GST is included.
When an Indian business pays a foreign licensor, questions of reverse charge GST and withholding tax arise. The Supreme Court’s 2021 decision in Engineering Analysis Centre of Excellence on whether end-user licence payments are royalty is discussed in our SaaS guide on foreign providers. Because the Income-tax Act, 2025 has replaced the 1961 Act, older clauses that cite withholding sections by number need updating. We do not give tax advice.
Click-to-accept consumer licences are not usually stamped in practice. A signed enterprise licence is an agreement for stamp law purposes, and stamping it in the state of execution at the modest rate for general agreements allows it to be relied on in evidence without a penalty; in Delhi, this can be done through e-stamp paper.
For online acceptance, proof matters more than stamp. The licensor should keep a record of each version of the EULA, the date each version applied, and, for each user or licence key, which version was accepted and when. If the record is ever produced in court, the rules for electronic evidence apply, including the certificate now required under the Bharatiya Sakshya Adhiniyam; see our guide to the Section 63 certificate.
Licence disputes tend to fall into a few types: piracy and over-use; a licensee’s complaint that the software does not work; arguments about audit findings; and, for enterprise deals, disputes about renewals and price. The EULA can make each of these easier to resolve.
We prepare the licence, the audit letters and the legal notices. Proceedings before an arbitrator, a commission or a court are for your advocate, whose fee is engaged and paid by you directly; we do not quote, collect or share it. You can find an advocate through our directory.
The Naraina company from the top of this page sold its billing software on a one-time “lifetime” price, with a key typed in at installation, and a licence copied years earlier from a foreign product. The licence said nothing about the number of machines, prohibited all copying, and promised nothing about updates.
Its revised EULA chose a clear model: a perpetual licence per device, with one year of updates and support included and an optional annual renewal for both. It allowed each licence to be moved to a replacement computer twice a year through a self-service deactivation screen, and permitted back-up copies of the installer and the data. It explained online activation, offered an offline activation code for shops with poor connectivity, and committed to releasing a permanent unlock if the activation service were ever shut down. Customer data was stated to belong to the customer, with a one-click export to spreadsheet.
For distributors, it issued a separate reseller agreement requiring each installation to use its own key. When the company later found one distributor’s customers running forty copies on one key, it deactivated the shared key after notice, offered each shop a discounted individual licence, and recovered most of the lost revenue without a lawsuit. Its support calls about “lost” licences also fell, because users could now move their own licences.
A multi-speciality hospital in Dwarka chose laboratory information software from a foreign vendor, to be installed on its own servers. The vendor’s standard licence allowed audits at any time, counted every server the software could run on in the hospital’s virtual environment, capped liability at one year’s support fee, excluded all loss of data, and allowed the vendor to end support for any version on thirty days’ notice.
The hospital negotiated. The licence metric became the number of concurrent laboratory users, with disaster recovery and test copies free of charge. Audits were limited to one a year on thirty days’ notice, beginning with a report from the licence tool. The vendor gave a ninety-day performance warranty, an IP indemnity outside the cap, and a commitment to security updates for five years from each major release, with any end-of-life notice given at least twelve months ahead. Data loss caused by a defective update was covered to the extent of the cost of restoring from the hospital’s back-up. The vendor’s remote support access was to be by named engineers, logged, and switched on only when the hospital approved, and the processor terms for patient data were attached as a schedule.
An end user licence agreement from us costs ₹2,999 and is ready in 1 – 3 days. We start from your product — how it is installed, how it is sold, who uses it, what data it collects — and draft a licence that fits it, or review a vendor’s licence you have been asked to accept.
| Included | Why it helps |
|---|---|
| Licence grant and defined licence model | Everyone counts use the same way |
| Restrictions aligned with the Copyright Act user rights | Protection that will hold up |
| Keys, activation, audit and true-up terms | Revenue protection without surprises |
| Updates, support and end-of-life terms | Clear promises after the sale |
| Data, privacy and third-party notices | Honest disclosure, fewer complaints |
| Warranty, liability and termination terms | Balanced risk for consumers and businesses |
If a signed enterprise licence needs stamping, the duty is charged at actual cost, and we tell you the total before we start. GST and withholding questions go to your chartered accountant. Should a licence dispute reach an arbitrator or a court, it is for your advocate, whose fee is engaged and paid by you directly; we do not quote, collect or share it.
A licence that counts use clearly, respects what the law lets users do anyway, and tells users honestly about keys, updates and data protects your revenue and your reputation together. Tell us how your software is installed and sold, and we will prepare the licence — or review the one a vendor has asked you to sign.
Two doors, both free. Clients search a factual directory of enrolled advocates. Advocates apply to be listed on it — no fee, no commission, nothing paid in either direction.
Search Bar Council enrolled advocates by what your matter is about, by court, or by city. Searching and sending a request are both free.
Enrolled advocates anywhere in India can apply to be listed. Your entry is published only after we verify your enrolment number with your State Bar Council.
This directory carries no ratings, no reviews, no rankings and no fees — only the factual particulars the Bar Council of India permits, published at each advocate's own request. Browse the network · Terms for Advocates