How to determine if your product is considered a SaaS based solution

The aim of this knowledge base article is to provide some clarity around what is considered a SaaS based solution - from a licensing perspective - and what is not.

SaaS is rapidly becoming a popular model for making software accessible to end users with no or very little upfront cost. We want to make sure that when our customers utilise our software in SaaS based solutions they are licensed appropriately to prevent costly surprises down the line.

As described in the KB article about redistributing Muhimbi software, SaaS based solutions require an OEM license. So why is a SaaS license considered the same as an OEM license? Think about it as follows, if – rather than using a SaaS based model you would have sold a regular on premise deployment of your solution – your solution would have been deployed on your customers' in-house servers. Muhimbi’s, software would be accessed from these same servers. In this case you would be redistributing our software, requiring an OEM license. A SaaS based solution works the same, the main difference is that your product is not physically deployed to your customers' systems.

 

The textbook definition for "SaaS" or "Software as a Service" is a model of software deployment whereby a provider licenses an application to customers for use as a service on demand. This is a rather 'woolly' definition open to interpretation.

The following examples should clear up what solutions are considered SaaS based and what solutions are not.

 

Definitions

Although this is not a legal document, to avoid confusion, let’s define what the various terms mean. We’ll try to keep it as simple as possible.

  • Customer: A Muhimbi customer who owns a license for our software.
  • Application / Solution: Software or website created, owned or rented by the Customer and which interacts either directly or indirectly with Muhimbi’s software.
  • End User: A person interacting with the Application / Solution, either directly or indirectly, and is not working for the Customer.
  • Internal use: The Application / Solution is accessible to people working for the Customer.
  • Public use: The Application / Solution is available to an End User either for free or for a fee.
  • Source document: A typical document before it has been processed by Muhimbi's software.
  • Processed document: A document that has been processed (converted or otherwise manipulated) by Muhimbi’s software.
  • Transmit: The method that is used to send the Source or Processed document to/from the Customer.  This can either be electronic  (via a website, customer application/solution, e-mail, etc) or in hard copy as paper documents, etc.

  

Checklist of what is considered SaaS use

One or a combination of the following points typically mean that a SaaS / OEM license is required.

  • Source documents are transmitted by End Users and Processed Documents are accessible to End Users as well.
  • Document conversion / manipulation is initiated by the End User.
  • Processed documents contain End User / time specific data.

 

Non SaaS solutions

The following examples do not require a SaaS / OEM license.

  • Internal use: Muhimbi's software is used for internal use only. Processed Documents can be used internally or distributed to external parties
  • Internal use: End User Transmits Source Documents to the Customer. Processed Documents are available for Internal use only.   
  • Public use: Muhimbi's software is used as part of a free or subscription based Application/Solution.  All Source Documents are created by the Customer and processed documents are the same for all End Users.
  • Batch use: Muhimbi's software is used to batch convert internal Source Documents. Processed documents are not End User specific and are made available for Public use.

 

SaaS solutions

The following examples DO require a SaaS / OEM license if the processed file is made available to the End User.

  • Application/Solution where End Users Transmit the source documents for processing by Muhimbi's software.  An example of this would be where an End User Transmits their records and the Processed Documents are then made available to them through a query made to the Application/Solution .
  • Application/Solution for Public Use where End User / time specific data is watermarked in each document.  An example of this would be where an End User requests a company sales brochure and their information is watermarked into it before transmission.
  • Application/Solution where End Users submit a query and customised processed documents are transmitted to them.  An example of this would be an Application/Solution where an End User requests a copy of their monthly billing statement.

 

Points of notice for solutions that qualify as SaaS

  • It doesn't matter if our software is only accessed by a small percentage of End Users, a SaaS license is still required.
  • It doesn't matter that our software only makes up a small percentage of your overall product, a SaaS license is still required.
  • It doesn't matter how many servers our software runs on being it a single one or 1000, a SaaS license is required.

 

Please note that these are merely examples and not a full list of all possible scenarios. If your scenario is not listed, or this Knowledge Base article just adds to the confusion, then please contact us. We are very nice and reasonable people and will be glad to help you out.

Muhimbi's standard Software License Agreement applies to SaaS based solutions as well. From a licensing perspective it is the same as an OEM license.

 

Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.