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 <johndam...@apache.org> wrote: > On Sat, Apr 22, 2017 at 9:43 PM Niclas Hedhman <nic...@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 <johndam...@apache.org> > > wrote: > > > > > 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 > > > > > > > > > > > > > > > -- > > Niclas Hedhman, Software Developer > > http://polygene.apache.org - New Energy for Java > > > -- sospartan Phone:13588488290 HangZhou
