Re: [CANCEL][VOTE]Release Apache DolphinScheduler (Incubating) 1.3.0
Hi, If you want me to check it before you bring it to teh IPMC vote I can do that. Alternately you might want to use the WIP DISCLAIMER. [1] Thanks, Justin 1. https://incubator.apache.org/policy/incubation.html#work_in_progress_disclaimer - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[CANCEL][VOTE]Release Apache DolphinScheduler (Incubating) 1.3.0
Thank you very much for your vote, but there are still some license and notice issues. So decide to cancel this vote and fix related issues. 1. some missing information in NOTICE. 2. incorrect license header in ./dolphinscheduler-ui/src/sass/common/_animation.scss 3. other LICENSE and NOTICE issues need to be checked In addition to the above problems, we will also do some other checks. -- DolphinScheduler(Incubator) PPMC BaoLiang 鲍亮 leon...@apache.org
Re: [VOTE]Release Apache DolphinScheduler (Incubating) 1.3.0
@Justin thank you for checking, we will cancel this vote, and check all the licenses and notices seriously. Justin Mclean 于2020年6月14日周日 上午10:10写道： > Hi, > > -1 (binding) as LICENSE and NOTICE are missing information and this file > [3] incorrectly has an ASF header (it’s MIT license). Similar issues were > brought up last release. > > I checked: > - incubating in nam > - LICENSE is missing license for [3] > - NOTICE in missing information from [1] See [2] > - No unexpended binary files > - All ASF files have ASF headers and this MIT licensed file incorrectly > has one [3] > - Can compile from source > > Thanks, > Justin > > > 1. https://github.com/mybatis/mybatis-3/blob/master/NOTICE > 2. https://www.apache.org/dev/licensing-howto.html (bundling an > apache-2.0-licensed dependency) > 3../dolphinscheduler-ui/src/sass/common/_animation.scss > > > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > > -- DolphinScheduler(Incubator) PPMC BaoLiang 鲍亮 leon...@apache.org
Re: [VOTE] Release Apache NLPCraft (Incubating) 0.6.1
Hi, -1 (binding) due to licensing concerns. You might want to consider using the WIP disclaimer I checked: - incubating in name - signatures and hash correct - DISCLAIMER exists - LICENSE is missing a number of 3rd party licenses - NOTICE mentions MIT licensed software there’s no need to do this - No unexpected binary files (but it would still be a good idea to rename that .bin files) - Can compile from source I think the a number of licensing issue that need to be resolved here: - Where did this geo son files come from? [1] it seem it might be from here? (which states it’s legal status is dubious) - This file [2] come from the moby project and need to be mentioned in LICENSE - These file [4][5][6][7] are of unclear origin and license. One come from [8] where the license is blank. - This file [9] copied from [10] which terms of use state " User’s personal, non-commercial use, without any right to resell or redistribute them or to compile or create derivative works therefrom” which would be incompatible with the ALv2. - A simpler situation exists with [11] as with [9] Thanks, Justin 1. ./nlpcraft/src/main/resources/geo/* 2. https://github.com/johan/world.geo.json 3. ./nlpcraft/src/main/resources/moby/* 4. ./nlpcraft/src/main/resources/opennlp/en-lemmatizer.dict 5. ./nlpcraft/src/main/resources/opennlp/models.txt 6. ./nlpcraft/src/main/resources/spell/dictionary.json 7. ./nlpcraft/src/main/resources/synonyms/synonyms.json 8. https://github.com/richardwilly98/elasticsearch-opennlp-auto-tagging 9 ./nlpcraft/src/main/scala/org/apache/nlpcraft/server/geo/tools/unstats/codes.txt 10. http://unstats.un.org/unsd/methods/m49/m49alpha.htm 11. ./nlpcraft/src/main/scala/org/apache/nlpcraft/server/geo/tools/unstats/subcontinents.txt - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE]Release Apache DolphinScheduler (Incubating) 1.3.0
Hi, -1 (binding) as LICENSE and NOTICE are missing information and this file [3] incorrectly has an ASF header (it’s MIT license). Similar issues were brought up last release. I checked: - incubating in nam - LICENSE is missing license for [3] - NOTICE in missing information from [1] See [2] - No unexpended binary files - All ASF files have ASF headers and this MIT licensed file incorrectly has one [3] - Can compile from source Thanks, Justin 1. https://github.com/mybatis/mybatis-3/blob/master/NOTICE 2. https://www.apache.org/dev/licensing-howto.html (bundling an apache-2.0-licensed dependency) 3../dolphinscheduler-ui/src/sass/common/_animation.scss - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache DataSketches-cpp 2.0.0-incubating-rc4
Hi +1 (binding) I checked: - incubating in name - signatures and hashes are fine - LICENSE and NOTICE are fine - No unexpected binary files - All source files have ASF headers - Don't have a suitable environment setup to compile Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Annotator (incubating) version 0.1.0 (-rc.4)
Hi, +1 (binding) I checked: - incubating in name - signature and hashes are fine - LICENSE is perhaps missing something e.g. license for [1] - NOTICE is fine - DISCLAIMER exists but please list why you are using the WIP disclaimer - No unexpected binary files - All source files have ASF headers - Unable to compile on OSX but assume that’s not a supported platform. It would be good to mention this in the README. You included “.git” directory in the source release was this intentional? It includes this file [1] which I’m not sure what the license is. You might also want to make this [2] be more in line with [3]. Thanks, Justin 1. .git/hooks/pre-rebase.sample 2. https://www.npmjs.com/org/annotator 3. https://cwiki.apache.org/confluence/display/INCUBATOR/Distribution+Guidelines - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache NLPCraft (Incubating) 0.6.1
+1 (binding) carrying my dev vote forward. I'll note here for anyone running the test suite under Windows - there seems to be some issues on some systems that are being looked at in parallel and testing using WSL2 seems to avoid the problem. Cheers, Paul. On Sat, Jun 13, 2020 at 4:30 AM Aaron Radzinski wrote: > Hello all, > This is a call for a vote to release Apache NLPCraft (incubating) version > 0.6.1. Apache NLPCraft is a library for adding a natural language interface > to any application. > > The Apache NLPCraft community has voted on and approved a proposal to > release Apache NLPCraft (Incubating) version 0.6.1. We would like to > request the Incubator PMC members review and vote on this incubator > release. > > Release information: > 1. PPMC vote result thread: > > https://mail-archives.apache.org/mod_mbox/nlpcraft-dev/202006.mbox/%3ccacwejt91kdfkqntbb9msekqo4sky5_vsqwyobft57eeibap...@mail.gmail.com%3e > 2. Release location: > https://dist.apache.org/repos/dist/dev/incubator/nlpcraft/nlpcraft/0.6.1/ > 3. Git tag: https://github.com/apache/incubator-nlpcraft/tree/v0.6.1 > 4. JIRA issues fixed in release: > https://issues.apache.org/jira/projects/NLPCRAFT/versions/12347775 > 5. KEYS file: > https://dist.apache.org/repos/dist/release/incubator/nlpcraft/KEYS > > The vote will be open for at least 72 hours or until a necessary number of > votes are reached. > > Please vote accordingly: > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove with the reason > > Thank you, > -- > Aaron Radzinski >
[DISCUSS] When to add Apache Headers to Third Party Code [WAS] Re: [MENTORS] PPMC case-by-case decision for major modifications of third-party work guidance
Hi, I agree there does not appear to be consensus on when it's appropriate to add Apache License Headers to Third Party code across projects. Here is Justin's email that request the Apache Headers removed [1] - file copyright NumPy Developers [6] this file look to incorrectly have an ASF header on it 6. ./src/operator/numpy/np_einsum_path_op-inl.h We want to make the choice that will be most sustainable for the project and most correct for the situation. Based on the emails I linked in the prior email it does seem like the cases where dual headers are appropriate is when there are Major Modifications. In the case of np_einsum_path_op-inl.h The file is derived from the implementation in Numpy [2]. If the implementation in Numpy changes will this file change? If so then the community will be tasked with continuing to re-port the changes over that is always based on Numpy so it may be more appropriate to just keep the Numpy license. Will MXNet likely evolve this file in a way that it's no longer resembles the Numpy implementation (Major Modification)? If so it may be better to keep the Apache Header as going forward the file will represent the work of the MXNet community not that of Numpy. Hopefully the above helps clarify my perspective on how to determine case by case. I don't see the dual license state as the simpler case in all situations. I don't believe you would have to get the original committer to relicense the file to you in order to remove the additional license. I believe the PPMC has all the authority it needs to change the file. I'd be interested to hear if this is a position that the rest of the Mentors/Incubator agree with. I know Hen has been involved in some of the conversations in support of dual licenses. Has this ever required escalation to an actual Lawyer in Legal? Or have these determinations been low enough risk that we are comfortable with our PMC making best effort decisions based on the ASF guidelines? - Bob [1] https://lists.apache.org/thread.html/rb83ff64bdac464df2f0cf2fe8fb4c6b9d3b8fa62b645763dc606045f%40%3Cgeneral.incubator.apache.org%3E [2] https://github.com/numpy/numpy/blob/master/numpy/core/einsumfunc.py On 6/12/2020 7:20 PM, Leonard Lausen wrote: > Thank you Bob for the elaboration. PPMC would like to minimize complexity, > that's why we ask for your recommendation. > > If it's easiest to just keep the original license header, we can do that. Do > we > need the contributor to re-license their contribution, or is the contribution > already available under both licenses as both license headers were included by > the contributor and the ASF header can simply be deleted? > > Reading through the threads you referenced, there does not seem to be a strong > consensus in the ASF about how to handle this situation. For example, quoting > Roman Shaposhnik [2] in support of just putting 2 License Headers for > simplicity: > >> Hm. This is tricky, now that I re-read the language of the ASF license >> header I'm not sure anymore. I *think* the language there should allow >> you to slap said header on a compatible license code. >> >> Besides, the alternative is much messier: every time somebody touches >> that file he/she needs to decide whether it is time for an ASF header >> or not. >> >> I *think* (but I'd love for old-timers to chime in and correct me) that #3-5 >> were written from though-shall-not-fork-communities perspective. > Can we follow this approach (keep 2 License headers) for simplicity (assuming > removal of ASF header will require extra steps)? > >> With respect to einsumfunc.py [5] vs np_einsum_op.cc [6] if this is in >> fact a port where the behavior was copied/derived directly from numpy I >> could see that as supporting Justin's case that the Apache header should >> be removed. However that is just my opinion. > Which email of Justin are you referring to? > > Best regards > Leonard > > > [1]: http://www.apache.org/legal/src-headers.html#purpose > [2]: > https://lists.apache.org/thread.html/ef46b1d0a3dd865d27a33c290430d892d3373d4bc5e27b5f06c7bcda%401451951295%40%3Cgeneral.incubator.apache.org%3E > > > On Wed, 2020-06-10 at 21:39 -0500, Bob Paulin wrote: >> First general disclaimer: I am not a lawyer. >> >> Second Disclaimer with an engineer hat on we want to avoid copying third >> party code into the project since it increases the amount of maintenance >> in a sense from a code standpoint and from a licensing standpoint. If >> at all possible it is preferable to either link or try to find a way to >> integrate your tweaks back into the other projects before taking on the >> burden of housing the code in MXNet. I do hope these options were >> considered or are being looked at for refactoring in the project since >> it will help the long term viability of the project. >> >> Now to your question. Similar situations have been discussed both on >> legal [1] and on incubator [2][3]. It may be useful to review some of >> thes
