What is Type One Versus Type Two Indirect Access?

Executive Summary

• Indirect access is frequently covered without distinguishing type 1 and type 2 indirect access.
• No coverage of SAP’s indirect access is complete without this distinction as it differentiates legitimate indirect access from SAP’s indirect access.

Introduction

Often in discussions around indirect access, I have the person I am discussing the topic with bringing up the point around the advice that one receives to check the contracts. This is also a concept that is promoted by those that work on contracts for a living. The idea is that all necessary to protect oneself is to have the sentence taken out of the SAP contract that states that the customer can only access SAP software either “directly or indirectly” through a license. The problem with this approach to dealing with the issue is not the existence of this clause. And this is why statements regarding taking an entire contract-focused approach to indirect access will not work. It is also why it is inaccurate to state that the SAP v. Diageo case was due to Diageo not paying close enough attention to the contract.

This falls into the same misunderstanding that SaaS was responsible for the game-changing on indirect access. To see why, and hopefully, to increase the knowledge in this area, I decided to cover what I am calling two different types of indirect access. In all of my reading on this topic, I don’t recall anyone proposing this. But it makes logical sense. Using this terminology will help mitigate confusion on this topic.

Our References for This Article

If you want to see our references for this article and other related Brightwork articles, see this link.

Notice of Lack of Financial Bias: We have no financial ties to SAP or any other entity mentioned in this article.

• This is published by a research entity, not some lowbrow entity that is part of the SAP ecosystem. 
• Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department. As you are reading this article, consider how rare this is. The vast majority of information on the Internet on SAP is provided by SAP, which is filled with false claims and sleazy consulting companies and SAP consultants who will tell any lie for personal benefit. Furthermore, SAP pays off all IT analysts -- who have the same concern for accuracy as SAP. Not one of these entities will disclose their pro-SAP financial bias to their readers. 

Understanding The Two Types of Indirect Access

There are two basic types of indirect access.

1. Type 1: This type is a legitimate complaint by the vendor. This is where a customer uses some type of UI to access the vendor’s software without paying the vendor. Type one indirect access cheats software vendors out of rightful revenue. In reality, this type of behavior was exceedingly rare in software history. In fact, before SAP introduced its version of indirect access, as a researcher and a person with decades of experience in IT, I had never before heard the term indirect access. 
2. Type 2 (AKA SAP Indirect Access): The second type – was invented by SAP as an extension of Type 1: It is not a legitimate complaint and is an attempt by one vendor, SAP, to expand the definition of indirect access in such a broad way that if it were accepted, it would change the landscape in the enterprise software market. It would give the largest software vendors even more leverage than they already possess.

We/Brightwork are now getting reports of other software vendors copying SAP and trying to invoke SAP’s definition of indirect access.

Type One Indirect Access

Type one Indirect access is when a company develops a user interface or uses a third-party user interface to connect to an application. Using a user interface to access the data and functionality within the system, type one indirect access cheats software vendors out of rightful revenue.

Type one indirect access is entirely well-founded and is challenging to argue with. However, how common is this type of behavior for customers? The answer is it isn’t. It has been the historical reason that software vendors have gone after customers for extra licenses.

Type Two Indirect Access

SAP has provided the following definition of indirect access, which I took from JNC’s article on this topic.

“Indirect access is user or third party application creating, manipulating or viewing data in the SAP systems via an interface.”

Therefore – using SAP’s definition –  SAP would be due a license sale for any system that is connected to SAP. For example, if a customer purchased 1000 licenses of Salesforce CRM, it now owes SAP 1000 licenses of its ERP system as the CRM system is leveraging the ERP system. SAP created its definition for a company that already has its software installed for so many customers, creating a massive hypothetical liability for all of its customers.

I quote from Dave Blake of UpperEdge.

“The most challenging aspect of SAP’s claim of a license grant violation here lies in the very definition of use itself. The definition fails to specifically identify the concept of indirect use which leaves it completely up to SAP to determine when a violation has occurred and to what magnitude. In the past, SAP briefly nipped at its customers’ heels on the issue of indirect access, but recently, SAP has shocked some of its loyal customers by going for the jugular. Through our customers, we have observed SAP use indirect access violations as an excuse for predatorily squeezing fees from their customers, and worse, seizing the opportunity to reduce flexibility and promote an anticompetitive environment.”

That is correct.

The part that hits home is that SAP has created an indirect access definition that no one outside of SAP agrees with. However, indirect access is a legally enforceable construct. Without the force of law, neither type 1 nor type 2 indirect access exists. And SAP cannot have its laws around indirect access.

Checking the License Contract?

Dave Blake goes on to explain the following:

“Although they can educate themselves about SAP’s behavior and negotiate accordingly from the get-go, SAP’s new definition of how their software cannot be used will handcuff even its new, informed customers into agreements which expose their company and now also include ludicrous restrictions on data extraction.”

Once again, this contradicts the commonly presented idea that all one needs to do is check the license contract.

I also like the term ludicrous. I think I previously used the term lunacy to describe SAP’s new “interpretation” of indirect access.

Tricking Customers into Thinking SAP’s Type 2 Indirect Access is “Kosher”

If SAP can convince some companies into thinking that its clauses are consistent with US law, then the evidence shows that they will do this. If customers know more about indirect access, they are always better positioned to get a better deal and be treated better.

SAP is mostly looking for soft targets. Companies that have not done their research on indirect access and SAP can trick them into accepting SAP’s interpretation of the law. The customer’s internal council can be queried, but they should have much indirect access expertise.

Remember that in some cases, the information about indirect access comes from SAP account executives, who are briefed by SAP. They merely repeat what they have been told in the SAP sales training material. They would not have any idea about its legality and are not trained or incentivized to question any information they are provided by SAP.

Therefore, it is more likely than not that the account executive will present indirect access with high confidence, but this does not necessarily relate to the actual legal support for SAP’s claims.

The Timing of Receiving SAP Indirect Access Information

SAP wants to push awareness regarding SAP indirect access as late as possible in the process. A quote from back in 2012 reinforces this.

The survey results are now in, and Blake recently shared some data points with ASUGNews.com. In general, the results demonstrate that.

“SAP is not doing a good job of educating their customers on this concept and what it means,”

He says.

“It reinforces why customers who have this issue—those customers who have had it brought to their attention—are completely caught off guard.”

But of course. You do not want to “educate” people if you can have them buy under one set of assumptions and then come to them later with many SAP indirect access charges.

There is, for SAP, a perfect time for customers to become aware of the indirect access liabilities of the software they purchased. A typical time to do this is during an SAP software license audit! When discussing indirect access liabilities, SAP would prefer the saying, “We will cross that bridge when we come to it.”

Non-Compliance?

“From our perspective, where non-compliance is clear, SAP is entirely within its right to demand payment for its customers’ use infractions. For example, it is acceptable for SAP to tout indirect use as a protective restriction when there is a legitimate reason for SAP to protect its intellectual property (IP). When unlicensed users knowingly take advantage of SAP’s infrastructure and unique processing capabilities without paying, SAP is justified in requesting its customer pay additional fees for the additional benefit. We also do not fault SAP for protecting its IP in situations where its processes enhance the capabilities of other systems. But of course, this is not where SAP’s definition stops.”

I don’t know if this is the distinction I am drawing between Type 1 and Type 2 indirect access, but it sounds similar.

If we take Dave Blake’s comment regarding “knowingly taking advantage of SAP’s infrastructure without paying…”

This wording gets a bit tricky.

The reason is that when integrated, all applications take advantage of each other “infrastructure,” its data, and its processing. That is the nature of application integration.

Reviewing a Scenario

Let us take the example of two CRM (systems that support sales) connected to the SAP ERP system. In one case, the CRM system is from Salesforce (which happens to be a vendor against which SAP has enforced indirect access claims), and in the other where the CRM system is provided by SAP. 

If a CRM system sends sales orders to the SAP ERP system, it is leveraging the ERP infrastructure of SAP. However, if the customer purchases SAP CRM instead of using the Salesforce CRM system, then SAP does not charge the same license price for the ERP license. Actually, in most cases, SAP waives the license fee. 

• However, SAP CRM is leveraging ECC’s infrastructure in the same way as Salesforce. The fact that SAP is engaging in such differential pricing puts it into a tying arrangement under US anti-trust law.

I don’t think there should be much debate on this, and the details can be read in my article How to Fight Indirect Access with Tying Arrangement Law.

Teradata seems to agree. Their lawsuit against SAP, which included allegations of anti-trust violations, used the term tying arrangement.

“SAP first carried out this plan by tying (emphasis added) SAP ERP upgrades to the adoption of HANA. Specifically, SAP launched the latest version of its ERP Application, SAP S/4HANA, in February 2015. SAP describes S/4HANA as being “built on” and “natively written” for HANA. This marketing language attempts to conceal the fact that, in an abrupt change to past practice, SAP S/4HANA is wholly incompatible with other transactional databases and can only run on HANA. Thus, in order to upgrade to SAP’s newest ERP Application, customers must now also adopt HANA.”

The Double Standard

So SAP applies a double standard. First, it will allow its applications to “indirectly access” (under its expanded definition) other applications. Still, if the software from another vendor does the same thing, SAP wants licenses to connect to the system to be paid. That is, indirect access only applies when the application is from a different software vendor. However, that is an entirely inconsistent definition of indirect access. I want this point emphasized so.

1. It is illogical for SAP to apply for indirect access only to non-SAP applications.
2. It is illogical for SAP to have a definition of indirect access that contradicts the overall history of software licensing.
3. If SAP were going to take this approach to indirect access, they should have done so back in the 1980s when selling their ERP application. If they had, they would have never grown into what they are today.

Applying Indirect Access to Excel?

If indirect access were applied to other software types, then if data were exported from Excel in a CSV format and then uploaded to a non-Microsoft database, Microsoft would be owed an additional license of Excel. But on the other hand, if an Access or SQLServer were used, then no additional Excel license would be required. That is the exact logic that SAP is using with its current determination. But it gets worse than that. If you agreed to purchase another separate application, for instance, Outlook, then the Microsoft account executive would waive the Excel’s indirect access license!

Therefore, while I think Dave Blake here is on the right path, I don’t think the language is sufficiently specific to differentiate real indirect access from faux indirect access. This is why I prefer the terms Type One from Type Two indirect access. Type One is a legitimate form of indirect access. Type Two, which I also call SAP’s model, isn’t.

Differentiated Prices

But there is also an extra dimension that must be captured, and it is not captured by the Type One and Type Two distinction that I have covered thus far. These are the questions of differential pricing and indirect access only applying to non-SAP applications being connected to SAP applications.

Indirect Access Mind Map

To help people make sense of this, I have the following mindmap graphic, with an accompanying description of the likely outcome depending upon where you are on the map.

• A.) If both systems in question are SAP, then SAP will not apply for indirect access. Indirect access is not defined by the use but by whether the connecting system is sold by SAP.
• B.) If you don’t buy other licenses from SAP that are unrelated to the first system connected to SAP, then SAP may decide to apply indirect access license fees.
• C.) If you are willing to purchase other SAP licenses, the indirect access issue will most likely disappear. SAP applies for indirect access inconsistently. It punishes customers who buy as much from SAP as SAP thinks they should.
• D.) If you are unwilling to purchase licenses immediately, the account executive still sees you as a high or better-than-average potential account. You will most likely not face indirect access charges.
• E.) If you appear to be moving away from SAP, then indirect access becomes much more likely.

The Problem: Secrecy Around Indirect Access

Oracle, SAP, and their consulting partners, ASUG, and the IT media entities all have something in common. They don’t want indirect access understood. Media outlets like Diginomica are paid to distribute PR releases as articles, as we covered in the article SAP’s Recycled Indirect Access Damage Control for 2018. The intent is to lower SAP customers’ concern around indirect access so that indirect access is underestimated, as we covered in the article The Danger in Underestimating SAP Indirect Access.

The primary providers of information in the SAP space are all financially linked to SAP. SAP does not want indirect access understood, so these entities do as they are told by SAP.