EULA, SaaS Agreement, and Software License: What Rights Does the Client Receive
The client paid for a corporate subscription to a SaaS service, provided access to employees within its corporate group, and connected an external contractor. The provider considered the license to permit use by only one company. The client, by contrast, assumed that the subscription covered its entire working team.
Such disputes arise when an agreement is limited to a general provision granting a non-exclusive right to use the software. This does not answer practical questions: who may use the product, whether affiliates may access it, whether contractors may be granted access, whether the software may be installed on multiple servers, or whether it may be used to provide services to third parties. The scope of rights should correspond to the way the product is delivered. Cloud-based SaaS, software installed on the client’s server, and white-label solutions require different contractual models.
How Does SaaS Differ from a License for Installed Software
Under a traditional licensing model, the client receives a copy of the software and the right to perform certain actions with it. The client may install the software on an agreed number of devices or servers, run it for a specified period, and create necessary technical copies within the limits of applicable law and the agreement.
In a SaaS model, the software remains within the provider’s infrastructure. The client receives remote access to its functionality through a browser, application, or API. A copy of the software is generally not transferred to the client for independent installation.
A SaaS agreement therefore often combines several elements: the right to access the service, provision of services, technical support, data processing, and limited permission to use the interface and other protected elements of the product. The title of the document does not change the actual model. If an agreement is called a license, this does not automatically give the client the right to download the code, install the system on its own server, or transfer the product to another company.
How to Choose a Contractual Model
The delivery model determines which rights should be described and which restrictions are appropriate.
| Model | What the Client Receives | Which Rights Should Be Defined | Main Contractual Risk |
| Cloud SaaS | Remote access to functionality | Users, accounts, usage volume, API access, affiliates, and contractors | The client assumes that the subscription permits use by the entire corporate group |
| On-premise | A copy of the software for installation within the client’s infrastructure | Servers, devices, instances, backup copies, test environments, and license term | Actual deployment exceeds the agreed limitations |
| Private cloud or hybrid model | A dedicated environment and separate components for installation | Hosting, administration, updates, provider access, and migration between environments | The agreement does not distinguish between rights relating to cloud-based and locally installed components |
| White-label or OEM | The ability to incorporate the product into the client’s own offering | Branding, distribution, sublicensing, territory, and relationships with end customers | A standard license does not permit resale or granting access to third parties |
| Mobile or desktop application | A copy of the software for end use | Devices, accounts, permitted purposes, updates, and termination of access | The EULA is not aligned with app store rules and the product’s actual functionality |
Sometimes a single product requires several documents. A B2B client signs a SaaS Agreement, its employees accept the Terms of Use, and a mobile or desktop version is additionally governed by an EULA. The terms of these documents should not contradict one another.
Which Client Rights Should Be Defined in the Agreement
The phrase the client is granted a non-exclusive, non-transferable license describes only part of the relationship. An effective software license agreement should connect the legal terms to the way the client will actually use the product.
Define the Permitted Users
The agreement should explain who may be granted access: the client’s employees, members of its corporate group, temporary personnel, consultants, or external contractors.
If the product is purchased by a holding company but will be used by its subsidiaries, the group’s right to use the product should be expressly stated. The client may be required to remain responsible for the actions of all authorized users and ensure their compliance with the applicable restrictions.
Contractors are generally permitted access only when performing work for the client. Independent use of the product for other customers does not fall within this model.
Describe the Permitted Purpose of Use
The phrase “for internal business purposes” is not suitable for every product. It may prevent the client from using the system when providing services to its own customers, even though this was the very reason for purchasing the solution.
If the product is intended for agencies, consultants, platform operators, or managed service providers, the agreement should permit its use in connection with end-customer projects. At the same time, it may prohibit resale of the service itself, creation of a competing product, and granting independent access to third parties.
Establish Technical Limitations
The scope of the license may be calculated based on the number of users, devices, servers, instances, transactions, projects, or API requests. The selected metric should be measurable and consistent with the pricing model. The agreement should specify whether inactive accounts, test environments, and backup instances are counted. If the provider has the right to verify compliance with usage limits, the agreement should describe the data sources, notification procedure, and consequences of exceeding those limits.
Define the Term and When Rights End
A license may remain valid for the duration of a subscription, for an agreed period, or perpetually. The word “perpetual” does not mean that the provider must provide support, updates, and cloud infrastructure indefinitely. These services are governed separately.
For SaaS, the agreement should specify what happens after termination: when accounts are disabled, how long the client may export its data, and when the information is deleted. For an on-premise model, the obligation to stop using the software, delete copies, and confirm deletion should be defined.
Regulate Assignment and Sublicensing
A prohibition on transferring the license may complicate a client’s reorganization, sale of its business, or transfer of the agreement to another company within the group. The agreement should separately address mergers, sales of a substantial portion of assets, and changes of control.
Allowing end customers to use the product generally requires sublicensing rights or another contractual structure. A standard corporate license does not grant such rights. White-label and OEM models should also establish the territory, distribution channels, and terms applicable to agreements with end users.
Define Permitted Modifications and Integrations
For an on-premise product, the agreement should specify whether the client may modify settings, create extensions, and integrate the system with other software. Access to an API does not necessarily permit copying documentation, bulk extraction of data, or creation of a competing interface. Restrictions on decompilation and reverse engineering should take applicable law into account. In the EU, certain acts necessary for the lawful acquirer to use the software or achieve interoperability may be permitted by law subject to specified conditions. A complete contractual prohibition will not always be enforceable.
Separate Rights to the Product, Data, and Outputs
A software license does not automatically determine ownership of client data, configurations, reports, and materials created using the product. These categories should be addressed separately.
The client generally retains rights to uploaded data. The provider receives a limited right to process that data for the purpose of performing the agreement. If the service generates analytical reports, templates, generated content, or trained configurations, the agreement should specify who may use those outputs after the subscription ends.
What Restrictions Can Be Established
The provider may prohibit copying beyond the agreed scope, sharing credentials, reselling the service, circumventing technical limits, and using the product to create a competing solution. Restrictions should be specific and consistent with the product architecture.
A prohibition on granting access to third parties will require an exception for contractors if they participate in implementing and supporting the system. A prohibition on commercial use is unsuitable for a product that the client purchases for its business activities.
The provider should also define the consequences of a breach. The agreement may provide for suspension of access, payment for excess usage, remediation of the breach within a specified period, or termination. Immediate suspension should be used cautiously if the service supports the client’s critical processes or stores its data.
Who Should Own the Rights to the Software
The provider may grant a license only within the scope of the rights it owns. Before launching sales, agreements with founders, employees involved in development, and external contractors should be reviewed. Payment for development does not always automatically transfer exclusive rights to the customer. Open-source components, commercial libraries, SDKs, fonts, and third-party content require separate review. Their licenses may impose requirements relating to distribution, attribution, disclosure of source code, or use in a commercial product.
The agreement with the client should not promise a broader scope of rights than the company itself has obtained from developers and component providers. Such an issue may be discovered during due diligence, an investment round, or following a claim from a rights holder.
How Does a Software License Agreement Differ from an EULA
An EULA governs the use of software by an end user. Such a document is commonly used for mobile applications, desktop software, games, and other software that a user downloads or installs.
A B2B SaaS Agreement governs a broader range of issues: access to the cloud service, payment, support, availability, data processing, liability, and the actions of corporate users. Replacing such an agreement with a short EULA leaves a substantial part of the relationship unregulated.
If an application is distributed through the App Store or Google Play, the EULA and Terms of Use should be aligned with the platform’s rules. The platform may establish its own provisions regarding payments, refunds, subscriptions, and the standard end-user license.
Common Mistakes in SaaS and Software Licensing
A common mistake is using the same template for cloud-based and installed products. A SaaS Agreement may grant the right to install a copy even though the client never receives the software, while an on-premise agreement may fail to specify the number of servers and test environments.
Sometimes license restrictions do not match the commercial offer. The sales team promises access for the client’s entire corporate group, while the agreement permits use by only one company. Pricing may be based on active users, while the agreement limits the total number of accounts created.
Problems also arise when licensing is mixed with support. A perpetual right to use an installed version does not mean perpetual access to updates, fixes, and consultations. The price and duration of these services should be defined separately.
Another risk concerns termination. The client may lose access to the SaaS immediately after termination and be unable to export its data, while the provider continues to store the information without an agreed retention period. Exit terms should be established before the client begins using the product.
What to Check Before Signing the Agreement
The provider should compare the licensing terms with the product architecture, pricing plans, and sales practices. If the product supports several deployment models, a separate scope of rights should be defined for each.
The client should determine whether the agreement covers all companies and individuals that will use the system, whether it permits working with end-customer data, and whether contractors may be granted access. For an on-premise product, servers, test environments, backup copies, and migration rights when infrastructure is updated should also be reviewed.
Before signing, the parties should also assess the provider’s ownership of the relevant rights, third-party components, update procedures, consequences of exceeding usage limits, and the ability to export data after the relationship ends.
How Wolja Digital Can Help
Wolja Digital prepares and reviews software license agreements, SaaS Agreements, EULAs, and agreements for white-label and on-premise products.
We determine the appropriate contractual model based on the product architecture and commercial terms, define the rights of users and corporate group companies, and regulate contractor access, license restrictions, updates, support, and termination of use. We also separately review ownership of rights to the code and third-party components to ensure that the scope of the license granted to the client corresponds to the rights held by the IT company itself.