[VOTE] Apache Gearpump (incubating) 0.8.3-RC1

[Karol Brejna]

Hi IPMC Community,

The PPMC vote to release Apache Gearpump (incubating) 0.8.3-RC1 has passed.
We would like to now submit this release candidate to the IPMC.

The PPMC vote thread is here:
https://lists.apache.org/thread.html/0e1022d2f3b5b2a2b879e4c278d7fc44d094058550d47ae7e07702ec@%3Cdev.gearpump.apache.org%3E

The source and binary tarballs, including signatures, digests, etc.
can be found at:
https://dist.apache.org/repos/dist/dev/incubator/gearpump/0.8.3-incubating/RC1/

Release artifacts are signed with the key with fingerprint:
3F12 81A2 DB58 0842 5ABA  6962 D8A8 4FBC 0A83 B291

The KEYS file is available here:
https://dist.apache.org/repos/dist/dev/incubator/gearpump/KEYS

The tag to be voted upon is:
https://git-wip-us.apache.org/repos/asf?p=incubator-gearpump.git;a=shortlog;h=refs/tags/0.8.3-RC1

The release hash is:
https://git-wip-us.apache.org/repos/asf?p=incubator-gearpump.git;a=commit;h=80f49154428cd18b5a27d946b8c9536124849cc9

For information about the contents of this release see:
https://issues.apache.org/jira/browse/GEARPUMP-294?jql=project%20%3D%20GEARPUMP%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20%3D%200.8.3

This vote will be open for 72 hours (Thursday, April 13, 2017 at 3:00AM PST).

Please download the release candidate and evaluate the necessary items
including checking hashes, signatures, build from source, run the
binary artifacts in the binary release and test.
Please vote:

[ ] +1 Release this package as gearpump-0.8.3
[ ] +0 no opinion
[ ] -1 Do not release this package because because...

Thanks,
Karol

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Apache Metron - licensing question

[zeo...@gmail.com]

Ok great, thank you for your feedback.  I did a bit more searching because
that timeline didn't seem right and found that the original
bro-kafka-plugin code[1] first appeared in the Metron repo on February 8,
2016.  My apologies for not properly linking this in my first email, I
hadn't realized it was moved.

1:
https://github.com/apache/incubator-metron/commit/bc140a571a78c428e9ae5a3315c427724183782f

Much appreciated,

Jon

On Mon, Apr 10, 2017, 11:33 PM Joe Witt  wrote:

> Jon,
>
> It appears that the code at [1] was initially committed on Mar 8,
> 2016.  The code in Apache Metron [2] was committed on April 13, 2016.
>
> The code in Metron [2] appears heavily derived from the code in the
> initial repository [1].
>
> In the Metron repository that code has an ASL v2 license and the
> Apache license headers.  That, to me, is where the error occurred.
>
> When the code was copied over, even if it was the original author
> doing it, the original license from [1] should be retained/honored and
> this is very easy to do.  You would simply ensure your source release
> LICENSE indicates the use of the BSD source.  You would still be free
> to alter that source code you've pulled into the Metron codebase and
> build around it as you need. Obviously there are maintenance
> challenges and tradeoffs to consider but the licensing part can be
> pretty clear straightforward other than the question of "how much do I
> have to change the original before it would be appropriate to slap the
> apache license header on a given source file"?
>
> Anyway, I'm not an expert and my advice/interpretation could be wildly
> inaccurate but this looks like it might have an easy solution so
> hopefully that helps.
>
> [1] https://github.com/bro/bro-plugins/tree/master/kafka
> [2]
> https://github.com/apache/incubator-metron/tree/master/metron-sensors/bro-plugin-kafka
>
> Thanks
> Joe
>
> On Mon, Apr 10, 2017 at 8:46 PM, zeo...@gmail.com 
> wrote:
> > Hi all,
> >
> >
> > I recently asked a licensing question to our dev mailing list.  I did get
> > feedback
> > <
> https://lists.apache.org/thread.html/a4e2e7bb7fb7497033696645b011c5604790f23f3802aaab32f1bd01@%3Cdev.metron.apache.org%3E
> >
> > from one of our mentors, but he also requested that we get a double
> check.
> > Please see below for a bit of background and my questions.  Thanks!
> >
> >
> > *Background*
> >
> > We have a situation where a portion of code
> > <
> https://github.com/apache/incubator-metron/tree/master/metron-sensors/bro-plugin-kafka
> >
> > was created for Apache Metron (incubating), which is a plugin for a
> > separate open source project, bro .  The code was
> > later pushed out by the initial author to the bro community under the
> > 3-Clause BSD license
> > , and
> > some important
> > enhancements
> > <
> https://github.com/bro/bro-plugins/commit/b9f1f35415cb0db065348da0a5043a8353b4a0a8
> >
> > have been made to the plugin in that separate community, which we would
> > like to include in our code, while merging with some recent changes
> > <
> https://github.com/apache/incubator-metron/commit/a2452a25caffdd8c35fd9efe0ed49ce0dd2e3781
> >
> > that have been made in the Metron code base as well (i.e. we are not
> simply
> > pulling the code down from the external project).  This was discussed
> > recently
> > <
> https://lists.apache.org/thread.html/c92acd125dae05f0537d4505e0254dfa6382ca9f40edba7d2f4c6224@%3Cdev.metron.apache.org%3E
> >
> > on the Metron dev mailing list, and we wanted to get some clarification
> > before moving forward.
> >
> >
> > *Questions*
> >
> > 1. Is it valid to assume that, as Casey mentioned
> > <
> https://lists.apache.org/thread.html/7468692c96ed0cb012ac9014229694ba8edf3a3b3b55d346eec57019@%3Cdev.metron.apache.org%3E
> >,
> > these are two separate plugins and we can simply make modifications to
> our
> > code base to resolve the current multithreading issue?
> >
> > 2. If we do 1, will this require a line in our LICENSE file as a
> derivative
> > work, or anything else?
> >
> >
> > Thanks,
> >
> > Jon
> > --
> >
> > Jon
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
> --

Jon

Re: How to deactivate/delete old GitHub mirror for log4cxx?

[Pono Takamori]

We can either delete the old Github mirror or put up a link to the new
repo in the description.  Feel free to file a ticket on JIRA for
whatever you folks decide is best :)

Cheers,
-Pono on behalf of Infra

On Tue, Apr 11, 2017 at 12:46 AM, Thorsten Schöning
 wrote:
> Hi,
>
> the logging project log4cxx moved to a new GIT-repo recently, but had
> a mirror on GitHub already in the past at the following place:
>
> https://github.com/apache/log4cxx
>
> The new mirror is the following:
>
> https://github.com/apache/logging-log4cxx
>
> Is there any way to deactivate/delete/whatever the old mirror? I
> already dealt with the PRs, so there shouldn't be anything lost if
> deleted. Or is there at least some note in the project description
> and/or some redirection possible? I don't seem to have access to the
> project or repo.
>
> Thanks!
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
> --
> Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
> AM-SoFT IT-Systeme  http://www.AM-SoFT.de/
>
> Telefon...05151-  9468- 55
> Fax...05151-  9468- 88
> Mobil..0178-8 9468- 04
>
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: How to deactivate/delete old GitHub mirror for log4cxx?

[John D. Ament]

And to be clear - that's an INFRA JIRA ticket -
https://issues.apache.org/jira/browse/INFRA/ (since this went to many
mailing lists)
John

On Tue, Apr 11, 2017 at 6:42 AM Pono Takamori  wrote:

> We can either delete the old Github mirror or put up a link to the new
> repo in the description.  Feel free to file a ticket on JIRA for
> whatever you folks decide is best :)
>
> Cheers,
> -Pono on behalf of Infra
>
> On Tue, Apr 11, 2017 at 12:46 AM, Thorsten Schöning
>  wrote:
> > Hi,
> >
> > the logging project log4cxx moved to a new GIT-repo recently, but had
> > a mirror on GitHub already in the past at the following place:
> >
> > https://github.com/apache/log4cxx
> >
> > The new mirror is the following:
> >
> > https://github.com/apache/logging-log4cxx
> >
> > Is there any way to deactivate/delete/whatever the old mirror? I
> > already dealt with the PRs, so there shouldn't be anything lost if
> > deleted. Or is there at least some note in the project description
> > and/or some redirection possible? I don't seem to have access to the
> > project or repo.
> >
> > Thanks!
> >
> > Mit freundlichen Grüßen,
> >
> > Thorsten Schöning
> >
> > --
> > Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
> > AM-SoFT IT-Systeme  http://www.AM-SoFT.de/
> >
> > Telefon...05151-  9468- 55
> > Fax...05151-  9468- 88
> > Mobil..0178-8 9468- 04
> >
> > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: How to deactivate/delete old GitHub mirror for log4cxx?

[Yury B.]

Leave link to the new location in description, this will be great promo.

On 11 Apr 2017 12:42, "Pono Takamori"  wrote:

We can either delete the old Github mirror or put up a link to the new
repo in the description.  Feel free to file a ticket on JIRA for
whatever you folks decide is best :)

Cheers,
-Pono on behalf of Infra

On Tue, Apr 11, 2017 at 12:46 AM, Thorsten Schöning
 wrote:
> Hi,
>
> the logging project log4cxx moved to a new GIT-repo recently, but had
> a mirror on GitHub already in the past at the following place:
>
> https://github.com/apache/log4cxx
>
> The new mirror is the following:
>
> https://github.com/apache/logging-log4cxx
>
> Is there any way to deactivate/delete/whatever the old mirror? I
> already dealt with the PRs, so there shouldn't be anything lost if
> deleted. Or is there at least some note in the project description
> and/or some redirection possible? I don't seem to have access to the
> project or repo.
>
> Thanks!
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
> --
> Thorsten Schöning   E-Mail: thorsten.schoen...@am-soft.de
> AM-SoFT IT-Systeme  http://www.AM-SoFT.de/
>
> Telefon...05151-  9468- 55
> Fax...05151-  9468- 88
> Mobil..0178-8 9468- 04
>
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Publishing npm modules

[Niclas Hedhman]

Hi,

does anyone have any information on policy/process for uploading npm
modules to global registry https://registry.npmjs.org/

This is for convenience and should be similar to publishing to Maven
Central, but I would like to know if there is anything explicit about it.

Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Help with Dependency Licensing

[Nick Couchman]

Hello, everyone,I'm currently working on the Guacamole incubator project, and 
am developing an extension for the project that has dependencies on binaries 
(JARs via Maven) that are licensed under Category-X licenses.  We've already 
determined that we cannot distribute a binary version of this extension, but, 
since it is an extension (and not core to the functionality of the product), we 
should be able to distribute the source code with build instructions for the 
users.
The question I have is how we should deal with license bundling in this 
scenario?  In the rest of this project, including other extensions, we bundle a 
src/licenses directory that has all of the dependency licenses for the 
extension.  When the binary is built, a resulting file has not only the binary 
for the extension, but also all of the dependency licenses.  Since we're not 
distributing a binary, is there any reason/need for us to package up dependency 
licenses?
Let me know if this needs more clarification - I know this might be a bit 
vague, but I'm in new territory, here, and am happy to provide any further 
information that might help someone help me :-).
Thanks,Nick

Re: Publishing npm modules

[John D. Ament]

On Tue, Apr 11, 2017 at 10:00 AM Niclas Hedhman  wrote:

> Hi,
>
> does anyone have any information on policy/process for uploading npm
> modules to global registry https://registry.npmjs.org/


You may want to check with the Cordova team, see what they've come up.


>
>
> This is for convenience and should be similar to publishing to Maven
> Central, but I would like to know if there is anything explicit about it.
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>

Re: Publishing npm modules

[Sergio Fernández]

INFRA-12886 might be relevant, since Nexus 3.x also comes with npm support.

On Tue, Apr 11, 2017 at 5:04 PM, John D. Ament 
wrote:

> On Tue, Apr 11, 2017 at 10:00 AM Niclas Hedhman 
> wrote:
>
> > Hi,
> >
> > does anyone have any information on policy/process for uploading npm
> > modules to global registry https://registry.npmjs.org/
>
>
> You may want to check with the Cordova team, see what they've come up.
>
>
> >
> >
> > This is for convenience and should be similar to publishing to Maven
> > Central, but I would like to know if there is anything explicit about it.
> >
> > Cheers
> > --
> > Niclas Hedhman, Software Developer
> > http://polygene.apache.org - New Energy for Java
> >
>

Re: Help with Dependency Licensing

[John D. Ament]

Nick,

In general, the LICENSE and NOTICE refers to the contents of the release
itself.  If you're not bundling any of those outside dependencies, then
there would be nothing to include.

Please also note - you can provide a binary release, assuming that the
binary release does not package the outside dependencies and that its clear
that it brings in those other dependencies.

John

On Tue, Apr 11, 2017 at 10:26 AM Nick Couchman
 wrote:

> Hello, everyone,I'm currently working on the Guacamole incubator project,
> and am developing an extension for the project that has dependencies on
> binaries (JARs via Maven) that are licensed under Category-X licenses.
> We've already determined that we cannot distribute a binary version of this
> extension, but, since it is an extension (and not core to the functionality
> of the product), we should be able to distribute the source code with build
> instructions for the users.
> The question I have is how we should deal with license bundling in this
> scenario?  In the rest of this project, including other extensions, we
> bundle a src/licenses directory that has all of the dependency licenses for
> the extension.  When the binary is built, a resulting file has not only the
> binary for the extension, but also all of the dependency licenses.  Since
> we're not distributing a binary, is there any reason/need for us to package
> up dependency licenses?
> Let me know if this needs more clarification - I know this might be a bit
> vague, but I'm in new territory, here, and am happy to provide any further
> information that might help someone help me :-).
> Thanks,Nick

Re: Help with Dependency Licensing

[Nick Couchman]

On Tuesday, April 11, 2017 11:10 AM, John D. Ament  
wrote:


 

 Nick,

> In general, the LICENSE and NOTICE refers to the contents of the release
> itself.  If you're not bundling any of those outside dependencies, then
> there would be nothing to include.

Okay, sounds good, thank you.

> Please also note - you can provide a binary release, assuming that the
> binary release does not package the outside dependencies and that its clear
> that it brings in those other dependencies.

I think that's problematic in this case - Guacamole builds with Maven, and, the 
way it's configured across the project, it goes out and pulls in all of the 
dependencies (binaries in JAR format) and creates a single JAR file that can 
then be copied to the extensions folder and used to extend the main Guacamole 
client.  So, the resulting binary file isn't just the source from the Guacamole 
project, it's also any binary dependencies necessary to run it.  I'll discuss 
with the other folks in the project, but I believe the thought at this point is 
that it's probably simpler to provide folks with the instructions for 
building/packaging themselves than to try to build without the dependencies and 
then have the user load those files into certain locations for the extension in 
question.
Thank you very much for the guidance!
Regards,Nick


On Tue, Apr 11, 2017 at 10:26 AM Nick Couchman
 wrote:

> Hello, everyone,I'm currently working on the Guacamole incubator project,
> and am developing an extension for the project that has dependencies on
> binaries (JARs via Maven) that are licensed under Category-X licenses.
> We've already determined that we cannot distribute a binary version of this
> extension, but, since it is an extension (and not core to the functionality
> of the product), we should be able to distribute the source code with build
> instructions for the users.
> The question I have is how we should deal with license bundling in this
> scenario?  In the rest of this project, including other extensions, we
> bundle a src/licenses directory that has all of the dependency licenses for
> the extension.  When the binary is built, a resulting file has not only the
> binary for the extension, but also all of the dependency licenses.  Since
> we're not distributing a binary, is there any reason/need for us to package
> up dependency licenses?
> Let me know if this needs more clarification - I know this might be a bit
> vague, but I'm in new territory, here, and am happy to provide any further
> information that might help someone help me :-).
> Thanks,Nick


   

Re: Apache Metron - licensing question

[Josh Elser]

Also, it may be worth mentioning: Metron is on its way out of the Apache 
Incubator. A vote has recently passed at the Incubator level for their 
graduation. It is likely that after the next ASF board meeting, Metron 
will no longer be a podling.


I am worried that you did not receive a response from the community on a 
previous message. They should be more than capable to answer your 
questions in the future. I'd suggest you re-ping them if your questions 
go unanswered in the future.


zeo...@gmail.com wrote:

Ok great, thank you for your feedback.  I did a bit more searching because
that timeline didn't seem right and found that the original
bro-kafka-plugin code[1] first appeared in the Metron repo on February 8,
2016.  My apologies for not properly linking this in my first email, I
hadn't realized it was moved.

1:
https://github.com/apache/incubator-metron/commit/bc140a571a78c428e9ae5a3315c427724183782f

Much appreciated,

Jon

On Mon, Apr 10, 2017, 11:33 PM Joe Witt  wrote:


Jon,

It appears that the code at [1] was initially committed on Mar 8,
2016.  The code in Apache Metron [2] was committed on April 13, 2016.

The code in Metron [2] appears heavily derived from the code in the
initial repository [1].

In the Metron repository that code has an ASL v2 license and the
Apache license headers.  That, to me, is where the error occurred.

When the code was copied over, even if it was the original author
doing it, the original license from [1] should be retained/honored and
this is very easy to do.  You would simply ensure your source release
LICENSE indicates the use of the BSD source.  You would still be free
to alter that source code you've pulled into the Metron codebase and
build around it as you need. Obviously there are maintenance
challenges and tradeoffs to consider but the licensing part can be
pretty clear straightforward other than the question of "how much do I
have to change the original before it would be appropriate to slap the
apache license header on a given source file"?

Anyway, I'm not an expert and my advice/interpretation could be wildly
inaccurate but this looks like it might have an easy solution so
hopefully that helps.

[1] https://github.com/bro/bro-plugins/tree/master/kafka
[2]
https://github.com/apache/incubator-metron/tree/master/metron-sensors/bro-plugin-kafka

Thanks
Joe

On Mon, Apr 10, 2017 at 8:46 PM, zeo...@gmail.com
wrote:

Hi all,


I recently asked a licensing question to our dev mailing list.  I did get
feedback
<

https://lists.apache.org/thread.html/a4e2e7bb7fb7497033696645b011c5604790f23f3802aaab32f1bd01@%3Cdev.metron.apache.org%3E

from one of our mentors, but he also requested that we get a double

check.

Please see below for a bit of background and my questions.  Thanks!


*Background*

We have a situation where a portion of code
<

https://github.com/apache/incubator-metron/tree/master/metron-sensors/bro-plugin-kafka

was created for Apache Metron (incubating), which is a plugin for a
separate open source project, bro.  The code was
later pushed out by the initial author to the bro community under the
3-Clause BSD license
, and
some important
enhancements
<

https://github.com/bro/bro-plugins/commit/b9f1f35415cb0db065348da0a5043a8353b4a0a8

have been made to the plugin in that separate community, which we would
like to include in our code, while merging with some recent changes
<

https://github.com/apache/incubator-metron/commit/a2452a25caffdd8c35fd9efe0ed49ce0dd2e3781

that have been made in the Metron code base as well (i.e. we are not

simply

pulling the code down from the external project).  This was discussed
recently
<

https://lists.apache.org/thread.html/c92acd125dae05f0537d4505e0254dfa6382ca9f40edba7d2f4c6224@%3Cdev.metron.apache.org%3E

on the Metron dev mailing list, and we wanted to get some clarification
before moving forward.


*Questions*

1. Is it valid to assume that, as Casey mentioned
<

https://lists.apache.org/thread.html/7468692c96ed0cb012ac9014229694ba8edf3a3b3b55d346eec57019@%3Cdev.metron.apache.org%3E

,
these are two separate plugins and we can simply make modifications to

our

code base to resolve the current multithreading issue?

2. If we do 1, will this require a line in our LICENSE file as a

derivative

work, or anything else?


Thanks,

Jon
--

Jon

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

--


Jon



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Help with Dependency Licensing

[Niclas Hedhman]

Please note that Cat X licenses are deemed to be incompatible with Apache
License, insofar that they are viral in nature, and FSF has made a claim
that dynamically linked languages, such as Java, forces the virality to the
dependent project... Meaning, if you have an import statement linking your
code to such dependency, there is legal uncertainty whether the entire
project must be under the copyleft license in question. FSF certainly
thinks so, and VP Legal has in the past concluded that we should have the
same stance.

So when is the optional Cat X dependency acceptable?

For instance, an acceptably licensed API specification is what our project
depend on, and some runtime mechanism (such as Java Service Loader or
Spring Dependency Injection) make that available. Without this indirection,
we ain't allowed to have dependency on Cat X for Java (and other
circumstances).


HTH
Niclas


On Tue, Apr 11, 2017 at 10:26 PM, Nick Couchman <
nick.couch...@yahoo.com.invalid> wrote:

> Hello, everyone,I'm currently working on the Guacamole incubator project,
> and am developing an extension for the project that has dependencies on
> binaries (JARs via Maven) that are licensed under Category-X licenses.
> We've already determined that we cannot distribute a binary version of this
> extension, but, since it is an extension (and not core to the functionality
> of the product), we should be able to distribute the source code with build
> instructions for the users.
> The question I have is how we should deal with license bundling in this
> scenario?  In the rest of this project, including other extensions, we
> bundle a src/licenses directory that has all of the dependency licenses for
> the extension.  When the binary is built, a resulting file has not only the
> binary for the extension, but also all of the dependency licenses.  Since
> we're not distributing a binary, is there any reason/need for us to package
> up dependency licenses?
> Let me know if this needs more clarification - I know this might be a bit
> vague, but I'm in new territory, here, and am happy to provide any further
> information that might help someone help me :-).
> Thanks,Nick




-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Help with Dependency Licensing

[John D. Ament]

On Tue, Apr 11, 2017 at 12:16 PM Niclas Hedhman  wrote:

> Please note that Cat X licenses are deemed to be incompatible with Apache
> License, insofar that they are viral in nature, and FSF has made a claim
> that dynamically linked languages, such as Java, forces the virality to the
> dependent project... Meaning, if you have an import statement linking your
> code to such dependency, there is legal uncertainty whether the entire
> project must be under the copyleft license in question. FSF certainly
> thinks so, and VP Legal has in the past concluded that we should have the
> same stance.
>
> So when is the optional Cat X dependency acceptable?
>
>
Ugh.  I hit send too soon.  Basically, what we came up with was that a
Cat-X dependency was OK when it was based on some common interface, and
never bundled within the application.  Hibernate was an example that came
up - I can provide a library that ships with integration for hibernate,
based on the JPA specification (which is Cat-B or Cat-A).


> For instance, an acceptably licensed API specification is what our project
> depend on, and some runtime mechanism (such as Java Service Loader or
> Spring Dependency Injection) make that available. Without this indirection,
> we ain't allowed to have dependency on Cat X for Java (and other
> circumstances).
>
>
> HTH
> Niclas
>
>
> On Tue, Apr 11, 2017 at 10:26 PM, Nick Couchman <
> nick.couch...@yahoo.com.invalid> wrote:
>
> > Hello, everyone,I'm currently working on the Guacamole incubator project,
> > and am developing an extension for the project that has dependencies on
> > binaries (JARs via Maven) that are licensed under Category-X licenses.
> > We've already determined that we cannot distribute a binary version of
> this
> > extension, but, since it is an extension (and not core to the
> functionality
> > of the product), we should be able to distribute the source code with
> build
> > instructions for the users.
> > The question I have is how we should deal with license bundling in this
> > scenario?  In the rest of this project, including other extensions, we
> > bundle a src/licenses directory that has all of the dependency licenses
> for
> > the extension.  When the binary is built, a resulting file has not only
> the
> > binary for the extension, but also all of the dependency licenses.  Since
> > we're not distributing a binary, is there any reason/need for us to
> package
> > up dependency licenses?
> > Let me know if this needs more clarification - I know this might be a bit
> > vague, but I'm in new territory, here, and am happy to provide any
> further
> > information that might help someone help me :-).
> > Thanks,Nick
>
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>

Re: Help with Dependency Licensing

[Mike Jumper]

On Tue, Apr 11, 2017 at 9:16 AM, Niclas Hedhman  wrote:

> Please note that Cat X licenses are deemed to be incompatible with Apache
> License, insofar that they are viral in nature, and FSF has made a claim
> that dynamically linked languages, such as Java, forces the virality to the
> dependent project...


I think it's important not to conflate "Cat X" with "GPL".

There are numerous reasons a license might be Cat X, but not all such
licenses are due to the FSF, and not all such licenses are viral to the
extent that the licensing of the source of the linking project is
compromised.

Meaning, if you have an import statement linking your
> code to such dependency, there is legal uncertainty whether the entire
> project must be under the copyleft license in question. FSF certainly
> thinks so, and VP Legal has in the past concluded that we should have the
> same stance.
>

Even in the case of the GPL, my understanding is that the virality takes
hold upon linking (at build time), not upon referencing the API via an
import, include, etc. in the source.

- Mike

Re: Publishing npm modules

[Marvin Humphrey]

On Tue, Apr 11, 2017 at 7:00 AM, Niclas Hedhman  wrote:

> does anyone have any information on policy/process for uploading npm
> modules to global registry https://registry.npmjs.org/

With regards to publication of packages, npm is just another downstream
distribution channel -- like Maven Central, Docker Hub, PyPI, CPAN, Debian,
crates.io, etc.

The main policy point that comes up is this one:

http://www.apache.org/legal/release-policy#publication

Projects SHALL publish official releases and SHALL NOT publish unreleased
materials outside the development community.

The second policy point that comes up frequently has to do with trademarks: we
expect that anything published as "Apache Foo" will actually be "Apache Foo",
and not, say, a vendor-specific "sneak peek" version incorporating
controversial new features.

It can also be important that multiple PMC members have upload permissions
for a given distribution channel.  That's a best practice, not a policy,
though.

But these points apply across all downstream distribution channels, not
just npm.

> This is for convenience and should be similar to publishing to Maven
> Central, but I would like to know if there is anything explicit about it.

Infra provides some extra support for certain kinds of distribution (we run
repository.apache.org, we used to run a PEAR repo, etc).  I don't know of
any special technical support related to npm, though.

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Publishing npm modules

[Niclas Hedhman]

Thanks, that was very helpful.

On Wed, Apr 12, 2017 at 7:03 AM, Marvin Humphrey 
wrote:

> On Tue, Apr 11, 2017 at 7:00 AM, Niclas Hedhman 
> wrote:
>
> > does anyone have any information on policy/process for uploading npm
> > modules to global registry https://registry.npmjs.org/
>
> With regards to publication of packages, npm is just another downstream
> distribution channel -- like Maven Central, Docker Hub, PyPI, CPAN, Debian,
> crates.io, etc.
>
> The main policy point that comes up is this one:
>
> http://www.apache.org/legal/release-policy#publication
>
> Projects SHALL publish official releases and SHALL NOT publish
> unreleased
> materials outside the development community.
>
> The second policy point that comes up frequently has to do with
> trademarks: we
> expect that anything published as "Apache Foo" will actually be "Apache
> Foo",
> and not, say, a vendor-specific "sneak peek" version incorporating
> controversial new features.
>
> It can also be important that multiple PMC members have upload permissions
> for a given distribution channel.  That's a best practice, not a policy,
> though.
>
> But these points apply across all downstream distribution channels, not
> just npm.
>
> > This is for convenience and should be similar to publishing to Maven
> > Central, but I would like to know if there is anything explicit about it.
>
> Infra provides some extra support for certain kinds of distribution (we run
> repository.apache.org, we used to run a PEAR repo, etc).  I don't know of
> any special technical support related to npm, though.
>
> Marvin Humphrey
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Help with Dependency Licensing

[Niclas Hedhman]

On Wed, Apr 12, 2017 at 12:31 AM, Mike Jumper 
wrote:

>
> Even in the case of the GPL, my understanding is that the virality takes
> hold upon linking (at build time), not upon referencing the API via an
> import, include, etc. in the source.
>

Your understanding is, simply put, not aligned with the FSF, and the ASF
has decided to follow FSF's conclusion. In fact, a former Director at ASF
and lawyer, Larry Rosen, was trying to fight this stance, basically making
the claim that GPL is overreaching, and that ended with Larry being kicked
out (not only for this particular question).


http://www.gnu.org/licenses/lgpl-java.html"; emphasis="mine">
It has always been the FSF's position that *dynamically linking
applications to libraries creates a single work derived* from both the
library code and the application code.The GPL requires that all derivative
works be licensed as a whole under the terms of the GPL, an effect which
can be described as “hereditary.” So, if an application links to a library
licensed under the GPL, the application too must be licensed under the GPL.
 :
 :
FSF's position has remained constant throughout: the LGPL works as intended
with all known programming languages, including Java. Applications which
link to LGPL libraries need not be released under the LGPL. Applications
need only follow the requirements in section 6 of the LGPL: allow new
versions of the library to be linked with the application; and allow
reverse engineering to debug this.


At first, the "link to LGPL libraries need not be released under LGPL" is
an indicator that Apache licensed projects could depend on LGPL projects,
but it is this "Section 6" that makes LGPL incompatible, since we don't
require this of our downstreams. This was hotly debated back in the days
when this FSF article was written, and it took us a year or two to nail it
down.


More info at http://www.gnu.org/licenses/gpl-faq.html

John, As for the case of Hibernate; If you depend on JPA, you don't depend
on Hibernate. However, if you depend on JPA in a way so that only Hibernate
makes the project work, and that EclipseLink or other implementations can't
be used instead, then you are in gray territory and should ask Legal for
advice. I am uncertain of that position.


Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

Re: Help with Dependency Licensing

[Mike Jumper]

On Apr 11, 2017 17:29, "Niclas Hedhman"  wrote:

On Wed, Apr 12, 2017 at 12:31 AM, Mike Jumper 
wrote:

>
> Even in the case of the GPL, my understanding is that the virality takes
> hold upon linking (at build time), not upon referencing the API via an
> import, include, etc. in the source.
>

Your understanding is, simply put, not aligned with the FSF, and the ASF
has decided to follow FSF's conclusion. In fact, a former Director at ASF
and lawyer, Larry Rosen, was trying to fight this stance, basically making
the claim that GPL is overreaching, and that ended with Larry being kicked
out (not only for this particular question).


http://www.gnu.org/licenses/lgpl-java.html"; emphasis="mine">
It has always been the FSF's position that *dynamically linking
applications to libraries creates a single work derived* from both the
library code and the application code


Sorry, but I don't see the disagreement between the above statement and "the
virality takes hold upon linking (at build time)". Doesn't this creation of
a derivative work, even in the FSF interpretation, occur at the time of
linking, and not at the time that the source is written?

A piece of uncompiled source code is not yet linked. Linking is part of the
build and/or runtime processes.

- Mike

Re: Help with Dependency Licensing

[John D. Ament]

On Tue, Apr 11, 2017 at 8:40 PM Mike Jumper 
wrote:

> On Apr 11, 2017 17:29, "Niclas Hedhman"  wrote:
>
> On Wed, Apr 12, 2017 at 12:31 AM, Mike Jumper 
> wrote:
>
> >
> > Even in the case of the GPL, my understanding is that the virality takes
> > hold upon linking (at build time), not upon referencing the API via an
> > import, include, etc. in the source.
> >
>
> Your understanding is, simply put, not aligned with the FSF, and the ASF
> has decided to follow FSF's conclusion. In fact, a former Director at ASF
> and lawyer, Larry Rosen, was trying to fight this stance, basically making
> the claim that GPL is overreaching, and that ended with Larry being kicked
> out (not only for this particular question).
>
>
> http://www.gnu.org/licenses/lgpl-java.html"; emphasis="mine">
> It has always been the FSF's position that *dynamically linking
> applications to libraries creates a single work derived* from both the
> library code and the application code
>
>
> Sorry, but I don't see the disagreement between the above statement and
> "the
> virality takes hold upon linking (at build time)". Doesn't this creation of
> a derivative work, even in the FSF interpretation, occur at the time of
> linking, and not at the time that the source is written?
>
> A piece of uncompiled source code is not yet linked. Linking is part of the
> build and/or runtime processes.
>
>
Mike, if I had to guess, the problem is two pieces.  Assumptions about
licenses in use, and assumptions about how build tools work.  What you're
describing sounds like GPL and statically linked libraries.  The Cat-X
section applies to many licenses, many languages.  For instance, JSON
license was moved to Cat-X due to a "do no harm" clause.  Some of the
original licensing comments I cited were based on a discussion around
non-transitive licenses, such as LGPL and Amazon Software License.

If I had to summarize some next steps - anytime you're dealing with Cat-X,
seek out legal (not incubator) opinion, review existing discussions (even
if not captured on the website) and wait for a decision.  All Cat-X is
never in source format, never as a binary must-have core dependency, and
typically a very rare case where a binary optional dependency is OK.


> - Mike
>

Re: Help with Dependency Licensing

[John D. Ament]

On Tue, Apr 11, 2017 at 8:29 PM Niclas Hedhman  wrote:

> On Wed, Apr 12, 2017 at 12:31 AM, Mike Jumper 
> wrote:
>
> >
> > Even in the case of the GPL, my understanding is that the virality takes
> > hold upon linking (at build time), not upon referencing the API via an
> > import, include, etc. in the source.
> >
>
> Your understanding is, simply put, not aligned with the FSF, and the ASF
> has decided to follow FSF's conclusion. In fact, a former Director at ASF
> and lawyer, Larry Rosen, was trying to fight this stance, basically making
> the claim that GPL is overreaching, and that ended with Larry being kicked
> out (not only for this particular question).
>
>
> http://www.gnu.org/licenses/lgpl-java.html"; emphasis="mine">
> It has always been the FSF's position that *dynamically linking
> applications to libraries creates a single work derived* from both the
> library code and the application code.The GPL requires that all derivative
> works be licensed as a whole under the terms of the GPL, an effect which
> can be described as “hereditary.” So, if an application links to a library
> licensed under the GPL, the application too must be licensed under the GPL.
>  :
>  :
> FSF's position has remained constant throughout: the LGPL works as intended
> with all known programming languages, including Java. Applications which
> link to LGPL libraries need not be released under the LGPL. Applications
> need only follow the requirements in section 6 of the LGPL: allow new
> versions of the library to be linked with the application; and allow
> reverse engineering to debug this.
> 
>
> At first, the "link to LGPL libraries need not be released under LGPL" is
> an indicator that Apache licensed projects could depend on LGPL projects,
> but it is this "Section 6" that makes LGPL incompatible, since we don't
> require this of our downstreams. This was hotly debated back in the days
> when this FSF article was written, and it took us a year or two to nail it
> down.
>
>
> More info at http://www.gnu.org/licenses/gpl-faq.html
>
> John, As for the case of Hibernate; If you depend on JPA, you don't depend
> on Hibernate. However, if you depend on JPA in a way so that only Hibernate
> makes the project work, and that EclipseLink or other implementations can't
> be used instead, then you are in gray territory and should ask Legal for
> advice. I am uncertain of that position.
>
>
The info I provided was based on a discussion on legal, originally carried
over from a discussion on optional dependencies on software licensed under
the Amazon Software License -
https://lists.apache.org/thread.html/2630f3d9540f02ef24f5e03cc171c4a2975bd8965c80a1965a55c0b4@%3Clegal-discuss.apache.org%3E



>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>

Re: Help with Dependency Licensing

[Niclas Hedhman]

On Wed, Apr 12, 2017 at 9:03 AM, John D. Ament 
wrote:

>
> The info I provided was based on a discussion on legal, originally carried
> over from a discussion on optional dependencies on software licensed under
> the Amazon Software License -
> https://lists.apache.org/thread.html/2630f3d9540f02ef24f5e03cc171c4
> a2975bd8965c80a1965a55c0b4@%3Clegal-discuss.apache.org%3E
>
>
Yet another long thread on the same topic. I was on Legal for ~5 years and
Hibernate came up again and again. Since their is an JPA implementation
in-house, there would be no need to depend on Hibernate for Apache
projects. And perhaps it is unfair to talk about Hibernate if you want to
discuss Amazon licensing terms, but that is where this thread headed (until
I stopped reading about half way down).

People (myself included at times) forget that our own individual 'opinion'
and 'interpretation' are irrelevant. What matters are "legal opinion" from
a lawyer, who is guessing(!) what a court/judge would rule, and to a lesser
degree the "intent of the license author", who in (L)GPL case is FSF Legal
Counsel (Eben Mogel just stepped down, btw), lawyers spending years to
figure this out, and when FSF declare an intent we either follow that or
take it to court.
Then to make matters worse, the software project author sometimes expresses
an intent that differs from the intent of its license author, and the
"exceptions" comes to play (or not).


Cheers
-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java

RE: [VOTE] Apache Gearpump (incubating) 0.8.3-RC1

[Wang, Gang1]

+1, Thanks.

Best Regards
Gary (Wang, Gang)

External Contact:
  (323)801-6286 (WhatsApp)

-Original Message-
From: Karol Brejna [mailto:karolbre...@apache.org] 
Sent: Tuesday, April 11, 2017 2:34 AM
To: general@incubator.apache.org
Cc: d...@gearpump.incubator.apache.org
Subject: [VOTE] Apache Gearpump (incubating) 0.8.3-RC1

Hi IPMC Community,

The PPMC vote to release Apache Gearpump (incubating) 0.8.3-RC1 has passed.
We would like to now submit this release candidate to the IPMC.

The PPMC vote thread is here:
https://lists.apache.org/thread.html/0e1022d2f3b5b2a2b879e4c278d7fc44d094058550d47ae7e07702ec@%3Cdev.gearpump.apache.org%3E

The source and binary tarballs, including signatures, digests, etc.
can be found at:
https://dist.apache.org/repos/dist/dev/incubator/gearpump/0.8.3-incubating/RC1/

Release artifacts are signed with the key with fingerprint:
3F12 81A2 DB58 0842 5ABA  6962 D8A8 4FBC 0A83 B291

The KEYS file is available here:
https://dist.apache.org/repos/dist/dev/incubator/gearpump/KEYS

The tag to be voted upon is:
https://git-wip-us.apache.org/repos/asf?p=incubator-gearpump.git;a=shortlog;h=refs/tags/0.8.3-RC1

The release hash is:
https://git-wip-us.apache.org/repos/asf?p=incubator-gearpump.git;a=commit;h=80f49154428cd18b5a27d946b8c9536124849cc9

For information about the contents of this release see:
https://issues.apache.org/jira/browse/GEARPUMP-294?jql=project%20%3D%20GEARPUMP%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20%3D%200.8.3

This vote will be open for 72 hours (Thursday, April 13, 2017 at 3:00AM PST).

Please download the release candidate and evaluate the necessary items 
including checking hashes, signatures, build from source, run the binary 
artifacts in the binary release and test.
Please vote:

[ ] +1 Release this package as gearpump-0.8.3 [ ] +0 no opinion [ ] -1 Do not 
release this package because because...

Thanks,
Karol

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org