incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Shaposhnik <>
Subject Re: [VOTE] Apache HAWQ (incubating) Release
Date Tue, 09 Aug 2016 23:10:46 GMT
On Tue, Aug 9, 2016 at 3:52 PM, Justin Mclean <> wrote:
> Hi,
>> If you're asking why adding ALv2 header is against the letter of the
>> policy, the answer is simple.
>> Quote:
>>    "3.  Do not add the standard Apache License header to the top of
>> third-party source files.”
> In the case when they are not actually ALv2 licensed. It assumed that any files that
is APLv2 license would already have a APLv2 header.

Well they are not. They are available under the PostgreSQL license overall
and *may* have originated under a different (but still very much compatible
with ALv2 -- so no alarm bells ;-)) license.

>> Because I actually don't know what the original license on the file is.
> That should ring alarm bells.

Why? It would be perfectly fine for PG project to include, lets say an MIT
source code. MIT is a compatible license. Whether the fact that the code
was originally licensed under MIT is reflected in the header of that
file is an open question. That's why I don't feel comfortable putting
the overall
PG  licensed header there on my own. It may not be, strictly speaking illegal,
but it makes me uncomfortable. And since the NOT putting it there has no
downside (aside from making scanning a bit more complex) I'd prefer for the
file to remain unmodified.

>> IOW, I can't add ALv2 header because of #3 on the policy
> No you can’t add ALv2 because you don’t know that the file is licensed under ALv2.

I think we're talking slightly past each other -- I told you I do KNOW that they
are licensed under the different ALv2 compatible license.

> Given the age of some of the files (predating when ALv2 was created) it’s very likely
that they are not.

Again, no reason to speculate -- we do KNOW what the overall license on
these files are -- that is PostgreSQL license. We may not know what the original
license on each individual file was, but we do know that it was compatible
with the PostgreSQL license.

>> I think documenting it in LICENSE should be enough, no?
> Yep that’s one one of doing it. Again I don’t thing everything has to be solved for
the next release,
> but documenting the issues/what may be missing is probably the best way to go.

Sounds good!


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

View raw message