What is the process for transitioning from Spring Enterprise to OSS

Products

• VMware Tanzu Spring Essentials

Issue/Introduction

Commercial Spring artifacts (e.g., Spring Boot enterprise CVE patches) are governed by the Broadcom Foundation Agreement. Unlike standard Open Source Software (OSS) licenses, the right to use, distribute, or run applications containing these enterprise binaries terminates upon the expiration of an active subscription.

Compliance Requirements

Upon termination of a Spring Enterprise subscription, customers must:

1. Cease Use: Stop running applications that contain enterprise-only binaries.
2. Purge Artifacts: Remove all Broadcom-licensed enterprise dependencies from:
   • Local build environments and developer machines.
   • Internal artifact repositories (e.g., Nexus, Artifactory).
   • CI/CD deployment pipelines.
3. Submit a Formal Certification of Destruction and Cessation of Use:
   The written notice should be printed on official company letterhead and include:
   
   
   • Contract Identification: Account name, agreement/transaction document number, site ID, and effective date of expiration or termination.
   • Product Scope: Specific listing of products or components discontinued (e.g., Tanzu Spring Enterprise, Tanzu Build Service, Java Archives, Documentation).
   • Explicit Cessation & Destruction Clause: A statement confirming that use of the software, documentation, and support has completely ceased, and that all local, cloud, and backup copies have been permanently destroyed or deleted.
   • Authorized Signature: Signature, printed name, title, and date from an officer or authorized company representative (e.g., Vice President, CTO, Director of IT/Procurement).
   
   
   Send the signed certification PDF to your assigned Broadcom Account Executive or Customer Success Manager.
   
   
4. Migrate to OSS: Replace enterprise-specific dependencies with standard OSS releases to maintain ongoing support and compliance within the open-source ecosystem.
   

Technical Migration Steps

To identify and replace enterprise dependencies, customers should follow these steps:

1. Identify Enterprise Artifacts

Scan pom.xml (Maven) or build.gradle (Gradle) files for dependencies sourced from the Spring Enterprise Repository (packages.broadcom.com). Enterprise versions typically follow a four-part versioning system (e.g., 3.1.24.0 or 3.1.28.1), where the fourth digit indicates a private enterprise-validated security patch.

2. Update Dependency Coordinates

Revert enterprise-specific coordinates to their OSS equivalents.

• Example: Replace an enterprise-only Spring Boot Starter version with the latest public OSS version available on Maven Central.
• Reference: Consult the Determining Commercial Support Eligibility for Spring Projects article to distinguish between commercial and OSS artifacts.

3. Rebuild and Validate

Rebuild applications using standard OSS repositories. Ensure that all enterprise-only features (such as specific SLSA compliance metadata or pre-disclosure CVE fixes) are no longer integrated into the build.

Resolution

Internal Audit Procedure (Support & Sales)

If a compliance audit is required for a non-renewing customer, internal teams should follow the governance protocol managed by the Compliance team.

Audit Initiation Template

To initiate an audit, complete the following details and submit them to the Compliance Lead (Prathyusha Upadrashta):

• Contract Details: Product name, Start/End dates, and Renewal date.
• Customer Info: Full Name, Office Address, and Primary Contact email.
• Legal & Sales Context: Sales sentiment, Broadcom Legal contact (if known), and details of any Partners/Distributors involved.
• Documentation: Attach the relevant agreement (ELA, SPF, or VEO).
• Justification: Explain the reason for the audit request (e.g., suspected continued use of enterprise binaries post-expiration).

Additional Information

Related Articles

• Determining Commercial Support Eligibility for Spring Projects