What This Article Covers
- Two Types of Indirect Access
- Type One Indirect Access
- Type Two Indirect Access
- Differentiated Prices
- Indirect Access Mind Map
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 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 entirely 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. It falls into the same category of misinformation and misunderstanding that SaaaS 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, and using this terminology will help mitigate confusion on this topic.
Two Types of Indirect Access
I view there being 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 totally change the landscape in the enterprise software market. It would give the largest software vendors, even more, leverage than they already possess. In fact, I am 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 completely well founded and is difficult to argue with. However, the problem with considering this type of indirect access is that it is not very common. It has been the historical reasons 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 in 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. I like this entire paragraph, but 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. 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 ludicrous and lunacy seem kissing cousins as words, so Dave and I seem to agree on adjectives to use.
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. 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 the same way as Salesforce. The fact that SAP is engaging in such differential pricing puts it into the category a tying agreement under US anti-trust law. In fact, 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 Agreement Law.
So SAP applies a double standard. First, it will allow its applications to “indirectly access” (that is under its expanded definition) other applications, but if the software from another vendor does the same thing, then SAP wants licenses of the connected to system to be paid. That is indirect access only applies when the application is from a different software vendor. However, that is a completely 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.
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, then Microsoft would be owed an extra license of Excel. But on the other hand, if an Access or SQLServer were used, then no extra 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 unrelated 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 type isn’t.
But there is also an extra dimension which 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.
Who is the Most Accurate Source on SAP?
Want to find out? See... A Study into The Accuracy of SAP