Re: [DISCUSS] Hosting Kraken maven artifacts in incubator-metron git repo

2017-01-31 Thread Michael Miklavcic
All, unless there are any objections, for now it might be best to keep the
status quo and circle back around to modifying this dependency at a later
time. While not ideal, it does not appear to currently violate any
licensing rules.

Best,
Mike

On Tue, Jan 31, 2017 at 11:04 AM, Billie Rinaldi  wrote:

> On Tue, Jan 31, 2017 at 9:41 AM, Michael Miklavcic <
> michael.miklav...@gmail.com> wrote:
>
> > Hi Billie,
> >
> > Thanks for the feedback and info. I'm working on resolving this over the
> > next couple of days and could use some additional guidance when you have
> a
> > moment.
> >
> > You mention building the Kraken code as part of Metron. So I could
> > literally pull down the full source, plop it in a new Maven submodule
> > within the Metron project structure and be good to go? Seems like this
> > might actually be easiest. Plus we'd have the source code.
> >
>
> There is an IP clearance process for bringing externally developed code
> into an ASF project: http://incubator.apache.org/ip-clearance/
> It says a software grant form is required. I am not sure what the options
> are in the case where a software grant can't be obtained and the code is
> ASLv2 licensed. This would probably have to be discussed on the incubator
> general list or on legal.
>
>
> >
> > Alternatively, you mention publishing to Maven Central. It looks like
> Maven
> > Central has some requirements for publishing artifacts that might prove
> > hairy - http://central.sonatype.org/pages/requirements.html. Let's say I
> > fork the project (not via Metron) in my own github fork and modify the
> > Kraken poms to provide the necessary info. I'm supposed to provide the
> scm
> > location (my github repo), javadoc, signed jars, etc. I'd also need to
> > modify the groupId. Should that then be something personal (e.g.
> > com.michaelmiklavcic) or would it be ok to use org.apache.metron as a
> > groupId? I prefer to use Metron's groupId. I believe there is also a
> review
> > process involved with getting artifacts published to the central repo
> which
> > might take some time.
> >
>
> You not should use Apache's groupId. I heard from Josh that Sonatype
> encourages com.github..
>
>
> >
> > I think the submodule sounds like the best approach, but want to be sure
> > I've understood the recommendations correctly. We need to resolve this as
> > part of our move out of incubation to TLP status.
> >
> > Thanks,
> > Mike
> >
> >
> > On Tue, Jan 17, 2017 at 2:49 PM, Billie Rinaldi 
> wrote:
> >
> > > On Fri, Jan 13, 2017 at 3:35 PM, Matt Foley  wrote:
> > >
> > > > Perhaps it would be more appropriate to put it under
> > > > https://dist.apache.org/repos/dist/release/incubator/metron/ ,
> perhaps
> > > as
> > > > https://dist.apache.org/repos/dist/release/incubator/metron/mvn-repo
> ?
> > > >
> > >
> > > No, we could only do that if it were a release artifact for an official
> > > release. There is some more information about releases here:
> > > http://www.apache.org/dev/release.html#what. Specifically, anything
> that
> > > is
> > > published is considered a release, and that would definitely include
> > > anything on dist.apache.org. We can only release source code and
> binary
> > > artifacts resulting from compiling that source code.
> > >
> > >
> > > >
> > > > We should not host anything with a license that isn’t compatible with
> > > > inclusion in an Apache project.  If we post only non-source
> artifacts,
> > > then
> > > > that would include packages with “Category B List” licenses (that is,
> > > > ‘"WEAK COPYLEFT" LICENSES’) as well as “Category A List” licenses
> > (those
> > > > “SIMILAR IN TERMS TO THE APACHE LICENSE 2.0”) -- per
> > > > https://www.apache.org/legal/resolved .  For versioning, we could
> > simply
> > > > structure as a maven repo, and in fact that’s what I think we should
> > do.
> > > >
> > > > Hosting the source code is not, I think, something we are supposed to
> > do
> > > > for non-Apache projects: https://www.apache.org/legal/resolved
> again,
> > > > this time the very first question:
> > > >
> > > > CAN ASF PMCS HOST PROJECTS THAT ARE NOT UNDER THE APACHE LICENSE?
> > > > No. See the Apache Software Foundation licenses page for more
> > > details,
> > > > and the Apache Software Foundation page for additional background.
> > > >
> > >
> > > Kraken does appear to be licensed under ASLv2. Based on that, it might
> be
> > > possible to use the kraken code as the basis of a submodule of the
> Metron
> > > project, so that the necessary kraken jars would be built as part of
> the
> > > Metron build.
> > >
> > > Alternatively, someone could just push the kraken jars to Maven central
> > > under a new group id. Here's an example of a personal GitHub repo
> project
> > > configured to publish to Maven central via Sonatype:
> > > https://github.com/joshelser/dropwizard-hadoop-metrics2/
> > > blob/master/pom.xml.
> > >
> > >
> > > >
> > > > On 1/13/17, 8:11 AM, "Billie Rinaldi"  wrote:
> > > >
> > > > N

Re: [DISCUSS] Hosting Kraken maven artifacts in incubator-metron git repo

2017-01-31 Thread Billie Rinaldi
On Tue, Jan 31, 2017 at 9:41 AM, Michael Miklavcic <
michael.miklav...@gmail.com> wrote:

> Hi Billie,
>
> Thanks for the feedback and info. I'm working on resolving this over the
> next couple of days and could use some additional guidance when you have a
> moment.
>
> You mention building the Kraken code as part of Metron. So I could
> literally pull down the full source, plop it in a new Maven submodule
> within the Metron project structure and be good to go? Seems like this
> might actually be easiest. Plus we'd have the source code.
>

There is an IP clearance process for bringing externally developed code
into an ASF project: http://incubator.apache.org/ip-clearance/
It says a software grant form is required. I am not sure what the options
are in the case where a software grant can't be obtained and the code is
ASLv2 licensed. This would probably have to be discussed on the incubator
general list or on legal.


>
> Alternatively, you mention publishing to Maven Central. It looks like Maven
> Central has some requirements for publishing artifacts that might prove
> hairy - http://central.sonatype.org/pages/requirements.html. Let's say I
> fork the project (not via Metron) in my own github fork and modify the
> Kraken poms to provide the necessary info. I'm supposed to provide the scm
> location (my github repo), javadoc, signed jars, etc. I'd also need to
> modify the groupId. Should that then be something personal (e.g.
> com.michaelmiklavcic) or would it be ok to use org.apache.metron as a
> groupId? I prefer to use Metron's groupId. I believe there is also a review
> process involved with getting artifacts published to the central repo which
> might take some time.
>

You not should use Apache's groupId. I heard from Josh that Sonatype
encourages com.github..


>
> I think the submodule sounds like the best approach, but want to be sure
> I've understood the recommendations correctly. We need to resolve this as
> part of our move out of incubation to TLP status.
>
> Thanks,
> Mike
>
>
> On Tue, Jan 17, 2017 at 2:49 PM, Billie Rinaldi  wrote:
>
> > On Fri, Jan 13, 2017 at 3:35 PM, Matt Foley  wrote:
> >
> > > Perhaps it would be more appropriate to put it under
> > > https://dist.apache.org/repos/dist/release/incubator/metron/ , perhaps
> > as
> > > https://dist.apache.org/repos/dist/release/incubator/metron/mvn-repo ?
> > >
> >
> > No, we could only do that if it were a release artifact for an official
> > release. There is some more information about releases here:
> > http://www.apache.org/dev/release.html#what. Specifically, anything that
> > is
> > published is considered a release, and that would definitely include
> > anything on dist.apache.org. We can only release source code and binary
> > artifacts resulting from compiling that source code.
> >
> >
> > >
> > > We should not host anything with a license that isn’t compatible with
> > > inclusion in an Apache project.  If we post only non-source artifacts,
> > then
> > > that would include packages with “Category B List” licenses (that is,
> > > ‘"WEAK COPYLEFT" LICENSES’) as well as “Category A List” licenses
> (those
> > > “SIMILAR IN TERMS TO THE APACHE LICENSE 2.0”) -- per
> > > https://www.apache.org/legal/resolved .  For versioning, we could
> simply
> > > structure as a maven repo, and in fact that’s what I think we should
> do.
> > >
> > > Hosting the source code is not, I think, something we are supposed to
> do
> > > for non-Apache projects: https://www.apache.org/legal/resolved again,
> > > this time the very first question:
> > >
> > > CAN ASF PMCS HOST PROJECTS THAT ARE NOT UNDER THE APACHE LICENSE?
> > > No. See the Apache Software Foundation licenses page for more
> > details,
> > > and the Apache Software Foundation page for additional background.
> > >
> >
> > Kraken does appear to be licensed under ASLv2. Based on that, it might be
> > possible to use the kraken code as the basis of a submodule of the Metron
> > project, so that the necessary kraken jars would be built as part of the
> > Metron build.
> >
> > Alternatively, someone could just push the kraken jars to Maven central
> > under a new group id. Here's an example of a personal GitHub repo project
> > configured to publish to Maven central via Sonatype:
> > https://github.com/joshelser/dropwizard-hadoop-metrics2/
> > blob/master/pom.xml.
> >
> >
> > >
> > > On 1/13/17, 8:11 AM, "Billie Rinaldi"  wrote:
> > >
> > > No, we can't host artifacts in a git repo, or on a website. It
> would
> > be
> > > like distributing a release that hasn't been voted upon.
> > >
> > > Regarding message threading, in Gmail adding a [tag] to the subject
> > > does
> > > not create a new thread. So the change is not visible in my mailbox
> > > unless
> > > the rest of the subject is changed as well.
> > >
> > > On Mon, Jan 9, 2017 at 1:00 PM, Michael Miklavcic <
> > > michael.miklav...@gmail.com> wrote:
> > >
> > > > This is a question primarily fo

Re: [DISCUSS] Hosting Kraken maven artifacts in incubator-metron git repo

2017-01-31 Thread Michael Miklavcic
My reservation with this approach is that we're still depending on an
unreleased version of files from a github repo that we do not control. So
if Kraken or OpenSOC pull their repos, then this no longer works. The 2
approaches outlined above mitigate this risk as follows:
1. Once published to Maven Central, the artifacts are there forever. The
source code is also required to publish to Maven Central, so even though
it's not in a repo structure, it could still be referenced if absolutely
needed.
2. Bringing in the source code allows us to avoid a separate review process
with Sonatype/Maven for getting into Maven Central. Kraken pcap source
hasn't been modified in quite a while, so we wouldn't really be missing
much by forking the project internally. And we'd have the full source
building in case we need to address any bugs or security issues. Much
easier than the other option.

On Tue, Jan 31, 2017 at 10:53 AM, JJ Meyer  wrote:

> Mike,
>
> You wouldn't  need to necessarily download the code and host it in the
> metron repo. Git sub-modules are sometimes used in cases like this. It is
> more like a pointer to an external repo. Below is a short read on how we
> could potentially do this with git sub-modules. I have used these in the
> past. I will say sometimes it becomes a bit confusing as to what version of
> the submodule is being used. It could just be me though.
>
> http://alex.nederlof.com/blog/2013/07/08/using-git-submodules-for-maven-
> artifacts-not-in-central/
>
> Thanks,
>
> On Tue, Jan 31, 2017 at 11:41 AM, Michael Miklavcic <
> michael.miklav...@gmail.com> wrote:
>
> > Hi Billie,
> >
> > Thanks for the feedback and info. I'm working on resolving this over the
> > next couple of days and could use some additional guidance when you have
> a
> > moment.
> >
> > You mention building the Kraken code as part of Metron. So I could
> > literally pull down the full source, plop it in a new Maven submodule
> > within the Metron project structure and be good to go? Seems like this
> > might actually be easiest. Plus we'd have the source code.
> >
> > Alternatively, you mention publishing to Maven Central. It looks like
> Maven
> > Central has some requirements for publishing artifacts that might prove
> > hairy - http://central.sonatype.org/pages/requirements.html. Let's say I
> > fork the project (not via Metron) in my own github fork and modify the
> > Kraken poms to provide the necessary info. I'm supposed to provide the
> scm
> > location (my github repo), javadoc, signed jars, etc. I'd also need to
> > modify the groupId. Should that then be something personal (e.g.
> > com.michaelmiklavcic) or would it be ok to use org.apache.metron as a
> > groupId? I prefer to use Metron's groupId. I believe there is also a
> review
> > process involved with getting artifacts published to the central repo
> which
> > might take some time.
> >
> > I think the submodule sounds like the best approach, but want to be sure
> > I've understood the recommendations correctly. We need to resolve this as
> > part of our move out of incubation to TLP status.
> >
> > Thanks,
> > Mike
> >
> >
> > On Tue, Jan 17, 2017 at 2:49 PM, Billie Rinaldi 
> wrote:
> >
> > > On Fri, Jan 13, 2017 at 3:35 PM, Matt Foley  wrote:
> > >
> > > > Perhaps it would be more appropriate to put it under
> > > > https://dist.apache.org/repos/dist/release/incubator/metron/ ,
> perhaps
> > > as
> > > > https://dist.apache.org/repos/dist/release/incubator/metron/mvn-repo
> ?
> > > >
> > >
> > > No, we could only do that if it were a release artifact for an official
> > > release. There is some more information about releases here:
> > > http://www.apache.org/dev/release.html#what. Specifically, anything
> that
> > > is
> > > published is considered a release, and that would definitely include
> > > anything on dist.apache.org. We can only release source code and
> binary
> > > artifacts resulting from compiling that source code.
> > >
> > >
> > > >
> > > > We should not host anything with a license that isn’t compatible with
> > > > inclusion in an Apache project.  If we post only non-source
> artifacts,
> > > then
> > > > that would include packages with “Category B List” licenses (that is,
> > > > ‘"WEAK COPYLEFT" LICENSES’) as well as “Category A List” licenses
> > (those
> > > > “SIMILAR IN TERMS TO THE APACHE LICENSE 2.0”) -- per
> > > > https://www.apache.org/legal/resolved .  For versioning, we could
> > simply
> > > > structure as a maven repo, and in fact that’s what I think we should
> > do.
> > > >
> > > > Hosting the source code is not, I think, something we are supposed to
> > do
> > > > for non-Apache projects: https://www.apache.org/legal/resolved
> again,
> > > > this time the very first question:
> > > >
> > > > CAN ASF PMCS HOST PROJECTS THAT ARE NOT UNDER THE APACHE LICENSE?
> > > > No. See the Apache Software Foundation licenses page for more
> > > details,
> > > > and the Apache Software Foundation page for additional backgrou

Re: [DISCUSS] Hosting Kraken maven artifacts in incubator-metron git repo

2017-01-31 Thread JJ Meyer
Mike,

You wouldn't  need to necessarily download the code and host it in the
metron repo. Git sub-modules are sometimes used in cases like this. It is
more like a pointer to an external repo. Below is a short read on how we
could potentially do this with git sub-modules. I have used these in the
past. I will say sometimes it becomes a bit confusing as to what version of
the submodule is being used. It could just be me though.

http://alex.nederlof.com/blog/2013/07/08/using-git-submodules-for-maven-artifacts-not-in-central/

Thanks,

On Tue, Jan 31, 2017 at 11:41 AM, Michael Miklavcic <
michael.miklav...@gmail.com> wrote:

> Hi Billie,
>
> Thanks for the feedback and info. I'm working on resolving this over the
> next couple of days and could use some additional guidance when you have a
> moment.
>
> You mention building the Kraken code as part of Metron. So I could
> literally pull down the full source, plop it in a new Maven submodule
> within the Metron project structure and be good to go? Seems like this
> might actually be easiest. Plus we'd have the source code.
>
> Alternatively, you mention publishing to Maven Central. It looks like Maven
> Central has some requirements for publishing artifacts that might prove
> hairy - http://central.sonatype.org/pages/requirements.html. Let's say I
> fork the project (not via Metron) in my own github fork and modify the
> Kraken poms to provide the necessary info. I'm supposed to provide the scm
> location (my github repo), javadoc, signed jars, etc. I'd also need to
> modify the groupId. Should that then be something personal (e.g.
> com.michaelmiklavcic) or would it be ok to use org.apache.metron as a
> groupId? I prefer to use Metron's groupId. I believe there is also a review
> process involved with getting artifacts published to the central repo which
> might take some time.
>
> I think the submodule sounds like the best approach, but want to be sure
> I've understood the recommendations correctly. We need to resolve this as
> part of our move out of incubation to TLP status.
>
> Thanks,
> Mike
>
>
> On Tue, Jan 17, 2017 at 2:49 PM, Billie Rinaldi  wrote:
>
> > On Fri, Jan 13, 2017 at 3:35 PM, Matt Foley  wrote:
> >
> > > Perhaps it would be more appropriate to put it under
> > > https://dist.apache.org/repos/dist/release/incubator/metron/ , perhaps
> > as
> > > https://dist.apache.org/repos/dist/release/incubator/metron/mvn-repo ?
> > >
> >
> > No, we could only do that if it were a release artifact for an official
> > release. There is some more information about releases here:
> > http://www.apache.org/dev/release.html#what. Specifically, anything that
> > is
> > published is considered a release, and that would definitely include
> > anything on dist.apache.org. We can only release source code and binary
> > artifacts resulting from compiling that source code.
> >
> >
> > >
> > > We should not host anything with a license that isn’t compatible with
> > > inclusion in an Apache project.  If we post only non-source artifacts,
> > then
> > > that would include packages with “Category B List” licenses (that is,
> > > ‘"WEAK COPYLEFT" LICENSES’) as well as “Category A List” licenses
> (those
> > > “SIMILAR IN TERMS TO THE APACHE LICENSE 2.0”) -- per
> > > https://www.apache.org/legal/resolved .  For versioning, we could
> simply
> > > structure as a maven repo, and in fact that’s what I think we should
> do.
> > >
> > > Hosting the source code is not, I think, something we are supposed to
> do
> > > for non-Apache projects: https://www.apache.org/legal/resolved again,
> > > this time the very first question:
> > >
> > > CAN ASF PMCS HOST PROJECTS THAT ARE NOT UNDER THE APACHE LICENSE?
> > > No. See the Apache Software Foundation licenses page for more
> > details,
> > > and the Apache Software Foundation page for additional background.
> > >
> >
> > Kraken does appear to be licensed under ASLv2. Based on that, it might be
> > possible to use the kraken code as the basis of a submodule of the Metron
> > project, so that the necessary kraken jars would be built as part of the
> > Metron build.
> >
> > Alternatively, someone could just push the kraken jars to Maven central
> > under a new group id. Here's an example of a personal GitHub repo project
> > configured to publish to Maven central via Sonatype:
> > https://github.com/joshelser/dropwizard-hadoop-metrics2/
> > blob/master/pom.xml.
> >
> >
> > >
> > > On 1/13/17, 8:11 AM, "Billie Rinaldi"  wrote:
> > >
> > > No, we can't host artifacts in a git repo, or on a website. It
> would
> > be
> > > like distributing a release that hasn't been voted upon.
> > >
> > > Regarding message threading, in Gmail adding a [tag] to the subject
> > > does
> > > not create a new thread. So the change is not visible in my mailbox
> > > unless
> > > the rest of the subject is changed as well.
> > >
> > > On Mon, Jan 9, 2017 at 1:00 PM, Michael Miklavcic <
> > > michael.miklav...@gmail.com> 

Re: [DISCUSS] Hosting Kraken maven artifacts in incubator-metron git repo

2017-01-31 Thread Michael Miklavcic
Hi Billie,

Thanks for the feedback and info. I'm working on resolving this over the
next couple of days and could use some additional guidance when you have a
moment.

You mention building the Kraken code as part of Metron. So I could
literally pull down the full source, plop it in a new Maven submodule
within the Metron project structure and be good to go? Seems like this
might actually be easiest. Plus we'd have the source code.

Alternatively, you mention publishing to Maven Central. It looks like Maven
Central has some requirements for publishing artifacts that might prove
hairy - http://central.sonatype.org/pages/requirements.html. Let's say I
fork the project (not via Metron) in my own github fork and modify the
Kraken poms to provide the necessary info. I'm supposed to provide the scm
location (my github repo), javadoc, signed jars, etc. I'd also need to
modify the groupId. Should that then be something personal (e.g.
com.michaelmiklavcic) or would it be ok to use org.apache.metron as a
groupId? I prefer to use Metron's groupId. I believe there is also a review
process involved with getting artifacts published to the central repo which
might take some time.

I think the submodule sounds like the best approach, but want to be sure
I've understood the recommendations correctly. We need to resolve this as
part of our move out of incubation to TLP status.

Thanks,
Mike


On Tue, Jan 17, 2017 at 2:49 PM, Billie Rinaldi  wrote:

> On Fri, Jan 13, 2017 at 3:35 PM, Matt Foley  wrote:
>
> > Perhaps it would be more appropriate to put it under
> > https://dist.apache.org/repos/dist/release/incubator/metron/ , perhaps
> as
> > https://dist.apache.org/repos/dist/release/incubator/metron/mvn-repo ?
> >
>
> No, we could only do that if it were a release artifact for an official
> release. There is some more information about releases here:
> http://www.apache.org/dev/release.html#what. Specifically, anything that
> is
> published is considered a release, and that would definitely include
> anything on dist.apache.org. We can only release source code and binary
> artifacts resulting from compiling that source code.
>
>
> >
> > We should not host anything with a license that isn’t compatible with
> > inclusion in an Apache project.  If we post only non-source artifacts,
> then
> > that would include packages with “Category B List” licenses (that is,
> > ‘"WEAK COPYLEFT" LICENSES’) as well as “Category A List” licenses (those
> > “SIMILAR IN TERMS TO THE APACHE LICENSE 2.0”) -- per
> > https://www.apache.org/legal/resolved .  For versioning, we could simply
> > structure as a maven repo, and in fact that’s what I think we should do.
> >
> > Hosting the source code is not, I think, something we are supposed to do
> > for non-Apache projects: https://www.apache.org/legal/resolved again,
> > this time the very first question:
> >
> > CAN ASF PMCS HOST PROJECTS THAT ARE NOT UNDER THE APACHE LICENSE?
> > No. See the Apache Software Foundation licenses page for more
> details,
> > and the Apache Software Foundation page for additional background.
> >
>
> Kraken does appear to be licensed under ASLv2. Based on that, it might be
> possible to use the kraken code as the basis of a submodule of the Metron
> project, so that the necessary kraken jars would be built as part of the
> Metron build.
>
> Alternatively, someone could just push the kraken jars to Maven central
> under a new group id. Here's an example of a personal GitHub repo project
> configured to publish to Maven central via Sonatype:
> https://github.com/joshelser/dropwizard-hadoop-metrics2/
> blob/master/pom.xml.
>
>
> >
> > On 1/13/17, 8:11 AM, "Billie Rinaldi"  wrote:
> >
> > No, we can't host artifacts in a git repo, or on a website. It would
> be
> > like distributing a release that hasn't been voted upon.
> >
> > Regarding message threading, in Gmail adding a [tag] to the subject
> > does
> > not create a new thread. So the change is not visible in my mailbox
> > unless
> > the rest of the subject is changed as well.
> >
> > On Mon, Jan 9, 2017 at 1:00 PM, Michael Miklavcic <
> > michael.miklav...@gmail.com> wrote:
> >
> > > This is a question primarily for the mentors.
> > >
> > > *Background*
> > > metron-common is currently depending on the openSOC github repo for
> > hosting
> > > kraken artifacts. The original reason for this was that these jars
> > are not
> > > hosted in Maven Central, and they were not reliably available in
> the
> > Kraken
> > > repo. https://issues.apache.org/jira/browse/METRON-650 is tracking
> > work
> > > around copying these artifacts to the Metron repo.
> > >
> > > Kraken source on openSOC - https://github.com/OpenSOC/kraken
> > > Krake maven repo on openSOC -
> > > https://github.com/OpenSOC/kraken/tree/mvn-repo
> > >
> > > *Ask*
> > > Create a new branch in incubator-metron to host any necessary maven
> > > artifacts. This 

Re: [DISCUSS] Hosting Kraken maven artifacts in incubator-metron git repo

2017-01-17 Thread Billie Rinaldi
On Fri, Jan 13, 2017 at 3:35 PM, Matt Foley  wrote:

> Perhaps it would be more appropriate to put it under
> https://dist.apache.org/repos/dist/release/incubator/metron/ , perhaps as
> https://dist.apache.org/repos/dist/release/incubator/metron/mvn-repo ?
>

No, we could only do that if it were a release artifact for an official
release. There is some more information about releases here:
http://www.apache.org/dev/release.html#what. Specifically, anything that is
published is considered a release, and that would definitely include
anything on dist.apache.org. We can only release source code and binary
artifacts resulting from compiling that source code.


>
> We should not host anything with a license that isn’t compatible with
> inclusion in an Apache project.  If we post only non-source artifacts, then
> that would include packages with “Category B List” licenses (that is,
> ‘"WEAK COPYLEFT" LICENSES’) as well as “Category A List” licenses (those
> “SIMILAR IN TERMS TO THE APACHE LICENSE 2.0”) -- per
> https://www.apache.org/legal/resolved .  For versioning, we could simply
> structure as a maven repo, and in fact that’s what I think we should do.
>
> Hosting the source code is not, I think, something we are supposed to do
> for non-Apache projects: https://www.apache.org/legal/resolved again,
> this time the very first question:
>
> CAN ASF PMCS HOST PROJECTS THAT ARE NOT UNDER THE APACHE LICENSE?
> No. See the Apache Software Foundation licenses page for more details,
> and the Apache Software Foundation page for additional background.
>

Kraken does appear to be licensed under ASLv2. Based on that, it might be
possible to use the kraken code as the basis of a submodule of the Metron
project, so that the necessary kraken jars would be built as part of the
Metron build.

Alternatively, someone could just push the kraken jars to Maven central
under a new group id. Here's an example of a personal GitHub repo project
configured to publish to Maven central via Sonatype:
https://github.com/joshelser/dropwizard-hadoop-metrics2/blob/master/pom.xml.


>
> On 1/13/17, 8:11 AM, "Billie Rinaldi"  wrote:
>
> No, we can't host artifacts in a git repo, or on a website. It would be
> like distributing a release that hasn't been voted upon.
>
> Regarding message threading, in Gmail adding a [tag] to the subject
> does
> not create a new thread. So the change is not visible in my mailbox
> unless
> the rest of the subject is changed as well.
>
> On Mon, Jan 9, 2017 at 1:00 PM, Michael Miklavcic <
> michael.miklav...@gmail.com> wrote:
>
> > This is a question primarily for the mentors.
> >
> > *Background*
> > metron-common is currently depending on the openSOC github repo for
> hosting
> > kraken artifacts. The original reason for this was that these jars
> are not
> > hosted in Maven Central, and they were not reliably available in the
> Kraken
> > repo. https://issues.apache.org/jira/browse/METRON-650 is tracking
> work
> > around copying these artifacts to the Metron repo.
> >
> > Kraken source on openSOC - https://github.com/OpenSOC/kraken
> > Krake maven repo on openSOC -
> > https://github.com/OpenSOC/kraken/tree/mvn-repo
> >
> > *Ask*
> > Create a new branch in incubator-metron to host any necessary maven
> > artifacts. This branch would simply be incubator-metron/mvn-repo.
> This is
> > similar to how we've hosted the asf-site.
> >
> > *Concerns/Questions*
> >
> >1. Can we host these jars/artifacts in this manner?
> >2. Concerns regarding licensing?
> >3. Do we need to also grab and host the source code?
> >
>
>
>
>
>


Re: [DISCUSS] Hosting Kraken maven artifacts in incubator-metron git repo

2017-01-13 Thread JJ Meyer
Has anyone used git's sub-modules before? My understanding is you just
point to an external repository. So *technically* I do not think the code
would be hosted in the main repo. Even if that was allowed, I have concerns
about how inactive the repo is. Could we fork this, make our changes, and
submit it to another apache project that it may make sense under? Is that
even allowed under their license?

On Fri, Jan 13, 2017 at 5:35 PM, Matt Foley  wrote:

> Perhaps it would be more appropriate to put it under
> https://dist.apache.org/repos/dist/release/incubator/metron/ , perhaps as
> https://dist.apache.org/repos/dist/release/incubator/metron/mvn-repo ?
>
> We should not host anything with a license that isn’t compatible with
> inclusion in an Apache project.  If we post only non-source artifacts, then
> that would include packages with “Category B List” licenses (that is,
> ‘"WEAK COPYLEFT" LICENSES’) as well as “Category A List” licenses (those
> “SIMILAR IN TERMS TO THE APACHE LICENSE 2.0”) -- per
> https://www.apache.org/legal/resolved .  For versioning, we could simply
> structure as a maven repo, and in fact that’s what I think we should do.
>
> Hosting the source code is not, I think, something we are supposed to do
> for non-Apache projects: https://www.apache.org/legal/resolved again,
> this time the very first question:
>
> CAN ASF PMCS HOST PROJECTS THAT ARE NOT UNDER THE APACHE LICENSE?
> No. See the Apache Software Foundation licenses page for more details,
> and the Apache Software Foundation page for additional background.
>
>
> On 1/13/17, 8:11 AM, "Billie Rinaldi"  wrote:
>
> No, we can't host artifacts in a git repo, or on a website. It would be
> like distributing a release that hasn't been voted upon.
>
> Regarding message threading, in Gmail adding a [tag] to the subject
> does
> not create a new thread. So the change is not visible in my mailbox
> unless
> the rest of the subject is changed as well.
>
> On Mon, Jan 9, 2017 at 1:00 PM, Michael Miklavcic <
> michael.miklav...@gmail.com> wrote:
>
> > This is a question primarily for the mentors.
> >
> > *Background*
> > metron-common is currently depending on the openSOC github repo for
> hosting
> > kraken artifacts. The original reason for this was that these jars
> are not
> > hosted in Maven Central, and they were not reliably available in the
> Kraken
> > repo. https://issues.apache.org/jira/browse/METRON-650 is tracking
> work
> > around copying these artifacts to the Metron repo.
> >
> > Kraken source on openSOC - https://github.com/OpenSOC/kraken
> > Krake maven repo on openSOC -
> > https://github.com/OpenSOC/kraken/tree/mvn-repo
> >
> > *Ask*
> > Create a new branch in incubator-metron to host any necessary maven
> > artifacts. This branch would simply be incubator-metron/mvn-repo.
> This is
> > similar to how we've hosted the asf-site.
> >
> > *Concerns/Questions*
> >
> >1. Can we host these jars/artifacts in this manner?
> >2. Concerns regarding licensing?
> >3. Do we need to also grab and host the source code?
> >
>
>
>
>
>


Re: [DISCUSS] Hosting Kraken maven artifacts in incubator-metron git repo

2017-01-13 Thread Matt Foley
Perhaps it would be more appropriate to put it under 
https://dist.apache.org/repos/dist/release/incubator/metron/ , perhaps as 
https://dist.apache.org/repos/dist/release/incubator/metron/mvn-repo ?

We should not host anything with a license that isn’t compatible with inclusion 
in an Apache project.  If we post only non-source artifacts, then that would 
include packages with “Category B List” licenses (that is, ‘"WEAK COPYLEFT" 
LICENSES’) as well as “Category A List” licenses (those “SIMILAR IN TERMS TO 
THE APACHE LICENSE 2.0”) -- per  https://www.apache.org/legal/resolved .  For 
versioning, we could simply structure as a maven repo, and in fact that’s what 
I think we should do.

Hosting the source code is not, I think, something we are supposed to do for 
non-Apache projects: https://www.apache.org/legal/resolved again, this time the 
very first question:

CAN ASF PMCS HOST PROJECTS THAT ARE NOT UNDER THE APACHE LICENSE?
No. See the Apache Software Foundation licenses page for more details, and 
the Apache Software Foundation page for additional background.


On 1/13/17, 8:11 AM, "Billie Rinaldi"  wrote:

No, we can't host artifacts in a git repo, or on a website. It would be
like distributing a release that hasn't been voted upon.

Regarding message threading, in Gmail adding a [tag] to the subject does
not create a new thread. So the change is not visible in my mailbox unless
the rest of the subject is changed as well.

On Mon, Jan 9, 2017 at 1:00 PM, Michael Miklavcic <
michael.miklav...@gmail.com> wrote:

> This is a question primarily for the mentors.
>
> *Background*
> metron-common is currently depending on the openSOC github repo for 
hosting
> kraken artifacts. The original reason for this was that these jars are not
> hosted in Maven Central, and they were not reliably available in the 
Kraken
> repo. https://issues.apache.org/jira/browse/METRON-650 is tracking work
> around copying these artifacts to the Metron repo.
>
> Kraken source on openSOC - https://github.com/OpenSOC/kraken
> Krake maven repo on openSOC -
> https://github.com/OpenSOC/kraken/tree/mvn-repo
>
> *Ask*
> Create a new branch in incubator-metron to host any necessary maven
> artifacts. This branch would simply be incubator-metron/mvn-repo. This is
> similar to how we've hosted the asf-site.
>
> *Concerns/Questions*
>
>1. Can we host these jars/artifacts in this manner?
>2. Concerns regarding licensing?
>3. Do we need to also grab and host the source code?
>






Re: [DISCUSS] Hosting Kraken maven artifacts in incubator-metron git repo

2017-01-13 Thread Billie Rinaldi
No, we can't host artifacts in a git repo, or on a website. It would be
like distributing a release that hasn't been voted upon.

Regarding message threading, in Gmail adding a [tag] to the subject does
not create a new thread. So the change is not visible in my mailbox unless
the rest of the subject is changed as well.

On Mon, Jan 9, 2017 at 1:00 PM, Michael Miklavcic <
michael.miklav...@gmail.com> wrote:

> This is a question primarily for the mentors.
>
> *Background*
> metron-common is currently depending on the openSOC github repo for hosting
> kraken artifacts. The original reason for this was that these jars are not
> hosted in Maven Central, and they were not reliably available in the Kraken
> repo. https://issues.apache.org/jira/browse/METRON-650 is tracking work
> around copying these artifacts to the Metron repo.
>
> Kraken source on openSOC - https://github.com/OpenSOC/kraken
> Krake maven repo on openSOC -
> https://github.com/OpenSOC/kraken/tree/mvn-repo
>
> *Ask*
> Create a new branch in incubator-metron to host any necessary maven
> artifacts. This branch would simply be incubator-metron/mvn-repo. This is
> similar to how we've hosted the asf-site.
>
> *Concerns/Questions*
>
>1. Can we host these jars/artifacts in this manner?
>2. Concerns regarding licensing?
>3. Do we need to also grab and host the source code?
>


Re: [DISCUSS] Hosting Kraken maven artifacts in incubator-metron git repo

2017-01-11 Thread Michael Miklavcic
Ok, that was funny

On Wed, Jan 11, 2017 at 7:43 AM, Casey Stella  wrote:

> I'd recommend restarting this discuss thread with the subject
> "[DISCUSS][MENTORS] Hosting Kraken maven artifacts in incubator-metron git
> repo".  That's the Mentors bat-symbol. The other option is to repeat
> "mentors" 3 times and either the mentors will appear or you will be eaten
> by a grue. ;)
>
> On Wed, Jan 11, 2017 at 9:32 AM, Michael Miklavcic <
> michael.miklav...@gmail.com> wrote:
>
> > Any comment from the mentors on this?
> >
> > On Mon, Jan 9, 2017 at 2:00 PM, Michael Miklavcic <
> > michael.miklav...@gmail.com> wrote:
> >
> > > This is a question primarily for the mentors.
> > >
> > > *Background*
> > > metron-common is currently depending on the openSOC github repo for
> > > hosting kraken artifacts. The original reason for this was that these
> > jars
> > > are not hosted in Maven Central, and they were not reliably available
> in
> > > the Kraken repo. https://issues.apache.org/jira/browse/METRON-650 is
> > > tracking work around copying these artifacts to the Metron repo.
> > >
> > > Kraken source on openSOC - https://github.com/OpenSOC/kraken
> > > Krake maven repo on openSOC - https://github.com/OpenSOC/
> > > kraken/tree/mvn-repo
> > >
> > > *Ask*
> > > Create a new branch in incubator-metron to host any necessary maven
> > > artifacts. This branch would simply be incubator-metron/mvn-repo. This
> is
> > > similar to how we've hosted the asf-site.
> > >
> > > *Concerns/Questions*
> > >
> > >1. Can we host these jars/artifacts in this manner?
> > >2. Concerns regarding licensing?
> > >3. Do we need to also grab and host the source code?
> > >
> > >
> >
>


Re: [DISCUSS] Hosting Kraken maven artifacts in incubator-metron git repo

2017-01-11 Thread Casey Stella
I'd recommend restarting this discuss thread with the subject
"[DISCUSS][MENTORS] Hosting Kraken maven artifacts in incubator-metron git
repo".  That's the Mentors bat-symbol. The other option is to repeat
"mentors" 3 times and either the mentors will appear or you will be eaten
by a grue. ;)

On Wed, Jan 11, 2017 at 9:32 AM, Michael Miklavcic <
michael.miklav...@gmail.com> wrote:

> Any comment from the mentors on this?
>
> On Mon, Jan 9, 2017 at 2:00 PM, Michael Miklavcic <
> michael.miklav...@gmail.com> wrote:
>
> > This is a question primarily for the mentors.
> >
> > *Background*
> > metron-common is currently depending on the openSOC github repo for
> > hosting kraken artifacts. The original reason for this was that these
> jars
> > are not hosted in Maven Central, and they were not reliably available in
> > the Kraken repo. https://issues.apache.org/jira/browse/METRON-650 is
> > tracking work around copying these artifacts to the Metron repo.
> >
> > Kraken source on openSOC - https://github.com/OpenSOC/kraken
> > Krake maven repo on openSOC - https://github.com/OpenSOC/
> > kraken/tree/mvn-repo
> >
> > *Ask*
> > Create a new branch in incubator-metron to host any necessary maven
> > artifacts. This branch would simply be incubator-metron/mvn-repo. This is
> > similar to how we've hosted the asf-site.
> >
> > *Concerns/Questions*
> >
> >1. Can we host these jars/artifacts in this manner?
> >2. Concerns regarding licensing?
> >3. Do we need to also grab and host the source code?
> >
> >
>


Re: [DISCUSS] Hosting Kraken maven artifacts in incubator-metron git repo

2017-01-11 Thread Michael Miklavcic
Any comment from the mentors on this?

On Mon, Jan 9, 2017 at 2:00 PM, Michael Miklavcic <
michael.miklav...@gmail.com> wrote:

> This is a question primarily for the mentors.
>
> *Background*
> metron-common is currently depending on the openSOC github repo for
> hosting kraken artifacts. The original reason for this was that these jars
> are not hosted in Maven Central, and they were not reliably available in
> the Kraken repo. https://issues.apache.org/jira/browse/METRON-650 is
> tracking work around copying these artifacts to the Metron repo.
>
> Kraken source on openSOC - https://github.com/OpenSOC/kraken
> Krake maven repo on openSOC - https://github.com/OpenSOC/
> kraken/tree/mvn-repo
>
> *Ask*
> Create a new branch in incubator-metron to host any necessary maven
> artifacts. This branch would simply be incubator-metron/mvn-repo. This is
> similar to how we've hosted the asf-site.
>
> *Concerns/Questions*
>
>1. Can we host these jars/artifacts in this manner?
>2. Concerns regarding licensing?
>3. Do we need to also grab and host the source code?
>
>


Re: [DISCUSS] Hosting Kraken maven artifacts in incubator-metron git repo

2017-01-09 Thread Otto Fowler
Just a heads up and hopefully not a distraction:

Per https://issues.apache.org/jira/browse/METRON-583, if we ever update to a 
never version of GROK, many of our existing rules are going to break.

I have a pull request out for this issue ( 
https://github.com/thekrakken/java-grok/pull/60 ) with them since November, but 
there has been no comment or movement on it.

On January 9, 2017 at 16:01:00, Michael Miklavcic (michael.miklav...@gmail.com) 
wrote:

This is a question primarily for the mentors.  

*Background*  
metron-common is currently depending on the openSOC github repo for hosting  
kraken artifacts. The original reason for this was that these jars are not  
hosted in Maven Central, and they were not reliably available in the Kraken  
repo. https://issues.apache.org/jira/browse/METRON-650 is tracking work  
around copying these artifacts to the Metron repo.  

Kraken source on openSOC - https://github.com/OpenSOC/kraken  
Krake maven repo on openSOC -  
https://github.com/OpenSOC/kraken/tree/mvn-repo  

*Ask*  
Create a new branch in incubator-metron to host any necessary maven  
artifacts. This branch would simply be incubator-metron/mvn-repo. This is  
similar to how we've hosted the asf-site.  

*Concerns/Questions*  

1. Can we host these jars/artifacts in this manner?  
2. Concerns regarding licensing?  
3. Do we need to also grab and host the source code?  


[DISCUSS] Hosting Kraken maven artifacts in incubator-metron git repo

2017-01-09 Thread Michael Miklavcic
This is a question primarily for the mentors.

*Background*
metron-common is currently depending on the openSOC github repo for hosting
kraken artifacts. The original reason for this was that these jars are not
hosted in Maven Central, and they were not reliably available in the Kraken
repo. https://issues.apache.org/jira/browse/METRON-650 is tracking work
around copying these artifacts to the Metron repo.

Kraken source on openSOC - https://github.com/OpenSOC/kraken
Krake maven repo on openSOC -
https://github.com/OpenSOC/kraken/tree/mvn-repo

*Ask*
Create a new branch in incubator-metron to host any necessary maven
artifacts. This branch would simply be incubator-metron/mvn-repo. This is
similar to how we've hosted the asf-site.

*Concerns/Questions*

   1. Can we host these jars/artifacts in this manner?
   2. Concerns regarding licensing?
   3. Do we need to also grab and host the source code?