>I can definitely see the utility of the gradle wrapper and was pretty >disappointed that it had to be removed
It would be great if you add a comment to 570 on how the wrapper was useful for you. So far the case sounds like "compiled code is forbidden no matter what" and "Vladimir is the only one who needs gradle-wrapper.jar". I do not want to go in circles there, however, having more voices would help. >I feel it's more >productive to be pragmatic and pick our battles. Exactly. The case is closed, the compiled code is forbidden, so let us just remove compiled code from source releases and move on. >the discussion in LEGAL-570 [1], suggests that images, PDFs and >minified javascript is allowed AFAIK, the LEGAL team is Justin Mclean and Roman Shaposhnik. I do not see where they suggest that minified javascript is allowed in source releases. >Was the licenses folder >introduced when we moved to gradle? Exactly. License cleanup was one of the key improvements when I reworked the build to Gradle. For instance, the current build generates the proper license for **shaded** artifacts, and it bundles the relevant licensees inside the combined jar. >How does the community feel about >committing the license folder into git? I would be -0.99 for updating the licenses manually. They would go out of date as soon as the first dependency update is made. It would be nice if someone comes up with an automatic update of the files. For example, the generated license files might be stored under the relevant folders (e.g. /src/test/resources/license/..., /shaded/core/test/resources/license/...), then the build would fail if the expected license outcome does not match the actual one. What I do not like with putting "license with all the details to the root folder" the most is that Calcite release consists of **multiple** artifacts, and they might have different license files, so I do not understand which of them is supposed to be "the right one for putting in git root". Vladimir
