In case we can automate LICENSE.txt creation I’d still rather not have it as a blocker since the file is easy to update to reflect source releases and for other reasons I listed I’m not sure if its value.
Removing binary-ready release as a blocker will give us time to automate without the pressure of hurrying for release. What do others think? On Sep 5, 2016, at 10:45 AM, Pat Ferrel <p...@occamsmachete.com> wrote: Thanks Andy. RE “Only need to include one entry with the complete text of a license, everything else can just name the license.” So the copyright notice in the license is not important, only the license type? This is often the only important difference in the license from one dep to another. It sounds like your automation covered LICENSE.txt creation? or just inclusion in the binary? On Sep 5, 2016, at 9:59 AM, Andrew Purtell <andrew.purt...@gmail.com> wrote: 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 <p...@actionml.com> 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?
