incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [VOTE] Apache Drill 0.4.0-incubating release
Date Sat, 09 Aug 2014 12:52:08 GMT
On 8 August 2014 18:12, Marvin Humphrey <> wrote:
> Hi Ted,
> On Fri, Aug 8, 2014 at 9:44 AM, Ted Dunning <> wrote:
>> Also, I think that it is important that *all* dependency licenses be
>> documented in the source release.  Speaking as a consumer, I need to know
>> what dependencies will come in when I compile the code.  Marking the
>> dependencies as source inclusions or as compile time or as test
>> dependencies or as package dependencies is a fine thing to do, but my
>> strong feeling is that the license summary should be identical in the
>> source distribution as with the binary artifacts.
> That seems counter to the principle of the licensing documentation for
> a package reflecting the bundled bits and only the bundled bits,
> discussed many times on many lists.


> The licensing documentation for the canonical source release should
> reflect the exact content of the canonical source release.  The
> licensing documentation for any derived, downstream packages,
> including "convenience binaries" which get distributed on our mirrors,
> should reflect their own exact content. If derived packages bundle
> additional dependencies, it is likely that the licensing documentation
> will need to be different from that of the canonical source release.


> It is not necessary to including information about non-bundled
> dependencies in the licensing documentation of our canonical source
> releases, because a consumer building a composite product can examine
> the licensing of each package in turn as it gets added. We have to
> ensure that Apache projects don't have any mandatory dependencies with
> problematic licenses, but it's not necessary or desirable to document
> the complete dependency tree including non-bundled dependencies.  What
> if a requirement could be satisfied by multiple options with different
> licenses?  It would not be good to try to enumerate all the possible
> configurations in our licensing documentation. The only sane option is
> to document only what is bundled.

+1 to ensuring that NOTICE and LICENSE only relate to the bundle in
which they are included.

However, I don't see why projects should not provide a full list of
dependencies somewhere else.
For example in a README or BUILDING file.
Maven site builds can include dependency info extracted from the pom.

> Marvin Humphrey
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message