I don't have an opinion, but would like to list pros and cons of doing so. The pro of doing so is that it indeed simplifies the release process, as these additional dependencies becomes category-B level dependencies as in https://www.apache.org/legal/resolved.html
The con of doing so is that it brings additional burden to the users of the software to check the license of these dependencies, in some sense, including these information in the license actually gives an extra level of transparency. The copyright message in some of the dependencies are a bit unfortunate, one potential way to run the check is to write a python script to go through the files and detect the line Copyright and cross match and add them. Note that good models to follow are - hadoop: https://github.com/apache/hadoop/tree/trunk/licenses - flink: https://github.com/apache/flink Each of the repo have a licenses folder that contains licenses, and things points to them. I am not a lawyer, but the case for ps-lite seems can be resolved as long as we can confirm these files follows Apache-2.0, as https://www.apache.org/licenses/LICENSE-2.0 only requires us to redistribute the license and anything in the NOTICE, but we do not have the obligation to list all the copyright messages in the source content. TQ On Fri, Jan 17, 2020 at 11:10 AM Yuan Tang <terrytangy...@gmail.com> wrote: > +1 > > On Fri, Jan 17, 2020 at 1:59 PM Chris Olivier <cjolivie...@gmail.com> > wrote: > > > +1 > > > > On Fri, Jan 17, 2020 at 10:19 AM Lausen, Leonard > <lau...@amazon.com.invalid > > > > > wrote: > > > > > Dear MXNet community, > > > > > > as per recent mail on gene...@incubator.apache.org [1] there are a > > number > > > of > > > licensing issues in MXNet 1.6rc1. Based on anecdotal evidence I believe > > > there > > > has been no release so far without any licensing issues, which is a > > > blocker to > > > MXNet graduating from it's incubating status. One contributing factor > is > > > that we > > > bundle 3rdparty source code in our releases [2]. > > > > > > One key factor is that 3rdparty projects don't always enforce licensing > > > best > > > practice in the way we do. For example, 3rdparty/ps-lite doesn't > enforce > > > license > > > headers in the source files and there has been confusion about the > > license > > > of > > > recent contributions by ByteDance (See [1]). > > > > > > To avoid such licensing issues in MXNet releases a simple solution is > to > > > stop > > > distributing the 3rdparty code in our source releases. Instead, we can > > > adapt our > > > buildsystem to download 3rdparty code as part of the build > configuration > > > process. CMake makes this very easy with the FetchContent module [3]. > > > > > > For development purpose involving changes to the 3rdparty source or > build > > > systems that can't access the internet, there are easy means for > > > specifying the > > > location of local sources (instead of downloading), via the > > > FETCHCONTENT_SOURCE_DIR_<someName> variable [4]. > > > > > > Would there be any concerns about such approach? Obviously it can only > be > > > fully > > > implemented as soon as the CMake build system is feature complete and > the > > > Makefile build can be dropped. (Note that the Makefile build is being > > > deprecated > > > and removed as part of MXNet 2 roadmap [5]) > > > > > > Best regards > > > Leonard > > > > > > [1]: > > > > > > > > > https://lists.apache.org/thread.html/rb83ff64bdac464df2f0cf2fe8fb4c6b9d3b8fa62b645763dc606045f%40%3Cgeneral.incubator.apache.org%3E > > > [2]: See the .tar.gz files at > > > https://incubator.apache.org/clutch/mxnet.html > > > [3]: https://cmake.org/cmake/help/latest/module/FetchContent.html > > > [4]: https://cmake.org/pipermail/cmake/2019-June/069709.html > > > [5]: https://github.com/apache/incubator-mxnet/issues/16167 > > > > > >
