metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Casey Stella <ceste...@gmail.com>
Subject Re: [DISCUSS] Apache Rat Exclusions
Date Thu, 16 Mar 2017 21:27:48 GMT
Thanks, Dave!  Much appreciated insight.

On Thu, Mar 16, 2017 at 4:21 PM, David Lyle <dlyle65535@gmail.com> wrote:

> Hi Casey,
>
> I know a couple.
>
>
> - **/dependency-reduced-pom.xml
>    - *Does anyone know if we can adjust the dependency-reduced-pom to have
>       a license?*
>
> I don't think that should be committed, it may have gotten in there by
> mistake. Those are generated on each build. I'd remove the exclusion.
>
>  **/ansible.cfg
>    - *This is YAML, right?  YAML has comments, IIRC.  If so we should
>       license it.*
>
> Not YAML, more like ini. Supports comments and the copies I looked at had
> licenses. I'd remove the exclusion.
>
>      - *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?*
>
> These come from Bento and are Apache licensed. LICENSED and NOTICED.
>
> Agree with your conclusions above.
>
> -D...
>
>
>
>
> On Thu, Mar 16, 2017 at 3:25 PM, Casey Stella <cestella@gmail.com> wrote:
>
> > 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
> >       specific.*
> >    - **/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
> >    - **/wait-for-it.sh
> >    - This one is cool and explicitly listed in the LICENSE as MIT
> licensed
> >    - **/*.out
> >    - This seems to be generated output, so ok.
> >
>

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