- 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.
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.
See our references for this article and related articles at this link.
This is also a concept that is promoted by those that work on contracts for a living. The idea is that all that is 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 in the SAP v. Diageo case was due to Diageo not paying close enough attention to the contract. This falls into the same category of misinformation and 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.
Two Types of Indirect Access
There are two basic types of indirect access.
- One of these types is a legitimate complaint on the part of the vendor.
- The other 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 at least 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. By 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 on the part of customers? 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 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.”
Well, congratulations, SAP is describing any system to system interaction. Therefore SAP deserves a license sale for any system that is connected to SAP. So if a customer purchased 1000 licenses of Salesforce, it now owes SAP 1000 of ECC. SAP created its definition, which is an amazingly self-serving manner for a company that already has its software installed at so many customers, changes the game to its benefit.
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 its definition of indirect access that no one outside of SAP seems to agree 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 to 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, so ridiculous and mania seem kissing cousins as words, so Dave and I seem to agree on adjectives to use.
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 the customer knows more about indirect access, then they are always in a better position to get a better deal and to be treated better.
SAP is mostly looking for soft targets. Companies that have not done their research on indirect access, and where SAP can trick them into accepting SAP’s interpretation of the law. The customer’s internal council can be queried, but they should be expected to have much expertise in indirect access.
Remember that in some cases, the information about indirect access is coming from SAP account executives, who are briefed by SAP. They are merely repeating what they have been told in the SAP sales training material. They would not have any idea as to 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 details on 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 to 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,”
“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 a bunch of 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.”
“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 same distinction I am drawing between Type 1 and Type 2 indirect access, but it does sound similar.
If we take Dave Blake’s comment, regarding “knowingly take advantage of SAP’s infrastructure without paying…”
This wording gets a bit tricky.
The reason being 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
If a CRM system sends sales orders to ECC, it is leveraging the infrastructure of SAP. But if the customer purchases SAP CRM, SAP does not charge the same license price for the ERP license. Actually, in most cases waiving the license fee. 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 the category of 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. In their lawsuit against SAP, which included allegations of anti-trust violations, they 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” (that is under its expanded definition) other applications. Still, if the software from another vendor does the same thing, then SAP wants licenses of the connection 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.
- It is illogical for SAP to apply for indirect access only to non-SAP applications.
- It is illogical for SAP to have a definition of indirect access that is entirely contrary to the overall history of licensing of software.
- If SAP was going to take this approach to indirect access, they should have done so back in the 1980s when they started 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 types of software, 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 license of Excel 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 indirect access license for Excel!
Therefore, while I think Dave Blake here is on the right path, I don’t think the language is sufficiently specific to differentiate what is 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.
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. And, this is the questions of differential pricing as well as 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 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 that is being connected to, then SAP may decide to apply indirect access license fees.
- C.) If you are willing to purchase other licenses from SAP, then the indirect access issue will most likely go away. SAP applies for indirect access inconsistently. It is used to punish customers that buy as much from SAP as SAP thinks they should.
- D.) If you are not willing to purchase licenses immediately, but the account executive still sees you as a high or better than average potential account, then 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, as well as 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, and so these entities do as they are told by SAP.