On Mon, Jun 27, 2016 at 11:20 PM, Justin Mclean <jus...@classsoftware.com> wrote:
> Hi, > > +1 binding > > But would be good clarify licenses of patches and fix up the slightly > confusing section in LICENSE. > > Thanks for your thorough check as always. Notes below: > I checked: > - incubating in name > - signature and hashes good > - DISCLAIMER exists > - NOTICE is good > - LICENSE I think is missing a boost [1] and again I think the end section > is confusing. Boost is MIT licensed and is in the source not just the > binary [1] > The LICENSE.txt has: thirdparty/boost_uuid/: Boost software license - See thirdparty/boost_uuid/LICENSE.txt which as I understand it is the preferred way to include MIT-style licenses in LICENSE.txt. That's based on http://www.apache.org/dev/licensing-howto#permissive-deps which says "add a pointer to the dependency's license within the distribution and a short note summarizing its licensing". > - all source files have Apache headers > - no unexpected binary files > - can compile from source > > There are a number of patches in [2], it’s not clear how they are licensed. > > Good point. This isn't new in this release, but we should address it. Do you think a README file in this directory would be sufficient? The patches are a mix - either they're backports from upstream repositories (in which case they're licensed the same as the source they are patching) or they are in a couple cases a small local patch to fix some integration with the Kudu build (in which case they're licensed as Apache, I suppose, but are trivial enough that we'd be fine licensing them with the modified source). What's the best way to handle this? -Todd
