On Mon, Apr 28, 2014 at 5:12 PM, Christopher <ctubb...@apache.org> wrote:
> On Mon, Apr 28, 2014 at 3:24 PM, Mike Drob <mad...@cloudera.com> wrote: > > Forking thread for discussion. > > > > On Mon, Apr 28, 2014 at 2:51 PM, Christopher <ctubb...@apache.org> > wrote: > > > >> On Mon, Apr 28, 2014 at 12:20 PM, Mike Drob <mad...@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.
