Over the past decade Software as a Service (SaaS) as a delivery model has been steadily replacing the traditional software licensing model which is characterized with on-premise software deployment. The differences between the two service delivery models are significant. Naturally, this also leads to certain substantial differences in the agreements that regulate the two types of services.
First, a key characteristic of a SaaS agreement is that there is no copy of the software that is to be handed over to the customer. Instead, the software solution is accessed by the customer remotely over the Internet, usually through the use of a “thin client” – a customer device equipped with a web browser. This provides for great convenience and flexibility. The SaaS application can easily be accessed from any device (desktop, laptop or mobile) and from any location. Unlike this, under a software licensing agreement, the customer would typically be provided with a copy of the software in machine-readable format (object code), alongside with software manuals and relevant documentation. Additionally, the customer would normally be allowed to make additional copies for back-up or testing purposes but there could be certain limitations on the use of such additional copies, especially when it comes to the deployment of the software to a production environment. In order for the customer to be able to use the software it will inevitably have to install it on its own hardware and take care of the related support and maintenance tasks. Unlike the SaaS model where the customer receives a service, here the customer would obtain a tangible copy of the software, usually provided through a download.
A second important difference involves the status of the required software maintenance services. When it comes to the SaaS model, maintenance is already included in the provided service. Therefore, it is the obligation of the SaaS vendor to provide the customer with the latest updated version of the software without the need of any hassle or extra effort on the customer side. Typically, such updates and scheduled maintenance tasks are quietly performed by the SaaS vendor in the background, outside of the timeframe of active use of the software so that there is minimum disruption to the operational tasks performed by the SaaS product. Unlike this, under the software licensing model the customer would need to buy maintenance services additionally and pay a dedicated maintenance fee that usually comes on top of the license fee. It could even be the case that the customer pays a one-time fee for a perpetual software license but has to pay a maintenance fee on a recurring annual basis for the entire lifecycle of the software product. Furthermore, after receiving the updated versions, it is the customer that has to perform the related installations.
Third, under the SaaS model, it is usually the vendor itself who hosts the software solution. Alternatively, the solution can be hosted by a third party cloud provider (for example, an IaaS provider who is providing hosting services to the SaaS provider) and still be managed by the SaaS vendor. This is distinctly different from the traditional software licensing model where the customer gets a copy of the licensed software and then proceeds to install it on its own computer systems. Hence, in the traditional licensing model, the software is typically customer hosted. This also means that the customer inevitably will have to purchase and maintain equipment and infrastructure (i.e. hardware) in order to install and run the software and probably also invest in hiring an internal IT team. Despite the extra efforts and costs, in such a scenario the customer would retain effective control over its own data and the related data processing activities. This is distinctly different from the SaaS model where the customer would have to rely on the systems and the controls of the vendor (or its subcontractors) and its employed information security practices when it comes to the crucial topics of data security, availability and confidentiality.
This leads us to another key difference – the existence of an information security annex or cybersecurity addendum as part of most SaaS agreements. Such an addendum serves the purpose of ensuring that the SaaS vendor will comply with a certain set of security requirements and established standards when it comes to the handling of customer data. These may include encryption, data separation, use of firewalls, authentication and access management, etc. Additionally, such annexes may also grant the customer with certain limited rights of audit, mostly in terms of reviewing certifications and third-party audit reports. Typically, cloud vendors would not allow on-site audits due to the specifics of the multi-tenant model they use for servicing their customers. Instead, they could provide customers with obtained certifications that can be used as proof of their compliance with the applicable information security and data protection requirements.
Unlike this, in a traditional software license scenario, the audit rights are typically reserved for the software vendor – licensor. The licensor needs those in order to be able to verify the compliance of the licensee with the established license restrictions. These restrictions could be manifold. They could apply to the number of end users that can use the software, the number of processors or processor cores which can run the software or the number of permitted installations. It has to be mentioned that some software vendors could equip their products with certain distance monitoring facilities that may be able to indicate the occurrence of certain forms of unauthorized use and this could act as a trigger for a fully-fledged audit initiated by the vendor.
As mentioned, in the traditional licensing scenario where the customer receives a copy of the software, the application is usually provided in machine code only (object code). This is done on purpose by the software vendors since the source code of their solutions is one of their most valuable trade secrets. However, this approach comes with a risk that the customer may try to reverse engineer (decompile) the software and obtain its underlying source code from the provided object code. That is why many software licensing templates contain a prohibition on reverse engineering. For the sake of completeness, it has to be mentioned that under EU law, the end user is allowed to lawfully reverse engineer a software solution without consent from the vendor for only two strictly limited purposes – correcting errors in the software and achieving interoperability with an independently developed second piece of software.
On the other hand, things are very different under the SaaS model. The customer interacts directly with the solution through a thin client but receives no object code whatsoever. Accordingly, instead of a license grant SaaS agreements provide for two specific rights for the end customer. These are: i) the right to access the SaaS solution and ii) the right to use the SaaS solution (sometimes, only the right to use, which inevitably implies the permitted access to the SaaS solution). Accordingly, in most SaaS delivery scenarios, there is hardly a need to forbid the customer to perform reverse engineering of the software since the customer does not receive its object code in the first place.
Due to the outlined significant differences, both vendors and customers should make sure that they have developed their separate templates for a SaaS agreement and a software licensing agreement. Those separate templates should properly take into account the distinct differences between the two delivery models. The use of one and the same template for both type of deals (even with some applied modifications) could result in problematic situations and unfavorable outcomes for both parties.
You must be logged in to post a comment.