incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC2
Date Sat, 22 Apr 2017 11:57:17 GMT
On Sat, Apr 22, 2017 at 7:25 PM, John D. Ament <>
> On Sat, Apr 22, 2017 at 6:41 AM Niclas Hedhman <> 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

> 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
> > above), and there is only Apache License to be considered.
> >
> > As for NOTICE, the ASF documentation you point to, basically says that
> > don't put in anything that is not bundled (i.e. just about nothing in
> > 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
> > itself in a single sentence, and think that the approach taken by Weex
> > 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.

Niclas Hedhman, Software Developer - New Energy for Java

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message