Hi PJ Fanning, Thank you for the feedback. Here are the clarifications and our action plan regarding your questions, plus one follow-up inquiry regarding the project structure.
1. Regarding Spring's maintenance of CGLIB: Yes, the Spring team maintains an active internal fork of the code, rather than just repackaging binaries. The original upstream CGLIB project is unmaintained and lacks support for modern Java versions. The Spring team has applied significant patches to their internal version to ensure compatibility with newer JDKs (e.g., JDK 17/21). This maintained codebase is essential for Fesod. 2. Regarding LICENSE and NOTICE files requirements: Understood. We missed the requirement to explicitly document bundled ALv2 artifacts in the LICENSE file. For RC2, we will strictly follow the bundling rules: META-INF/LICENSE: We will append a section to the LICENSE file explicitly stating that the artifact bundles code from the Spring Framework (APLv2). META-INF/NOTICE: We will propagate the relevant attribution notices from spring-core's NOTICE file into our project's NOTICE file. 3. Follow-up Question regarding Project Structure: If we strictly implement the LICENSE and NOTICE fixes mentioned above, is it acceptable to continue using the separate fastexcel-support jar (module)? We prefer to keep fastexcel-support as a standalone dependency that handles the shading, rather than moving the shading logic directly into the fesod source tree (Internal Shading). Our question is: As long as the licensing compliance is strictly resolved, is it permissible to maintain this separate module structure for the release? Best , Shuxin Pan On Wed, Jan 7, 2026 at 6:10 PM PJ Fanning <[email protected]> wrote: > > * 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
