Skip to Content
Author's profile photo Richard Hirsch

Cloud-based enterprise stores for mobile apps, APIs and other goodies: SAP’s Cloud Agreements revisited

I’ve revisited the legal agreements for SAP’s cloud offerings and found some interesting new details that I would like to share.

A Cloud-based Enterprise Store for Mobile Apps

Most people know and love the SAP Store but I found a new agreement that reveals that a new type of store is coming:

The Service includes cloud-based services to enable Customer to operate an SAP Enterprise Store to distribute mobile apps to Active Users (defined below). Customer is responsible for providing all mobile apps and other content it makes available via the SAP Enterprise Store and no mobile apps or other content are provided as part of the Service. Customer is responsible for administering the SAP Enterprise Store with the functions made available as part of the Service, and the Service only includes the infrastructure and tools required for such administration.

This new cloud offering is administered by the customer not SAP.

The metric that determines the price is also intriguing:

In addition to any fixed fees set forth in the Order Form, fees for the Service are based on Active Users. An Active User is a unique visitor to the SAP Enterprise Store that performs actions on the SAP Enterprise Store that can be tracked by the Service, including without limitation, uploading an app, downloading an app, setting up the Customer store, or reviewing an app.

A user is not an app user but anyone who visits the service offering – even just to write a review. The associated costs of the store are not to be confused with the costs with the mobile apps themselves.

This offer would be especially useful in combination with SAP’s Mobile Platform, cloud version.

The importance of APIs

A recent conference  – API Days – stressed the increasing importance of such interfaces. 

In an oil-based economy, industrial processes help make gasoline for cars or fibers for clothing. Data-driven processes help developers build software. And APIs connect that software to create new types of services that span the physical and virtual world.

3SCale Co-Founder Steve Willmott presented at API Days. His theory: software is eating the world and APIs are eating software. But by itself software has limited value. Connect it and the software turns things into programmable nodes. [SOURCE]

Recent agreements for SAP’s cloud offerings, for example, SAP Mobile Platform Supplemental Terms and Conditions, SAP Mobile Documents Supplemental Terms and ConditionsSAP Lumira Cloud – Enterprise Edition – now include more details about API usage.

The particular APIs offered are quite different: In the mobile platform offering, the APIs focus on the ability to “access the Service from third party management and reporting” tools. In the mobile documents platform, the APIs in question are Content Management Interoperability Services (CMIS) compliant although SAP emphasizes that these APIs are not included in the Service and it also does not guarantee that the Service supports the CMIS standards in their entirety.

The agreements share a generic attachment about APIs:

In order to connect Customer solutions with the Service (“Customer Solutions”), Customer may use supported third party technologies to connect the Service to Customer Solutions via APIs provided with the Service. Any such connections are subject to the following conditions:

The APIs must not be used to:

  1. unreasonably impair, degrade or reduce the performance or security of the Service; (ii) enable the bypassing or circumventing of SAP license restrictions and/or provide users with access to Service to which such users are not directly licensed; (iii) render or provide, without written consent from SAP, any information concerning SAP software license terms, SAP software, or any other information related to SAP products, or (iv) permit mass data or metadata extraction from SAP software to non-SAP software, including use, modification, saving or other processing of such data in the non-SAP software.
  2. iAPIs are subject to ongoing changes. It is Customer’s responsibility to adapt the Customer Solution to such changes to APIs.
  3. SAP is not responsible for any defect or malfunction in the Service caused by use of the APIs except as permitted in this Agreement.

I’ve been analyzing these cloud-related agreements for a few years and this is the first time that I’ve seen the use of such legal language to describe such scenarios. There have been previous references to similar APIs in previous documents but the focus there was more on the protection of SAP’s IP rather than regulating API usage.

As APIs become more important in SAP’s cloud offerings, expect more related details / restrictions in such legal agreements.

Interesting Details: Mobile Platform, Cloud Version

Agreement date: 06-2013

Gateway license is necessary

Customer must have a valid license for SAP ERP and must have implemented SAP NetWeaver Gateway functionality included in such license to use the Service. This license is not included in the subscription for the Service.

This restriction is interesting for those use cases for usage scenarios where the mobile apps in question use data from other non-ERP / Gateway sources – for example, other cloud-based services.

Which productivity mobile apps are supported?

The agreement provides a link to “those Productivity and Non-Productivity Mobile applications permitted for use with the Service” where we find this information

These mobile apps are supported by SAP Mobile Platform, enterprise edition, cloud version:

• Starter option:

− Cloud-ready mobile apps are in production

• Starter+ option:

− SAP Customer Financial Fact Sheet (for Windows 8.0 only) [SOURCE]

I don’t really understand this list but it looks like there is currently just one application that may be used (certified?) for the offering. I’m hopeful that this list will be updated on a regular basis so that customers can confirm that the productivity apps that they wish to run on the mobile platform, cloud version really work there.


Fees for the Service are based on Productivity Mobile Applications and Non-Productivity Mobile Applications.

I don’t understand this fee structure – it looks like the subscription amount is based on the number of apps supported rather than the number of users of such applications.  If a low cost-per-supported application fee structure was promoted, this would permit companies to start slow with one app and gain experience with the platform before rolling out more apps.

Interesting Details: SAP Mobile Documents

Agreement date: 06-2013

Expanding the user base

Usually, SAP’s cloud offerings are restricted to “Named Users” who are normally employees or business partners.  This new Mobile Documents offering is different.

Named Users must be employees or contractors of Customer or its Affiliates. Named Users may share documents or other data with non-Named Users by sending text links to the applicable documents. SAP Mobile Documents comprises two separate subscription types– SAP Mobile Documents (User Subscription) and Cloud Storage. SAP Mobile Documents (User Subscription) is a prerequisite to a subscription to Cloud Storage.

The fee structure reflects this broader user base. The ability to charge for cloud storage to deal with non-Named Users allows SAP to increase the size of potential users and also reflects the typical use cases in the market (for example, from competitors like, etc).

Data Reuse

One of the most important benefits of providing cloud services is the ability to gain insights via the aggregation of the data from multiple customers.  SAP is no exception and its legal documents allow this scenario.

Here are two examples (TwoGo and Business Network as a Service) of such usage:

End User Data means data or content collected from or submitted by individual End Users accessing the Platform directly or by using a mobile device to remotely transmit such data to the Platform, and transaction log data collected by the Service. Customer agrees that SAP may use the End User Data in aggregated form to provide services to other customers provided neither individual End Users nor Customer can be identified from such aggregated End User Data. Customer may have the ability to access, monitor, use, or disclose End User Data via its administrative user access to the Service. [SOURCE]

In using the Service, Customer will provide SAP with its Customer Profiles and Business Partner Profiles. SAP may use the Business Partner Profiles and Customer Profiles to provide the Service, including any Additional Services (defined below). Further, Customer agrees that SAP is entitled to use the Business Partner Profiles and Customer Profiles to provide services to other SAP customers, including allowing its affiliates and partners to use such descriptions, in current or future products and services during the term of the applicable Order Form and thereafter to be distributed to and used by customers and partners of SAP in connection with such products and services.  [SOURCE]

Although SAP maybe using the data to improve the service (which I assume it is doing as well) but its main focus is to use the data to provide new services to other customers.

Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Sam Bayer
      Sam Bayer


      This is very useful information.  However, I find contract terms and conditions to be very abstract at best and confusing at worst.  What usually helps is if they could be combined with contract illustrations.

      Perhaps setting up a fictitious company and describing the various cloud implementations they may encounter and their licensing implications?  I know that that is probably a lot of work and wouldn't expect you to do it by yourself.  Nevertheless, I believe that concrete examples turn the abstract into reality quite quickly.

      Nice post.