Thanks for the feedback. I have pushed few changes for removing xtable-utilities and updating LICENSE file for xtable. https://github.com/apache/incubator-xtable/pull/540 https://github.com/apache/incubator-xtable/pull/541
I have also compiled the list of dependencies for each module (Dependency, Dependency Type Dependency Scope, License, Category, ASF Compliant) in this sheet, please review if anything still needs to be added in LICENSE file. https://docs.google.com/spreadsheets/d/1XBCZBeWqF2D5d1L4H9fRQ1QLarJq4tLgIEgnGiNdoV8/edit?usp=sharing Next steps, 1. Release 0.2.0 after addressing feedback and merging PR's mentioned above. 2. Exclude category X dependencies from xtable-utilities and reduce the size of bundled jar. 3. Release 0.3.0 with the goal of moving from DISCLAIMER-WIP to DISCLAIMER. Thanks Vinish On 2024/09/13 16:27:58 Vinoth Chandar wrote: > Thanks everyone for jumping on this. Truly appreciate the complexity in > getting these things right, given how Apache processes/instructions can be > vaguely defined at best, in many places. > > +1 on removing the bundled jar and pushing out another release right away. > > On the bundled jar etc, many projects including Iceberg provide these > convenience jars for users. Asking users to build it themselves for XTable, > where we expect it be added to data pipeline runtimes, will be hard. > > From hudi experience, we moved to a model of specifically "whitelisting" > jars (vs bundling every dependency), carefully understanding what are > already provided by different compute engines for e.g . > That reduced the overall jar size, that seems to have caught everyone's > imagination, as well as reduce the overall exposure to licenses, ensure we > never whitelist a non-permissible licence etc. > I suggest we work towards that approach.. > > Cheers, > Vinoth > > > On Fri, Sep 13, 2024 at 8:02 AM Stamatis Zampetakis <zabe...@gmail.com> > wrote: > > > Hello, > > > > From a maven release perspective, I don't think there is significant > > benefit in publishing a fat/shaded jar of xtable-utilities. If we drop > > shading, the xtable-utilities jars should be rather minimal without > > special requirements for licensing. XTable consumers that want to use > > the xtable-utilities via maven will automatically get all transitive > > dependencies via maven's dependency resolution mechanism. > > > > From the user's perspective, a fat jar makes sense since it greatly > > simplifies execution using a simple java command. An alternative way > > to provide simplicity to the users is to gather dependencies in a lib > > directory during the build (using maven-assembly-plugin, > > maven-dependency-plugin, etc.) and instruct the users to run a script > > (usually in a bin directory) which is mostly there to manage the > > classpath. The main advantage of this approach is that 3-party > > binaries will not be published/released as Apache XTable code. > > > > In all cases we need to verify the licenses of our dependencies but if > > we don't mingle 3rd party binaries in Apache binaries things are > > significantly easier to document. > > > > Lastly there are various maven plugins (such as > > https://www.mojohaus.org/license-maven-plugin/) that can aid the > > LICENSE documentation and checks but from the moment that the project > > does not perform binary releases this is not strictly necessary. > > > > Best, > > Stamatis > > > > > > On Fri, Sep 13, 2024 at 5:47 AM Jesus Camacho Rodriguez > > <jcama...@apache.org> wrote: > > > > > > Hello everyone, > > > > > > First, I'd like to thank Vinish for driving our first release as an ASF > > > project, which is often the most challenging one. > > > > > > Unfortunately, during the recent release vote on the incubator mailing > > > list, licensing issues in the xtable-utilities module were found [1]. > > > Honestly, I did not check licensing that carefully in our first release > > > because I assumed the WIP disclaimer [2] would allow us more flexibility > > to > > > address these issues in future releases. However, it appears that was not > > > the case, as discussed in the mailing list. > > > > > > We need to address these licensing concerns for the xtable-utilities > > > artifact for our release, but this requires considerable effort; Vinish > > has > > > outlined the plan in this GitHub issue [3]. > > > One suggestion provided in the thread was to exclude the xtable-utilities > > > bundle, at least from the initial releases, to simplify the process. > > > > > > I'm +1 on excluding it from the first releases, but I would also like to > > > discuss more broadly whether we should consider including it in future > > > releases in its current form or whether we should explore other options. > > > The bundle is quite large (over 600MB) and includes many artifacts, which > > > means that any changes in dependency versions in the future will require > > > close monitoring for licensing issues. I'd appreciate input from others, > > > especially if they have experience in similar situations, on how they > > think > > > we should proceed. > > > > > > Thanks, > > > Jesús > > > > > > [1] https://lists.apache.org/thread/pcs3c7dq6bljzxmwlcyrwns9ndbfd23g > > > [2] https://github.com/apache/incubator-xtable/blob/main/DISCLAIMER-WIP > > > [3] https://github.com/apache/incubator-xtable/issues/536 > > >
