Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (athena.apache.org: domain of mdrob@cloudera.com designates
 209.85.214.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAL5zq9bWwwZ+vvaOPdjUxzypZjFzhdHc9utx0nhu_EX4HLs7GQ@mail.gmail.com>
References: 
 <CAFAMeY+=Qrwy836dWq4QZGS-aw8N1nc+K0cHepL-djjqjNi+PQ@mail.gmail.com>
 <CAL5zq9bWwwZ+vvaOPdjUxzypZjFzhdHc9utx0nhu_EX4HLs7GQ@mail.gmail.com>
From: Mike Drob <madrob@cloudera.com>
Date: Mon, 28 Apr 2014 17:23:13 -0400
Message-ID: 
 <CAFAMeY+1Ku5BTUaF8XG_yDsy4P5Y863Vh3wRQkr4CRe+b76g4A@mail.gmail.com>
Subject: Re: [DISCUSS] Accumulo 1.6.0-RC4
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=089e015387027a20fe04f820ede0

--089e015387027a20fe04f820ede0
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 28, 2014 at 5:12 PM, Christopher <ctubbsii@apache.org> wrote:

> On Mon, Apr 28, 2014 at 3:24 PM, Mike Drob <madrob@cloudera.com> wrote:
> > Forking thread for discussion.
> >
> > On Mon, Apr 28, 2014 at 2:51 PM, Christopher <ctubbsii@apache.org>
> wrote:
> >
> >> On Mon, Apr 28, 2014 at 12:20 PM, Mike Drob <madrob@cloudera.com>
> wrote:
> >> > -1
> >> >
> >>  >
> >> > * Missing licence headers:
> >> > ** README
> >> > ** conf/examples/crypto/readme.txt
> >> > ** test/compat/japi-compliance/README
> >> > ** test/system/continuous/ScaleTest.odp
> >> > **
> >> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.odg
> >> >
> >> > **
> >> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.pdf
> >> >
> >> > **
> >> > docs/src/main/latex/common/state_diagrams/tablet_states.odg
> >> >
> >> > ** docs/src/main/latex/common/state_diagrams/tablet_states.pdf
> >>
> >> The rat check plugin typically ignores README/NOTICE/LICENSE files as
> >> category "N" (for Notices). That's why it ignored the
> >> japi-compliance/README and conf/examples/crypto/readme.txt. I think
> >> it's expected that the LICENSE file covers them. At the very least, I
> >> don't think they contain anything copyrightable that would necessitate
> >> a license. But, for consistency, maybe we should add it anyway? I'm
> >> not sure that consistency argument warrants blockage (for me), though.
> >>
> >> http://www.apache.org/legal/src-headers.html#faq-exceptions
> >
> > The README has plenty of intellectual creativity in its content, and is
> > therefore subject to copyright claims. It could be argued that the other
> > two README files are short enough to not have copyright-able content, but
> > it doesn't sound like that's the case you want to make.
> >
> > There is also lengthy discussion on
> > https://issues.apache.org/jira/browse/LEGAL-114 but again, that is
> focused
> > on small, non-creative files. Our README does not fall into that
> category.
> >
>
> Agreed. Sorry, I meant the two smaller files didn't have enough. I had
> combined two paragraphs for succinctness and this distinction got
> lost.
>
> We had previously ignored other README files, but then added licences to
them in ACCUMULO-2534 when rat-plugin complained. I believe the assumption
is that README files are generally minimal, but I do not want to speak for
the developers in this case.

I strongly believe that our README needs a licence header. I am under the
impression that it never had one.


>  >
> >> The rest were ignored because the rat check does not check binary
> >> files. These files should be covered by the LICENSE/NOTICE files.
> >> Binary document files may or may not be capable of supporting license
> >> metadata, in general, but I think the coverage by the LICENSE/NOTICE
> >> files is sufficient. However, we can do additional things with these
> >> files. The ScaleTest.odp could probably be converted to markdown, with
> >> a license header. The state_diagrams are not used anywhere in the
> >> LaTeX generation (leftover from old developer manual?), and could
> >> probably be deleted or moved to the website or wiki, if they are
> >> needed at all. I'm not sure which option is best. However, again, I'd
> >> consider the LICENSE/NOTICE files sufficient, so as not to block,
> >> especially since they didn't block any previous release (presumably
> >> because LICENSE/NOTICE covered them), and they've been around awhile.
> >>
> >
> > I do not agree that "in general, coverage by LICENSE files is sufficient.
> > If that were the case, then we would not need to put headers on our
> source
> > files, on our markdown files, on our example configuration files, etc...
> >
> > I also do not accept "they've been around for a while and nobody noticed
> > it" as a reason to continue to ignore them. Either they are a violation,
> or
> > they are not. This is not to say that we have been perfect in the past,
> but
> > instead we correct mistakes when they are brought to attention.
>
> No, the "in general" part I was referring to only was for binary
> files, which cannot be labeled without altering the contents. That is
> not the case here (if the document formats allow metadata), but a
> general explanation of the assumptions that the RAT check makes. I
> also agree precedent should not determine the correct course of
> action. The comment about precedent was specifically made in the
> context of the parenthetical presumption... if that presumption does
> not hold, and they did not block for some other reason (oversight, for
> example), that is a different statement entirely.
>

It makes sense for rat-plugin to ignore binary files because they could be
encrypted or compressed or something else, and already have a license
header (false positives) or are simply impossible to add a header to
because they are machine generated.

If these files have licence headers somewhere in them, then I will withdraw
my concern over them. I felt that I performed due diligence by visually
inspecting them, running them through "strings" program, and attempting to
check for file metadata. I support removing them and somehow moving the
contents to our website.

--089e015387027a20fe04f820ede0--