Julian>(Technically there are no binary releases, just artifacts. I stay corrected. The better term is "source package" and "compiled/binary package" which are both parts of the release.
Julian>Apache policy, as I understand it, does allow images in source releases I believe the policy is not mathematically defined. If you have a link that states "binary files must not be in source package" please let me know. Of course, I did not analyze all the tickets in LEGAL, however, LEGAL-288 does not forbid releasing gradle-wrapper.jar as a part of source package. --- For instance, Apache JMeter is a standalone desktop application, and you can't really build a workable application if all the icons and images were removed from the source package. The app would start, however, it would be very hard to use for the majority of the users. To my understanding, the intention is that the build artifacts should not be the primary part of the release and that there always should be a way to build the resulting binaries. However, to my best knowledge, excluding binary files from the source package is not really feasible. For instance, images might serve an important part in the documentation and in the application user interface. Julian>Not sure about .min.js, but it isn’t binary I believe the most important bit is the ability for humans to look inside and analyze. Of course, .min.js looks like a text file, however, it is written in such a way that humans can't really tell what the code is doing. Would it remove all the files in my filesystem if I run it? I don't know. I need a beautifier and IDE to analyze the behavior of the minified javascript. In that sense, .min.js is more or less the same as jar file, except jar file might be even better since most of the times class and variable names are not obfuscated in Java. Julian>It is also reasonable that when I browse the source in GitHub I should see the same LICENSE file that will be in the source release That would imply every third-party dependency update would trigger an update to the LICENSE file which means: 1) Every contributor that updates a dependency would bump into CI failure that reads "oh, you forgot updating LICENSE file" which will be annoying. 2) I test different third-party library versions. That might induce LICENSE-related failures when I update the dependency version without updating the version in the LICENSE. Do you mean I should always edit LICENSE file when editing dependency versions? That won't work. 3) If we validate LICENSE contents only during the release, then release managers might bump into the weird "oh, LICENSE file is out of date". That is why I believe, the way it works now is the least evil, however, you are welcome to improve it. The current implementation allows us to have a single base copy of LICENSE file, and it is used to build all the different licenses. For instance, calcite-avatica/shaded/core uses the same base LICENSE file and it adds the shaded third-party references there. If we put "the expected source artifact LICENSE" to the root of the repository, then: a) We would have to put "base license file for shaded artifacts" somewhere else b) People might assume that the LICENSE file covers all the entries in the Git repository. For instance, Calcite repository has site/fonts/ which have a license that is incompatible with ASF source artifact restrictions. If you put "source artifact license" to the root of apache/calcite repository, people might assume that everything in apache/calcite is AL2 compatible. Here's what I mean: https://github.com/apache/calcite/blob/8581f0a3fe9a4f079cb4d36f02121ae22118714c/release/build.gradle.kts#L145-L157 Well, of course, you could just remove site/fonts from the Git repository, whoever, that would paint us to a corner if we ever add a similar dependency. Vladimir
