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. > 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. 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. Cheers -- Niclas Hedhman, Software Developer http://polygene.apache.org - New Energy for Java
