accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [VOTE] Accumulo 1.7.2-rc1
Date Fri, 17 Jun 2016 22:21:16 GMT
On Fri, Jun 17, 2016 at 4:30 PM Christopher <ctubbsii@apache.org> wrote:

> On Fri, Jun 17, 2016 at 3:28 PM Josh Elser <josh.elser@gmail.com> wrote:
>
>>
>>
>> Mike Drob wrote:
>> > Thanks for taking a look, Sean.
>> >
>> > The LICENSE file in the source tarball refers to the BSD license and
>> > includes "for details see
>> > core/src/main/java/org/apache/accumulo/core/bloomfilter" and all files
>> > there (BloomFilter.java, DynamicBloomFilter.java, and Filter.java)
>> include
>> > the full 3-Clause BSD license in the header. Similarly, the MIT clause
>> has
>> > "for details see server/monitor/src/main/resources/web/flot" which has a
>> > LICENSE.txt
>>
>> I have absolutely no idea if this is "sufficient" or not. I can
>> understand Sean's confusion in not seeing relevant licenses in the
>> LICENSE file.
>>
>>
> According to http://www.apache.org/legal/release-policy.html#license-file,
> the license details must be included, but a pointer in the LICENSE file to
> those details elsewhere in the distribution is sufficient.
>

Sean, I noticed you committed the change you wanted to the LICENSE files,
in spite of my reference here indicating (more or less definitively) that
it wasn't actually necessary. The change itself doesn't bother me all that
much, but the fact that you proceeded while appearing to ignore my response
at this point in the conversation does.

I'd preferred you'd have at least made an attempt convince me that it was
still a good idea, even if it wasn't actually necessary. I don't think it
would have taken much to convince me (I wasn't strongly opposed), but the
fact that you didn't try, kinda makes me feel like you were going to do
what you wanted, regardless, and didn't actually care about the community
discussion. That doesn't sit well with me.

If my impression does not match your intent, please forgive me for
attributing false intentions. I can only describe my perspective.


>
>
>> > Regarding the crypto, according towww.apache.org/dev/crypto.html#inform
>> it
>> > looks like we need to place that disclaimer in the README and not the
>> > NOTICE file anyway. If you prefer this reading of the policy, can you
>> file
>> > a JIRA for making these changes and set it as a blocker? Thanks.
>>
>> Yeah, NOTICE is not the right place for this, AFAIU. I wouldn't think
>> this is a blocker, but something we should just remove from the
>> src-release's NOTICE file.
>>
>>
> Agreed. There are other superfluous stuffs in our NOTICE files which
> should also be removed (notices about inclusion of other ASF projects, for
> example; only transitive notices should be carried forward from these
> dependencies; the ASF project itself is satisfied by the catch-all notice
> line about including software developed at ASF).
>
> I think these are wrong (
> http://www.apache.org/dev/licensing-howto.html#mod-notice : "Do not add
> anything to NOTICE which is not legally required."), but also not a
> blocker.
>
>
>> > Mike
>> >
>> > On Fri, Jun 17, 2016 at 12:28 PM, Sean Busbey<busbey@cloudera.com>
>> wrote:
>> >
>> >> >  -1
>> >> >
>> >> >  good:
>> >> >
>> >> >  * verified checksums and signatures
>> >> >  * source artifact corresponds to referenced commit
>> >> >  * source builds correctly with Oracle JDK 1.7.0_80 / Apache Maven
>> >> >  3.3.9 (including unit tests, not including ITs)
>> >> >
>> >> >  bad:
>> >> >
>> >> >  * LICENSE in source tarball references the "3 clause BSD" and "MIT"
>> >> >  licenses but does not provide their text or a pointer to where the
>> >> >  text can be found in the artifact.
>> >> >  * NOTICE in the binary tarball doesn't include any of the encryption
>> >> >  notice stuff that's in the source tarball NOTICE (I don't know if
>> this
>> >> >  information is required in the NOTICE file, but it seems like we
>> >> >  should be consistent for things that are equally applicable in the
>> >> >  two).
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message