metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Casey Stella <>
Subject [DISCUSS] Apache Rat Exclusions
Date Thu, 16 Mar 2017 19:25:32 GMT
As part of the mentor feedback on our 0.3.1 release, it was noted that we
have broad apache rat exclusions in our top level pom.  It was suggested
that we distribute those to the individual relevant modules rather than
having them in the top level pom.  The concern is for broad exclusions from
rat that we might be out of compliance with respect to licensing everything
which can take a comment.  If we intend on moving on to a top level
project, I think this should at the very least be addressed.

As a prerequisite to that work (and a stop-gap), I'd like to understand the
nature of those exclusions so we can at least justify them.  Where we
cannot justify the exclusion, we need to correct it.  This ideally should
happen before we attempt to go to a top level project, in my opinion.

I have listed them here with my comments.  The bolded comments are the ones
most concerning to me or that I had a pointed question about.

   - **/*.md
   - *This seems wrong, markdown can take comments, so we should have an
      apache license header, right?*
   - **/VERSION
   - *This is coming from the python sensor plugins.  Any suggested
      verbiage around this for the comment?*
   - **/*.json
   - I think this is ok as JSON can't have comments, rights?
   - **/*.tokens
   - These are generated data files from antlr and don't appear to take
      comments, so I think they're ok
   - **/*.log
   - Log files aren't source, so I think this is ok
   - **/*.template
   - ES Templates are JSON and can't have comments
   - **/.*
   - *Which dotfiles are we explicitly excluding?  Some dotfiles take
      comments and could be licensed.*
   - **/.*/**
   - ditto
   - **/*.seed
   - *I don't see this anywhere, where did this one come from?*
   - **/*.iml
   - IDE files
   - **/ansible.cfg
   - *This is YAML, right?  YAML has comments, IIRC.  If so we should
      license it.*
   - **/*.rpm
   - This is generated, binary files, so it should be ok.
   - site/**
   - *This seems wrong.  It's jekyll format, so we can't put the license at
      the top, but we can attach a license in the generated HTML, right?*
   - **/src/main/resources/patterns/**
   - *Does Grok allow for comments?  If so, we should license these.*
   - **/src/main/sample/patterns/**
   - *Ditto*
   - **/src/test/resources/**
   - *This seems overly broad, to me.  We should at least do it via
      extension.  This way if someone adds something that should be
licensed, we
      know about it, right?*
   - **/src/main/sample/data/**
   - *This is raw data and ok, but maybe it'd be good to make this project
   - **/dependency-reduced-pom.xml
   - *Does anyone know if we can adjust the dependency-reduced-pom to have
      a license?*
   - **/target/**
   - **/bro-plugin-kafka/build/**
   - The output of the build, so I think that's ok
   - **/packer-build/scripts/**
      - *These are bundled source scripts, which falls under the rules
      around bundling.  What are their licenses and did we include
these scripts
      in the LICENSE?*
   - **/packer-build/bin/**
   - This seems to be binary data, so ok
   - **/packer_cache/**
   - This seems to be binary data, so ok
   - **/hbase/data/**
   - This seems to be binary data, so ok
   - **/kafkazk/data/**
   - This seems to be binary data, so ok
   - **/
   - This one is cool and explicitly listed in the LICENSE as MIT licensed
   - **/*.out
   - This seems to be generated output, so ok.

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