I won't weigh in on the question at hand but I'd like to make a couple of clarifications for what it is worth:
> This yielded 166 deps, so this implies we need to include 166 licenses and > copyright notices in LICENSE.txt. There are some available simplifications: - Only need to include one entry with the complete text of a license, everything else can just name the license. - Where there are multiple artifacts coming from a single project, like Hadoop, only one entry for the project is needed. > Donald is looking at automating this but I’m personally dubious As I think I've mentioned before here we have successfully automated this for HBase (based on automation done by yet other Apache projects) so I hope you'll take my advice and evidence based assertion it can be done. Caveat: we use maven not SBT as build framework. > > On Sep 5, 2016, at 9:43 AM, Pat Ferrel <[email protected]> wrote: > > This weekend I tracked down all out deps, which required a few scripts to > process sbt output. This yielded 166 deps, so this implies we need to include > 166 licenses and copyright notices in LICENSE.txt. As I read the Apache > guidelines this should be the license that goes with the version we include > since the copyright owner of license may have changed in newer versions. > > This may be near impossible to maintain by hand if we have frequent > dependency upgrades and frequent releases. Donald is looking at automating > this but I’m personally dubious about this because it require all 166 deps > have maintained their licenses in artifacts for all versions we might use. > > A source release requires that *only* the source included be reflected in > LICENSES.txt. This would be ~0, I think a couple things are included. > > Several things lead me to favor a source-only release: > 1) 166 licenses needed for binary ~0 needed for source—I’d rather we spend > time on things that add more value > 2) I have never used the binary release. Any version of a source download and > `./make-dirstribution` works universally. > 3) our install.sh now installs source and builds it for the user. This is > good because we can use the same script for unreleased -SNAPSHOT versions > sitting in the `develop` branch. > 4) outside of instructions for downloading and installing the binary that do > not yet exist afaik, there would be no obvious way for the user to get the > binary. > 5) indirectly any delay to release is getting to be a serious problem. We > haven’t had a well supported release from the main project since close on a > year ago and work on new features is being delayed. > 6) we can do a source only release now and be clean of the license issue as > far as the IPMC is concerned. We can add binary when we have a better answer > to automation. In other words why hold the release for binary? > > Since this decision will affect the project for as long as it is in > incubation. I’d like to see what others think. I believe we can release now > if we do source-only. > > Source only, or source & binary?
