On Sat, Apr 22, 2017 at 7:57 AM Niclas Hedhman <nic...@hedhman.org> wrote:
> On Sat, Apr 22, 2017 at 7:25 PM, John D. Ament <johndam...@apache.org> > wrote: > > > > On Sat, Apr 22, 2017 at 6:41 AM Niclas Hedhman <nic...@hedhman.org> > wrote: > > > > > Note on gradle-wrapper.jar, > > > Agreed, and this is mostly my argument as well. However, in *nix the JAR > > will get downloaded automatically if not present. On windows, you need > to > > pre-install gradle. > > Where did you get this idea? The gradlew launches the Java program inside > the gradle-wrapper.jar which in turn downloads the full Gradle distro if > not present already. I have not heard neither that the gradlew would > download the wrapper jar, nor that the gradle-wrapper does not work on > Windows. > > I must have seen a custom built version of gradlew then. > > > The argument I've seen from present VP Legal is that the JARs may have > > viruses in them, or contain other malware. > > That was the silliest reason I have heard in a long time. With that > argument, we only allow source distributions, only allow to use tools that > are built from source recursively back through time... Yeah! Right... now, > there are a few projects that needs that, such as the Bitcoin blockchain > toolchain, as they distrust everything, and settled on some binary from > decades ago with a known hash as the starting point. In any event, ASF > would collapse under the "they may contain malware" banner of paranoia. > > I don't buy it, since I trust my fellow folks at ASF rather than assume > malevolence from everyone. > > I don't disagree with you. And now may be a good time to bring this back up. But for now, its not allowable in the release. See also https://issues.apache.org/jira/browse/LEGAL-288 > In this particular case, I don't think that gradle-wrapper.jar ever > changes, so committing a new version would set off red flags, at least with > me (used Gradle for about 7 years now). A small script that traverse all of > Apache GitHub and compares them all?? > > > > > > Note on LICENSE; > > > IIUIC, the source distribution doesn't ship any dependencies (except > Gradle > > > above), and there is only Apache License to be considered. > > > > > > As for NOTICE, the ASF documentation you point to, basically says that > a) > > > don't put in anything that is not bundled (i.e. just about nothing in > the > > > source release), b) no burden on downstream users. HOWEVER, by > excluding > > > the list of dependencies that will be in the resulting product, we > would > > > actually increase the burden of downstream users as they would need to > > > figure out what licensing requirements will come out of it all, if they > > > choose to distribute. > > > Therefor, I would argue that documentation is in this case arguing > against > > > itself in a single sentence, and think that the approach taken by Weex > is > > > appropriate. > > > > > > > I disagree. I think you're thinking of source release vs binary release. > > Weex has only presented a source release. > > I am aware of that, but the documentation says "make it easier for the > downstream" and by "excluding all non-bundled, but required, dependencies > from NOTICE" we actually make it harder for the downstream. And sorry, I > place "common sense" and "tribal knowledge" way over someone writing a > documentation and perhaps didn't realize the consequences. I never stop > thinking, just because I read something somewhere. > > I'm not sure what a valid response to this would be. I don't believe we should be taking into account ease of use for downstream consumers, however at the end of the day those downstream consumers of a source release eventually get a binary and that binary should include proper data. What I am trying to say is that these contents look more appropriate for the binary release, which would be a satisfactory use case for downstream consumers. > > Cheers > -- > Niclas Hedhman, Software Developer > http://polygene.apache.org - New Energy for Java >
