SAP: Open Source's Friend or Foe?
For an outfit that calls itself “the world's largest business software company”, the German software giant SAP is relatively little-known in the open source world. With 51,500 employees, a turnover of 11.5 billion euros ($16 billion) last year, and operating profits of 2.7 billion euros ($3.8 billion), SAP is clearly one of the heavyweights in the computer world. Given that huge clout, SAP's attitude to open source is important; and yet it is hard to tell whether it is really free software's friend or its foe.
On the positive side, SAP has invested in many of the top open source companies, through its SAP Ventures arm. Well-known names it has backed include Alfresco, GroundWork, Intalio, JasperSoft and Zend; earlier investments included MySQL and even Red Hat.
Just recently, it announced that it was increasing its participation in the Eclipse Foundation:
As part of its ongoing commitment to Java technology and the choice it provides to customers as well as industry-wide technology standards and open source, SAP AG is taking a more active leadership role in the Eclipse Foundation by increasing its membership level from Strategic Consumer to Strategic Developer. SAP will provide at least eight full-time development resources to various projects and lead open source projects, ensuring direct input into the development and architecture of Eclipse. As a Strategic Developer, SAP will be more active within the Eclipse community, including the new Eclipse Git Team Provider (EGit), the Eclipse Modeling Project (EMP) and the Eclipse Equinox Project. Eclipse technology has become the de-facto standard in many domains and for many companies ongoing collaboration on various projects with other industry leaders supports the standards and open source strategies of customers and partners.
These outward-facing activities present a very positive picture of the company, engaging with open source in all kinds of ways. But there's another side, one that's hidden unless you start digging through obscure documents, that's rather less flattering.
For example, the European Commission organised seven workgroups looking at various aspects of European software policy. One of these was on open source. Among the groups taking part in this was the Free Software Foundation Europe, and SAP. At the end of their joint report (PDF, HTML), there are a number of appendices that represent the particular views of participants. SAP's is by far the longest, running to some 17 pages.
Most of that space is used to bolster the following statements through supporting comments of various kinds (mostly links to news items):
A number of key open source projects depend on the contributions by mixed source / hybrid model companies
Hybrid / mixed source models seem to be a key element of the larger open source ecosystem
Open source development like closed source development has its pros and cons
It is very difficult to discriminate between open source and non-open source vendors any longer
Open source software is proprietary as well
Different business models and business interest lead to different positions regarding IPR, standardization and interoperability
The general thrust seems to be that there's no big difference between open and closed source, or between open source and non-open source vendors, and that everything is converging on “hybrid/mixed source models”.
So why is SAP so keen to blur the distinction between open and closed source solutions? An answer can perhaps be found in the main body of the report, where some members express their disagreement with sections of the main text otherwise approved by the others. Here's a case in point:
Mandates for OSS can harm OSS:
The following is a view specific to SAP and CompTIA
Open source has created an interesting opportunity for entrepreneurs as they can start a business on top of something that is already available. For example, many companies offer services and support around popular open source software packages.
Due to the mixed model growth, software vendors are combining open source with closed source, and as a consequence, the line between open source and closed source increasingly blurs. Therefore, any preferences or mandates favouring open source may be harmful for all software vendors including most open source vendors.
For example, if an open source vendor monetizes its open source contributions by selling closed source add-on components and closed source enterprise editions, such a vendor will be discriminated or excluded during such public tenders. This is particularly true when the closed source “enterprise editions” have been productized under a different brand name and thus are not recognized as an open source product anymore. Thus, even though it might sound paradoxal, preferences or mandates for open source may harm open source, because they reduce the opportunities for the contributing open source vendors to get a return on their open source contributions. Therefore, open source preferences or mandates could be counter productive in growing the European software industry.
We can see here how SAP and CompTIA are implicitly drawing on SAP's argument that there's now no fundamental difference between open and closed source, and that “mixed models” prevail. That being the case, they argue, it would “harm” open source to insist on open source only. That is why SAP spent so many pages “proving” this: it needs it to support its earlier objection.
However, just as the “mixed models” have grown in popularity just recently, so they may well fall out of favour; basing European policy on fashion rather than principle is hardly wise. Moreover, it's really irrelevant whether companies are adopting a “mixed model” or not; the European Commission needs to decide what is best for Europe, not for software companies that have built their businesses in a certain way.
There are many well-known benefits that accrue from mandating open source for European contracts – level playing-field, absence of lock-in, ease of moving between suppliers etc. More generally, it creates a bigger software commons that everyone can draw upon - not just companies, whether giants like SAP, or small startups, but educational establishments too (an important but often-overlooked sector).
Companies that have adopted a mixed model can simply re-jig their product line, offering wholly open source versions for European government consumption, and making money through their proprietary add-ons elsewhere; adoption by Europe would be a huge marketing boost, making it much easier to do this. And if they won't adapt to the situation, that creates an opportunity for new players who *are* willing to do so.
That's not the only place where SAP's attitude to open source is ambiguous, to put it mildly. For example, there's a section in the document that deals with software patents:
IPR sanity checks
Setting a clear agenda on IPR sanity checks and the ability to deliver legally binding IPR compliance statements on OSS components by a transparent body is a much needed action item.
But SAP is not happy with what follows:
SAP disagrees with the following part of this proposition
On top of providing Compliance statements this body could have the following goals from which Open Source will strongly benefit
- push for ex-ante disclosure on patents
- call for transparency of the judiciary in charge of software IPR rulings
- promote acknowledgement and full integration of alternative IPR modes aside the RAND types by Standards Development Organisation, research projects, public procurement, and public/private European entities delivering IPR-related assets.
- promote alignment of e-procurement processes to ensure the risk of vendor lock-in is evaluated and part of the decision criteria.
- push for Systematic “prior art” research on open source projects as a step of new patent analysis
The problem here is that SAP likes software patents. In another obscure filing, this time to the European Patent Office, it spends pages arguing that the current, already-porous regime for granting patents on software in Europe should be loosened even further.
Other ideas that SAP objects to in the European report include “Promote OSS initiatives targeted to commoditize software products of interest to European industries,” and the creation of the “European OSS forge” and “The European OSS test bed.”
A company that wished open source well would back these ideas. One that *really* supported free software would also fight against software patents. So, while SAP's involvment in Eclipse and investment in open source companies is welcome – and pretty self-interested, it has to be said, given that it presumably hopes to make a profit on them – it's not really enough cancel out its unhelpful attitude and statements elsewhere. If it wants to be a serious, respected player in the world of open source, as befits its size, it must do better.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Server Hardening
- BitTorrent Inc.'s Sync
- The Death of RoboVM
- EnterpriseDB's EDB Postgres Advanced Server and EDB Postgres Enterprise Manager
- The Humble Hacker?
- The US Government and Open-Source Software
- New Container Image Standard Promises More Portable Apps
- Open-Source Project Secretly Funded by CIA
- ACI Worldwide's UP Retail Payments
- AdaCore's SPARK Pro
In modern computer systems, privacy and security are mandatory. However, connections from the outside over public networks automatically imply risks. One easily available solution to avoid eavesdroppers’ attempts is SSH. But, its wide adoption during the past 21 years has made it a target for attackers, so hardening your system properly is a must.
Additionally, in highly regulated markets, you must comply with specific operational requirements, proving that you conform to standards and even that you have included new mandatory authentication methods, such as two-factor authentication. In this ebook, I discuss SSH and how to configure and manage it to guarantee that your network is safe, your data is secure and that you comply with relevant regulations.Get the Guide