* Have Spring team forked the cglib code or are they just packaging the unmaintained cglib classes (with shaded package names)? * If we include 3rd party classes in our jars, we will need to add details in the META-INF/LICENSE file that we include in the jar - even if they are Apache licensed. Possibly also, META-INF/NOTICE depending on if the 3rd party classes have NOTICE files that we need to acknowledge.
On Wed, 7 Jan 2026 at 11:03, Shuxin Pan <[email protected]> wrote: > > Hi Community and Mentors, > > We are currently preparing for Apache Fesod (incubating) 0.1.0-RC2. > > I would like to initiate a discussion regarding the handling of > CGLIB/ASM dependencies to address the valid concerns raised regarding > the fastexcel-support module during the RC1 vote. > > 1. The Issue in RC1 , we included a standalone fastexcel-support > module containing repackaged ASM and CGLIB classes. Our mentor > rightfully pointed out [1]: > > "What is fastexcel-support-1.3.0.jar? ... Are these copies of the > classes from the asm and cglib projects? If so, the licenses/LICENSE > file appears invalid." > > 2. Clarification of Origin To clarify: These classes were NOT copied > from the original ASM (BSD) or CGLIB (ALv2) projects. They were shaded > (extracted and relocated) from spring-core (which is Apache License > 2.0). > > Why shading? The upstream CGLIB project is unmaintained. The fork > maintained within the Spring Framework has become the de facto > standard, supporting newer JDKs (e.g., Java 17/21). > > The Oversight in RC1: While the license (ALv2) is compatible, we > failed to include the required Attribution for the Spring Framework in > the NOTICE file. This made the origin of the classes unclear and the > License file appear incomplete. > > 3. Proposed Solution for RC2 To resolve this ambiguity and strictly > follow the "Source Release is King" principle, we propose the > following changes: > > A. Remove the fastexcel-support module: We will delete this standalone > module entirely to avoid confusion in the source package. > > B. Implement "Internal Shading": We will move the shading logic > directly into the build cycle of the main module (where these classes > are actually used) using the maven-shade-plugin. This will: > > - Extract necessary classes from spring-core. > > - Relocate them to org.apache.fesod.shaded.* to prevent transitive > dependency conflicts (Dependency Hell). > > - Exclude spring-core from the generated POM (dependency-reduced-pom). > > C. Strict Attribution Compliance: We will update the META-INF/NOTICE > file to explicitly acknowledge the Spring Framework, fulfilling our > obligations under the Apache License 2.0. > > 4. Alignment with ASF Practices This "Internal Shading + Relocation" > pattern is a standard best practice used by projects like Apache Flink > to safely vendor critical dependencies. > > We believe this plan resolves the licensing ambiguity and ensures a > clean, compliant source release. > > If there are no objections, we will proceed with this strategy for RC2. > > [1] https://lists.apache.org/thread/vw70x0pm9zd1odgn2mp9nlcg58mfod6x > > Best, > Shuxin Pan > Apache Fesod PPMC member > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
