Cub license issue

[roywei]

As pointed out here:
https://mail-archives.apache.org/mod_mbox/incubator-general/201907.mbox/%3CF9383AEE-5693-40ED-BE1C-C109F3D219B7%40classsoftware.com%3E

There is a file in Nvidia cub submodule with a license that does not allow redistribution:https://github.com/NVlabs/cub/blob/v1.8.0/test/half.h

This will prevent MXNet from using it. While I raised an issue on NVlab github, I would propose the following if there is no response

1. change submodule cub to use v1.7.4 instead of v1.8, 1.7.4 and older does not have this file:
   https://github.com/NVlabs/cub/tree/v1.7.4/test. Not sure if v1.7.4 has the historical problems that lead us to make a snap shot of it

2. revert Change CUB submodule to track Nvidia CUB project. #13322 which will go back to use dmlc/cub and it's v1.7 without the file.

cc @frankfliu

[mxnet-label-bot]

Hey, this is the MXNet Label Bot.
Thank you for submitting the issue! I will try and suggest some labels so that the appropriate MXNet community members can help resolve it.
Here are my recommended labels: Feature

[roywei]

@mxnet-label-bot add [Licenses]

[marcoabreu]

@DickJC123 @ptrendx fyi

[roywei]

We have got help from the author, thanks @ptrendx!

https://lists.apache.org/thread.html/e811d47ffc61a0dd2b6ba5254632ecdf1d04282ab4040c87480e9cbe@%3Cgeneral.incubator.apache.org%3E

Next step is to resolve this before the next release, so we can wait for cub to release a new version and update our submodule

[TaoLv]

Hi @roywei @ptrendx is this got fixed on the master branch? Do we need to include the fix to 1.5.1 patch release?

[roywei]

we can update our submodule to latest cub commit

[samskalicky]

@ptrendx heres the build failure:

execution-space-call -std=c++11 -Xcompiler -D_FORCE_INLINES -O3 -ccbin g++  -gencode=arch=compute_52,code=sm_52 -gencode=arch=compute_70,code=sm_70 -Xcompiler "-DMSHADOW_FORCE_STREAM -Wall -Wsign-compare -g -Werror -O3 -DNDEBUG=1 -I/work/mxnet/3rdparty/mshadow/ -I/work/mxnet/3rdparty/dmlc-core/include -fPIC -I/work/mxnet/3rdparty/tvm/nnvm/include -I/work/mxnet/3rdparty/dlpack/include -I/work/mxnet/3rdparty/tvm/include -Iinclude -funroll-loops -Wno-unused-parameter -Wno-unknown-pragmas -Wno-unused-local-typedefs -msse3 -mf16c -I/usr/local/cuda/include -DMSHADOW_USE_CBLAS=1 -DMSHADOW_USE_MKL=0 -DMSHADOW_RABIT_PS=0 -DMSHADOW_DIST_PS=0 -DMSHADOW_USE_PASCAL=0 -DMXNET_USE_OPENCV=1 -I/usr/include/opencv   -fopenmp -DMXNET_USE_OPENMP=1 -DMXNET_USE_OPERATOR_TUNING=1 -DMSHADOW_INT64_TENSOR_SIZE=0 -DMXNET_USE_LAPACK -DMSHADOW_USE_CUDNN=1 -DMXNET_USE_BLAS_OPEN=1  -DMXNET_USE_DIST_KVSTORE -I/work/mxnet/3rdparty/ps-lite/include -I/work/mxnet/deps/include -I/work/mxnet/3rdparty/nvidia_cub -DMXNET_ENABLE_CUDA_RTC=1 -DMXNET_USE_NCCL=0 -DMXNET_USE_LIBJPEG_TURBO=0" src/operator/tensor/elemwise_binary_scalar_op_logic.cu
/work/mxnet/3rdparty/nvidia_cub/cub/device/dispatch/dispatch_reduce.cuh(362): error: use the "typename" keyword to treat nontype "std::iterator_traits<_Iterator>::value_type [with _Iterator=InputIteratorT]" as a type in a dependent context

/work/mxnet/3rdparty/nvidia_cub/cub/device/dispatch/dispatch_reduce.cuh(363): error: use the "typename" keyword to treat nontype "std::iterator_traits<_Iterator>::value_type [with _Iterator=OutputIteratorT]" as a type in a dependent context

/work/mxnet/3rdparty/nvidia_cub/cub/device/dispatch/dispatch_reduce.cuh(683): error: use the "typename" keyword to treat nontype "std::iterator_traits<_Iterator>::value_type [with _Iterator=InputIteratorT]" as a type in a dependent context

/work/mxnet/3rdparty/nvidia_cub/cub/device/dispatch/dispatch_reduce.cuh(684): error: use the "typename" keyword to treat nontype "std::iterator_traits<_Iterator>::value_type [with _Iterator=OutputIteratorT]" as a type in a dependent context

[szha]

@ciyongch we missed updating this in 1.7.0. I think it's a minor issue that we proceeded with previous releases. We will still need to address this in the next release when we try to remove the DISCLAIMER-WIP.

[ciyongch]

Hi @szha, we didn't update this as I checked with @roywei for this issue before the code freeze in here #15963 (comment) , so I just took this case same as the previous release version (#15547 has similar status)