Open source obligations in RISE deployments.

Open source software runs through the RISE with SAP stack at every layer. The S/4HANA application includes open source components inside the database connector, the message bus, and the runtime libraries. The BTP extension model relies on open source frameworks for the runtime, the build pipeline, and the deployment fabric. The underlying hyperscaler infrastructure runs on Linux distributions that carry their own licence inheritance. The combined open source surface area generates obligations that the standard RISE contract addresses only in summary. This article identifies where the obligations sit, where the buyer carries the residual risk, and the negotiation moves that close the open source gap.

Where the open source layer sits inside the RISE stack

The RISE stack has four layers that involve open source. The first layer is the SAP application itself, which embeds open source components inside the core libraries. The components are typically licensed under permissive terms such as Apache or MIT, but a small minority are licensed under copyleft terms such as LGPL or GPL. The presence of the copyleft components is not visible from the application surface, but it is documented inside the SAP open source disclosure that the contract references.

The second layer is the BTP extension fabric. The fabric supports buyer side custom development against the SAP application, with the development running inside containers that the buyer manages. The containers include open source runtimes such as Node.js or Python, open source libraries such as Spring or Express, and open source operating system components inside the container image. The buyer side custom code may also include open source libraries that the buyer team adds during development.

The third layer is the hyperscaler infrastructure. The underlying compute runs on Linux distributions that are themselves built from open source components, with each distribution carrying its own licence inheritance. The hyperscaler manages the distribution at the infrastructure layer, but the licence terms inherit through to the buyer subscription. The fourth layer is the SAP managed middleware and operations tooling, which includes its own open source dependencies that the SAP delivery team maintains.

The licence inheritance and what it implies for the buyer

The standard RISE contract addresses the open source layer by reference to the SAP open source disclosure and by reference to the standard SAP indemnification. The two mechanisms together create a chain in which SAP represents that the open source components inside the SAP application comply with the applicable licence terms, and SAP indemnifies the buyer against third party claims arising from the open source compliance. The chain is sufficient for the components that SAP controls directly.

The chain is incomplete for the components that the buyer introduces inside the BTP extension fabric. A buyer development team that includes a copyleft library inside a BTP extension may inadvertently trigger the copyleft obligations against the surrounding code. The SAP indemnification does not cover the buyer introduced components, and the buyer is exposed to the copyleft compliance obligations that the library carries. The exposure is the buyer responsibility under the standard contract, and the responsibility is rarely flagged at the architecture review.

The buyer counter is to introduce an open source policy at the BTP development gate. The policy requires the development team to scan every dependency against a defined open source compliance database, to flag any copyleft component before commit, and to escalate any flagged component to the open source steering committee. The policy is the operational property that prevents the inadvertent triggering of the copyleft obligations, and the policy is the property that the buyer side legal team should require as a contractual obligation against the development team, not as a recommendation.

Sub processor exposure and the open source security supply chain

The open source security supply chain extends through the entire RISE stack. A security vulnerability in a single open source component may affect the SAP application, the BTP extension fabric, the hyperscaler infrastructure, or any combination. The standard RISE contract assigns the security obligation to SAP for the layers that SAP controls and to the buyer for the layers that the buyer controls. The assignment is clean in principle and messy in practice.

The messy operational reality is that a vulnerability in a shared open source component, such as a widely used logging library or a JSON parsing utility, may affect multiple layers simultaneously. The SAP delivery team patches the SAP application against the vulnerability on the SAP timeline. The hyperscaler patches the infrastructure against the vulnerability on the hyperscaler timeline. The buyer patches the BTP extensions on the buyer timeline. The three timelines rarely converge, and the divergence leaves the integrated landscape exposed during the patch window.

The buyer counter is to negotiate a coordinated vulnerability response protocol into the contract. The protocol defines the notification window, the patch coordination procedure, and the temporary mitigation steps that the SAP delivery team will implement during the patch window. The protocol is the operational property that converts the open source security obligation from a layered set of independent activities into a coordinated incident response.

Indemnification scope and the open source carve out

The standard SAP indemnification covers the open source components that SAP includes inside the SAP product. The indemnification does not cover the open source components that the buyer introduces inside the BTP extension fabric. The indemnification does not cover the open source components that third party SAP partners introduce inside their applications that integrate with the RISE landscape. The scope gap is the property that the buyer side legal team should examine most carefully when the BTP extensions or the partner integrations involve copyleft components.

The buyer counter is to require the third party SAP partners to provide back to back indemnification on the open source components inside their integrated applications. The back to back indemnification is rarely available from the small SAP partners, and the absence creates a residual exposure for the buyer. The residual exposure has to be priced into the integration risk budget, with the buyer accepting the cost or negotiating an alternative integration path that avoids the exposed partner. The pricing of the residual is the discipline that distinguishes the controlled RISE landscapes from the exposed ones.

Audit rights and the open source bill of materials

The standard RISE contract does not provide the buyer with an explicit right to audit the open source bill of materials for the SAP managed components. The SAP open source disclosure is published at the SAP discretion and updated at the SAP cadence. The buyer who needs the bill of materials for compliance reporting, for security analysis, or for incident response has to work through the SAP support channel, with the response time and the response detail at the SAP discretion.

The buyer counter is to negotiate an explicit right to receive the open source bill of materials inside the standard reporting cycle. The bill of materials covers the SAP application, the SAP managed middleware, and the SAP operations tooling. The bill is delivered in a defined format that the buyer compliance tooling can ingest, with the cadence aligned to the buyer reporting cycle rather than the SAP disclosure cycle. The clause is increasingly important for buyers in regulated industries that have to report against the software supply chain to their own regulators.

The negotiation playbook in summary

The open source obligations clause has five recurring negotiation moves. First, introduce an open source policy at the BTP development gate as a contractual obligation. Second, negotiate a coordinated vulnerability response protocol across the SAP, the hyperscaler, and the buyer layers. Third, require back to back indemnification from third party SAP partners on the open source components inside their integrated applications. Four, negotiate an explicit right to receive the open source bill of materials inside the standard reporting cycle. Five, define the open source security disclosure obligation against the SAP timeline. The combined yield is a materially stronger open source position than the standard template, and the combined yield is the property that closes the gap that the standard contract leaves open.

Closing position. The open source layer is the silent layer

The open source layer inside RISE is invisible to most buyers at signature and material to most buyers at incident. The contract addresses the layer in summary, with the detail left to disclosures and policies that the SAP team controls. The buyer who reads only the contract paragraphs misses the operational reality. The buyer who reads the disclosures, the policies, and the integration architecture identifies the exposures that the contract paragraphs do not flag. The discipline of reading the open source layer is the property that distinguishes the deals that close with operational confidence from the deals that close with vendor representations. The layer is the silent property of the cloud subscription, and it is the property that the firm consistently surfaces on the contract review engagement.