Thank you for the candid feedback. To be clear: We absolutely do not want the project structure to appear "untidy," nor do we want to leave any impression that we are "avoiding licensing obligations."
We are committed to following the Apache Way and ensuring the project meets the highest standards of compliance and quality. Therefore, I have submitted a PR [1] to address the points raised in this discussion: Action: It removes the external `fastexcel-support` module entirely and implements Internal Shading within the build process. It also strictly updates the LICENSE and NOTICE files as required. If this PR meets the requirements, I propose to close this discussion and merge these changes into the release branch for RC2. Looking forward to your review. [1] https://github.com/apache/fesod/pull/780 Best, Shuxin Pan On Wed, Jan 7, 2026 at 8:35 PM PJ Fanning <[email protected]> wrote: > > It is not required to abandon the dependency on fastexcel-support. It > would be nice to not have it as an external jar and preferable to have > it maintained inside the Apache Fesod podling. > If we keep it as an external jar, it would be preferred if that jar > had an improved META-INF LICENSE and NOTICE. > If we bring it inside the Fesod tent then it must have an improved > META-INF LICENSE and NOTICE. > > In summary, we can keep using fastexcel-support as an external jar but > it seems untidy to have what is essentially a Fesod jar but maintained > outside of the ASF so that you can avoid applying the correct > licensing to it. > > On Wed, 7 Jan 2026 at 11:48, Shuxin Pan <[email protected]> wrote: > > > > 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] > > > > --------------------------------------------------------------------- > 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]
