incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sospartan <sospar...@gmail.com>
Subject Re: [VOTE]: Apache Weex-incubating Release 0.12.0-RC2
Date Mon, 24 Apr 2017 03:09:00 GMT
john,
I'll take the work and make NOTICE and LICENSE(s) right.
Thanks for this discussion, which will be a good lesson for  our newbies.

The full-licensed file(SimpleWeexActivity.java) is in old branch, we have
fix that in dev. I'll push to master after we have our first RC.




On Sun, Apr 23, 2017 at 7:26 PM, John D. Ament <johndament@apache.org>
wrote:

> On Sat, Apr 22, 2017 at 9:43 PM Niclas Hedhman <niclas@hedhman.org> wrote:
>
> > John,
> > thanks for pointing me to the issue. I argue against Marvin on it, based
> on
> > "this is a tool" that is made conveniently available for those who are
> not
> > paranoid.
> >
> > NOTICE; Ok, let's rename the file.
> > NOTICES-POSSIBLY-NEEDED-FOR-BINARY-DISTRIBUTION
> >
> >
> Sure - but there's still issues with it.  And you still need a NOTICE file
> in your source distribution.
>
> Here's an example: fastjson is listed in the NOTICE file.  If I look at
> fastjson's repository, and build artifacts, there's no NOTICE file
> included.  As a result, there should be no entry in the NOTICE file for
> this dependency.  https://github.com/alibaba/fastjson
>
> Likewise, for each MIT licensed artifact, an entry in LICENSE should be
> made pointing to the MIT license for that product.  Same applies to each
> BSD-3-Clause licensed work included in the binary.  Same applies to other
> non-Apache-2 licensed products (Apache 2 is already included, so you're
> good).  Apache 2 products are meant to carry NOTICE files for copyright to
> avoid repeating licenses.
>
> At the same time, dexposed has a ridiculously long NOTICE file - completely
> incorrectly build, but its all in there.  This may technically mean the
> entire contents have to be included in your binary NOTICE file:
> https://github.com/alibaba/dexposed/blob/master/NOTICE
>
> If you need me to, I can go into each of your dependencies and give a heads
> up, but would recommend that the PPMC does this, based on the assembling
> guide I've linked to already.
>
>
> > Ok?
> >
> >
> I thought about your points a bit more last night, and conversely I want to
> explain why its actually more of a burdon.  Suppose that for some reason I
> found the contents of this class to be useful and wanted to use it alone in
> my work:
> https://github.com/apache/incubator-weex/blob/master/
> android/commons/src/main/java/com/alibaba/weex/commons/
> SimpleWeexActivity.java
> .
> By having an extremely verbose NOTICE, as a user of this file alone, I have
> to carry all of that along with me.
>
> I also just noticed that your files are including the full license text of
> the apache license in each file.  We typically use the abbreviated version.
>
>
> >
> > On Sun, Apr 23, 2017 at 8:01 AM, John D. Ament <johndament@apache.org>
> > wrote:
> >
> > > On Sat, Apr 22, 2017 at 7:57 AM Niclas Hedhman <niclas@hedhman.org>
> > wrote:
> > >
> > > > On Sat, Apr 22, 2017 at 7:25 PM, John D. Ament <
> johndament@apache.org>
> > > > wrote:
> > > > >
> > > > > On Sat, Apr 22, 2017 at 6:41 AM Niclas Hedhman <niclas@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
> > > >
> > >
> >
> >
> >
> > --
> > Niclas Hedhman, Software Developer
> > http://polygene.apache.org - New Energy for Java
> >
>



-- 
sospartan
Phone:13588488290
HangZhou

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