On SDN Code Exchange, Open Source and Free Software

[Former Member]

Today, we announced that we plan to launch Code Exchange as a key facility of the SAP Developer Network (SDN) which will allow developers to collaborate with each other. Beyond the announcement, I would like to provide a couple of details that led to the conclusion to offer such capability on SDN  and the steps we have taken to make it happen.

The general need for such a capability is obvious; developers don't just blog, but they write code that they like to share with the community. We already have the SDN code gallery in place, but a Wiki is certainly not a equivalent for a source code management system that includes code versioning. Once multiple developers start to collaborate, a professional software management system that includes bug reporting, release management, build scripts, testing and continuous integration across team members is also required.

The demand from the SDN community for such a capability was equally obvious, as excellent examples of useful tools were jointly developed by members of the SDN community such as SAPlink written originally by Dan McWeeney and Ed Herrmann. However, Dan and Ed were able to do just that without a SDN Code Exchange because developer collaboration sites like SourceForge or Google Code are already available for public usage. There is definitely a trend towards software forges; even the U.S. military has one now with http://www.forge.mil/.

Why a SAP SDN Code Exchange ?

So, what are the advantages of an SDN Code Exchange ? One is the tight integration with the rest of the SDN community, and we are carefully planning the exact features in close collaboration together with our SAP Mentors as well as other top contributors of the SAP Community Network using SCRUM methodology.

However, the focus of this blog will be on a different topic, which is software licensing. A software license essentially governs the rights granted to the community by a software author, so that in the end the community can use the resulting end product within certain limits specified in the license. Also, if you have multiple authors jointly and collaboratively working on an joint work product, the software license also needs to specify what rights an individual author needs to grant to the other authors so that the end product can be jointly used within limits specified in the software license.

Traditionally, when companies have come together to jointly produce a software product, co-development contracts were written that would exactly specify the obligations of each participant and what rights to the end products the contract partners would have. However, when individuals come together to work on a joint product that not only benefits them, but a whole community, so-called open source licenses have become very popular. Under these licenses, the source code becomes easily accessible and no payment of license fees is required. This makes it easy for other developers to use a piece of software code, modify it to his or her purpose, and give the changes back to the community.

Many different Open Source licenses

There are many different open source licenses, and the Open Source Initiative has published a vast collection.

Each of the open source licenses has a different philosophy, but roughly the differences are as follows:

• When a piece of open source is used in a different product (like a library within a software product), will that product also be subject to the same open source license, or can the product be licensed under different terms ? Specifically, is there an obligation to publish the source code of the product, or can it be licensed under terms that make the product proprietary, i.e. where the source code is kept secret and the product is sold for a fee.
• When a software author makes a modification to software code that is licensed through an open source license, does he or she have an obligation to publish the changes ?
• When a piece of open source is used in a different product, is it required to give attribution to the original author ?

The most "pure" open source license is probably the GNU General Public License (GPL) which requires that any use of GNU-licensed code would require that the end product that uses that code also becomes subject to the GPL. Effectively, whoever uses GPL software for free would also require that the resulting end product would have to be made available for free. It is, however, permitted to offer services (like support) for a fee, which is why the Free Software Foundation, that governs GPL, talks about "Free Speech" and not "Free Beer". A piece of free software that is open sourced or that uses free software can never be made non-free software, which has strong civil liberty and social responsibility associations, but it also does not exclude that companies make money off of GPL code. The best example is Linux which is available under GPL code, but where companies like RedHat and Novell run successful businesses supporting their customers.

Contrary to that, the Apache license permits that any end product that uses Apache-licensed code can be licensed under any terms, including for fee, and that changes to Apache-licensed code do not need to be published. Effectively, a user of Apache-licensed code can pretty much do anything with it, as long as proper attribution is given to the Apache-licensed code.

The Eclipse Public License (EPL) is sort of like in the middle, where software products that use EPL code can be re-licensed under different terms, but if changes are made to modules that are licensed through the EPL, a user needs to publish those changes.

SAP uses open source, but is a proprietary software company that sells its software for a fee. That's the reason why SAP favors Apache and EPL, as the resulting end product can still be licensed under any different terms. SAP has been a strong supporter of the Eclipse Foundation for many years, and has today also announced that it will join the Apache Foundation. Joining those not-for-profit Foundations is required when SAP wants to make changes to Apache or Eclipse code. SAP needs to sign their contributor agreements, and in the case of Eclipse has also financially supported the Foundation over the years. We have not made a decision whether to support the Apache Foundation financially, but this will certainly be a consideration.

Now, why is all this relevant for Code Exchange ?

Basically, most public forges offer developers a menu of licenses, usually including GPL and Apache. The issue is that in the vast majority of cases people in the SAP Developer Community would want to collaborate on software that has some sort of relationship to the SAP application products. It is unlikely that SDN developers would work together to develop, say, a new sort algorithm. A piece of software that is developed by SDN developers and shared under an open source license would likely use SAP Enterprise Services, utilize SAP Data Dictionary elements, call a BAPI or any similar technical facility that is essentially SAP's intellectual property, and for which SAP requires signature of a software license agreement.

When such code that use SAP intellectual property would be shared under a open source license, the open source license does not automatically grant rights to the underlying SAP software. Any user of a piece of software shared under an open source license must therefore make sure that they also have a valid SAPsoftware license to get access to the underlying SAP intellectual property. That, however, has essentially various degrees of issues regarding the compatibility of open source licenses and philosophy with SAP proprietary software licenses. The most pronounced incompatibility is probably with the philosophy of the Free Software Foundation and the GPL license, particularly the new version 3, that speaks about intellectual property in the context of GPL-licensed code.

As a result, it is not possible for SAP to reuse any of the existing open source licenses, and consequently, usage of a software forge that only offers common open source licenses is not be possible. We therefore had to come up with a way that harmonizes SAP software license practices and the desire of SDN developers to come together and use open source principles in their joint development processes (transparency, accountability, sharing of work etc).

So, what about SAP and Open Source ?

This is the brief summary: SAP uses open source, contributes to open source, supports open source foundations, but it is very important to note that while Code Exchange uses open source principles, the resulting code is not open source. This is due to the fact that code shared through Code Exchange requires a SAP software license which embodies the fact that we run a profitable software business.

Acquiring SAP software licenses is definitely required to use our application products, but also developers that build software with our developer tools on top of our application platform require a license, particularly to our Enterprise Services or similar technical facilities in order to develop and share what is called an "add-on" to SAP software. Enterprise Services are definitely open, which means you can go to the ES Workplace and browse them, but they are not open source. It's best to say that they are "open, but proprietary". However, that does not means that developers need to pay for the tools, nor for access to the Enterprise Services, at least not as long as they don't commercialize their code and only share it with their SDN peers to help each other.

How are we going to make this happen ?

The first important step to make Code Exchange happen was therefore to offer developers free development tools with which they can develop prototypes, and which allows them to develop add-ons using Enterprise Services. So far, the only way to get free access to SAP NetWeaver tools like the Composition Environment was the 90 day evaluation license. However, this evaluation license did not even offer the right to develop software. We changed that with the perpetual SAP NetWeaver Developer License that permits development of prototypes and share them through Code Exchange.

The second step is to create the Code Exchange licenses that permit both contribution of code to the Code Exchange, as well as use/consumption of this code. We had to make it particularly clear what the difference was between code that individual developers shared through the Code Exchange vs. SAP application code that this developer's employer had licensed through their customer agreements. The same applies to the use/consumption of code; it must be made very clear that SAP can't offer support for community-developed software that is shared on the SAP SDN Code Exchange, even if SAP employees participate in such a project. The same applies to prototype code that SAP shares with the community (e.g. sample applications, templates etc). There is no support provided by SAP beyond the resources available on the SAP Developer Network.

Both the SAP NetWeaver Developer License as well as the Code Exchange agreements for contributions and consumption is currently being reviewed by the SAP Mentors.

The final step - sometimes I feel it's minor compared to the many months of work we worked closely with our legal staff - is to provide the Code Exchange software. It will be tightly integrated with the SAP Developer Network, but we are not going to re-invent the wheel. We'll be following best practices in terms of launching a software forge, and will work very closely together with important partners. We'll be sharing more details soon.

Did this help ?

The main objective of this blog was to contextualize the various announcements we have made today: SAP joining the Apache communities and extending our commitment to open source technologies, and the announcement of SAP Code Exchange and the SAP NetWeaver Developer Licenses.

I hope I have provided you with some background, so you now better understand the difference between open source, and code that is shared between community members but that is not necessarily open source. This can be confusing, but it is important to understand the differences. SAP has a decade-long history of sharing ABAP code with its customers, so they can modify the system to their requirements. However, that does not make the ABAP code open source; on the contrary, the code is only accessible after agreeing to SAP software license agreements. Those agreements govern what can be done with ABAP source code modifications, and what kind of add-ons can be built on top of SAP functionality. Code Exchange governs only sharing of add-ons, but modifications of ABAP application source code is not covered.

Where are we going ?

We are on a very exciting journey, but it is very important to understand at least some of the foundational concepts. Open source software and proprietary software licenses are concepts that don't necessarily contradict each other. Because there are open source licenses that permit re-licensing under commercial terms, SAP can use and contribute to open source. However, this does not mean that SAP supports those open source licenses that are associated with the Free Software ideology, and SAP software most definitely is not free software.

For every use case we need to determine the right tool; if the requirement is to make SAP software more open and interoperable, use of and contributions to open source software is definitely a good way to go. Best examples are the fact that SAP has mostly standardized its non-ABAP development tools on Eclipse, and is therefore completely open to the Eclipse ecosystem.

However, in order to preserve its business, SAP may chose to open up some of its source code, but keep it under a proprietary software license and not under an open source license. Even in cases where it does not directly make money off of a certain piece of code, it may not be the right thing to do to contribute that code to Apache the or Eclipse Foundation. That code may just serve the SAP ecosystem and the SAP developer base and would be of little use to an industry-wide audience. In that case, sharing this code under SDN Code Exchange may be a good way to go. We will constantly evaluate other licensing models, and down the line it may even be possible to share code under an open source license under the SDN Code Exchange, but not yet, and there are no concrete plans to do so at this time.

Finally, in the end it is about running a profitable business, so if there is a business strategy that ensures maximum adoption through open source, yet drives revenue in a secondary market, we'll evaluate it. For example, Google Android is an operating system that is available largely under an Apache license, but Google is most definitely a very profitable business. Using open source licensing and running a successful business is not contradicting each other. Even using GPL-licenses of the Free Software Foundation may support a well-thought out business strategy, and companies like Sun Microsystems have successfully increased Java adoption while protecting their revenue model through licensing some parts of the Java Virtual Machine through GPL which makes downstream commercial usages of the VM more difficult.