A license from hell: SAP Developer License 3.2 – CAP

Published by Tobias Hofmann on

13 min read

In 2021 I wrote about what is needed license-wise to make CAP a success. Short version: not much. What is needed are developers that use CAP. A license only must enable developers to use CAP. Developers must be able to discover CAP, learn it, use it in some projects and gather project experience using CAP. An open source license might help in this endeavor but is not a hard requirement. A license should act as an enabler. A license indicates what a company wants to achieve. An open source license indicates that the company is open to new developers from outside: outside the core team, company, established eco system: new people joining and even bringing with them new use cases.

Back in 2021, I was thinking: what could go wrong? The CAP license worked more or less for SAP and non-SAP use cases. There were some gaps and questions regarding use cases. An open-source license would be better, for sure. And open-sourcing CAP was on the roadmap! The SAP Development License was good enough to get people from outside the SAP world to discover CAP. It might not have been good enough for the non-SAP world to adopt CAP for their non-SAP related projects. While everything could go faster and CAP acceptance, especially by the non-SAP Java/JavaScript developers, could have been higher: what could go wrong? The stage was set for things to work out and all that was needed from us was to wait. Surely it would not take too long to solve the license problem. Fast forward to 2025.

In 2025, the essence of my post is still true: SAP should focus on the non-SAP world to make CAP a success. Limiting it to the boundaries of the SAP world, specifically to the limited resources of SAP developers, is a risky approach to making CAP a success. Specifically in customer projects. Customers are busy going to S/4HANA. Even with SAP support doing heavy marketing at S/4HANA projects for CAP and side-by-side extensibility. The resources customers have available are focused on S/4HANA. When they want to go for clean core: this means ABAP. When a company needs ABAP developers in the first place to understand what the code is doing and how to transform it to clean core, leaving ABAP is not the best option. Extensibility is shifting from side-by-side where CAP is an alternative, to on-stack extensibility. Why add complexity when ABAP Cloud is available on stack for all S/4HANA flavors: on-premise, private cloud, public cloud?

New license

In 2021 I thought that the license isn’t the crucial point. 2025 shows that I was wrong.

CAP before 9.x is licensed under the normal SAP Developer Agreement 3.2. So far, this license has helped CAP to grow its fan base in partners and freelancers. It is just so much easier to start a CAP app on your laptop than having to connect to a NetWeaver ABAP system or having to connect to BTP first. Great for PoC or demos running on your laptop. For a sustainable user base, the fan group is not big enough. The CAP team is working to make CAP a feasible alternative for SAP product teams building cloud solutions. Problem: this is SAP internal. An SAP product is built, probably SaaS. Naturally, in these cases, the CAP license is irrelevant. And for the SAP-external (aka customer) and non-SAP part? How about those that pay the bill? SAP sells software, partners sell stuff, and freelancers want to have an assignment to develop CAP apps. They all depend on customers to buy their services. Customers do not have unlimited money available, and they depend on that software fulfills some constraints. You do not want to be the first one to solve a problem.

Starting with version 9, CAP is released und a special version of the SAP Developer Agreement 3.2. SAP and the CAP team decided to clarify license and support question by releasing CAP under the SAP Developer License 3.2 – CAP. The license differs in some parts from the standard SAP DEVELOPER LICENSE AGREEMENT 3.2.

Limitation to BTP

This is a little bit complicated due to how the license is formatted. This is how the text is presented:

LICENSE: SAP grants You a non-exclusive, non-transferable, non-sublicensable, revocable, limited use license to copy and reproduce the application programming interfaces (“API”), documentation, plug-ins, templates, scripts and sample code, libraries, software development kits (“Tools”) to create new applications (“Customer Applications”) being developed either for (a) testing and only non-productive use (“Customer Test Applications”) or (b) for productive use deployed and operated exclusively on “SAP Business Technology Platform (BTP)” or any other platform licensed from SAP (“Customer Productive Applications”).

Formatting could be better. It makes a difference where the deployed and operated part is.

Alternative 1: BTP only for productive apps:

[…] to create new applications being developed either for

(a) testing and only non-productive use or

(b) for productive use deployed and operated exclusively on “SAP Business Technology Platform (BTP)”

Alternative 2: BTP only for all CAP apps:

[…] to create new applications being developed either for

(a) testing and only non-productive use or

(b) for productive use

deployed and operated exclusively on “SAP Business Technology Platform (BTP)”

Small change, big impact. Luckily, someone at SAP saw that this might be confusing and there is a FAQ section about the CAP license at the CAP documentation. Productive usage of a CAP app is only allowed on “BTP or any other platform licensed from SAP”. For non-productive apps you can run CAP on anything else. Be aware: it only takes small changes in the formatting and SAP can ensure that everything that comes after developing must be done on BTP. Or that everything must be done on BTP if you ever want to offer a productive app.

Productive apps

With a SAP platform being mandatory to run a productive CAP app, what is a productive app? The FAQ contains a section about this topic. Unfortunately, it only differentiates from testing and non-productive usage and productive usage. The explanation leaves room for interpretation. An internal only available CAP app written to help employees to e.g. book their vacation, company car, register for an event, look up trainings, … are all those apps are productive apps. You cannot run those in the K8s environment of your choice like in Azure or AWS. You need to run them on BTP. A CAP app written to serve as a show case to convince customers to hire you for a project? A demo app shown at a conference to show how cool CAP is and – as a side effect – show that you master this skill and prospects can get in touch with you? These apps serve a productive use case: be hired. No wonder CAP is not presented at JavaScript or web events. You’d need BTP to run those apps on. When you have BTP, you are already an SAP customer. Therefore, CAP does not serve to get non-SAP developers joining the SAP world.

In case productive usage does not get better clarified: be careful. For freelancers this might be a challenge. To be on the safe side, all CAP apps presented at an event or that are part of your portfolio must run on BTP and not on a laptop. Freelancers must be a BTP customer. We all know how well the free tier worked.

Support

A side effect of enforcing BTP is support. CAP apps used for demonstrations or POC sometimes can trigger improvements. Support for such apps? It must be a productive app.

We offer support for Customer Productive Applications that are developed and made available by You in accordance with the SAP Developer License 3.2 CAP.

Developing a CAP app to try something out, to learn and running it on your laptop? No support from SAP / CAP. You’d need to be a BTP customer. And, here I’d like some clarification regarding support, if the app is intended to run on BTP, but is still in development? The part “and made available” means: the app is already deployed as a productive app in BTP? Because in that case: only productive apps on BTP get support? A bug found in developing and testing gets no support? Starting the CAP app development locally and with the plan to deploy it on BTP in 3 months and I encounter a CAP bug? Do I have support? I guess the and made available on BTP is optional for such CAP apps? And when the CAP is developed, gets support, and later is canceled and never went to production?

Maybe the CAP support section in the license is intended to make life easier for partners? Judging from the testimonial for the new license I’d say: yes, good for partners. Everything where a partner would have to invest is simply outsourced to the customer: support is your problem. Open a ticket to SAP and just don’t bother the partner.

This is somewhat sad. An open-source license allows partners to demonstrate that they are better than the competition. A bug can be solved by a skilled partner (or freelancer) and provided immediately to the customer and to the greater CAP community by sharing the code. Of course, the license must support this. But, if the advantage of the CAP license is to point customers to SAP for support, you know what to expect in the future. A framework for business applications where customers are forced to use the SAP support is something we already have. CAP could differentiate here, but the message from SAP is clear. This eliminates the need to master the internals of CAP for partners. Dealing with this is left to SAP and the CAP team. For customers this means: when your CAP development encounters a bug, you’ll have to wait for SAP to solve it. Independent if CAP is open-sourced or not. SAP is going to be the bottleneck, independent from the partner chosen to support you with your app.

CAP is not for AI

You cannot use your CAP app to train or refine an AI model.

ARTIFICIAL INTELLIGENCE TRAINING: You are expressly prohibited from using the Software, Tools or APIs as well as any Customer Applications or any part thereof for the purpose of training (developing) artificial intelligence models or systems (“AI Training”). Prohibition of AI Training includes, but is not limited to, using the Software, Tools, APIs and/or Customer Applications or part thereof in any training data set, algorithm development, model development or refinement (including language learning models) related to artificial intelligence, as well as text and data mining in accordance with §44b UrhG and Art. 4 of EU Directive 2019/790. For the avoidance of doubt, by accepting this Developer Agreement You agree that Your ownership of Customer Applications shall not create nor encompass any right to use Customer Applications for AI Training and, hence, You will not use Customer Applications or any part of it for AI Training.

Let’s try to make this shorter and and highlight what you cannot do.

You are expressly prohibited […] purpose of training (developing) artificial intelligence models […] Customer Applications in any training data set, algorithm development, model development or refinement as well as text and data mining […] You will not use Customer Applications or any part of it for AI Training.

Unfortunately, there is no explanation about AI and CAP at the CAP license FAQ. Maybe someone can add some clarifications? Or is it as simple as: no, you cannot?

In case you thought that you can use a CAP app as input for training a LLM: no. Not allowed. Now, the question is: what about agents or MCP? Is CAP here allowed? Can I have a CAP app that serves data via MCP? Does this count as training? Or refinement? Nevertheless, until this is cleared in a written form: I’d not use CAP anything AI related that is not 100% aligned with SAP. Using Joule to create a CAP app? Find, go ahead. Use MCP to consult an OData Service from CAP? Nope, wouldn’t do it. Everyone that thought about presenting some AI use case with CAP: you better be an SAP employee. If not: do not do this.

Applause

After looking a little bit a the new CAP license: why were people applauding when this change was announced at reCAP? As the applause was weak, maybe only the SAP employees applauded? This license is the contrary to open source. It limits the possible use cases and runtime scenarios. Even when CAP is open sourced, the damage is done. Why limiting before going open? No one that is sane will build anything CAP, if not 100% SAP related. The intentions from SAP are clear with the license: Even when CAP is open sourced, SAP will try to restrict its usage to scenarios it can control: BTP as the default platform and the one with support. Features and bug fixes will be determined by the SAP customer status. Open source users will be second-class citizens. If at all. And it won’t help to find the needed developers and to create a market for CAP that attracts customers.

The new license contradicts any move to open sourcing CAP. It will be interesting to see what SAP is going to do when CAP is released as open source. How will SAP enforce the AI limitation? Support for non-BTP apps only via issues that get a low priority assigned? Support only via the community? Like today?

Other than what is made available on the SAP Community Website (SCN) by SAP at its sole discretion and by SCN members, SAP does not offer support for the API or Tools which are the subject of this Developer Agreement

What now to do with CAP? Productive apps must be run on an SAP platform. For customers this means: BTP. Partners will point you to SAP for support. Support is then provided by the CAP team that publicly states they are struggling to provide support. CAP for public demos or show cases to win customers? Better have the app running on BTP. CAP as input for AI related tasks? Better check your lawyer. AI is one of the most hype topics of the last years and the years to come. And CAP is out.

ISC License days

Earlier releases of CAP were published on NPMJS using the ISC license. For @sap/cds-dk 1.8.0 the package.json states:

Ein Bild, das Text, Screenshot, Software, Schrift enthält.

KI-generierte Inhalte können fehlerhaft sein.

There was no license file provided. The good old days when people just ran npm init and accepted default values. At least since CAP 2.0.7 the license was changed to the SAP Developer License Agreement.

Ein Bild, das Text, Screenshot, Zahl, Schrift enthält.

KI-generierte Inhalte können fehlerhaft sein.

Typos in the license

In case someone from SAP is reading this and wants to fix typos in the developer 3.2 license: there are two spaces before “SAP

(b) for productive use deployed and operated exclusively on  “SAP Business Technology Platform (BTP)”

You might also check for double spaces in general, as this is not the only part. Points 7 to 12 come with 2 spaces, while the others have one space. 7. has “CUSTOMERS  OR” 11. has “immediately.  In”, 6. “AVAILABLE.  YOU”, 5. “INFRINGING.  YOU”, … and so on. Just search for ” ” and you’ll be surprised.

Let the world know
Categories: SAP

Tobias Hofmann

Doing stuff with SAP since 1998. Open, web, UX, cloud. I am not a Basis guy, but very knowledgeable about Basis stuff, as it's the foundation of everything I do (DevOps). Performance is king, and unit tests is something I actually do. Developing HTML5 apps when HTML5 wasn't around. HCP/SCP user since 2012, NetWeaver since 2002, ABAP since 1998.

0 Comments

Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.