Re: [DISCUSS] Hudi Incubation Proposal

[Julien Le Dem]

Sorry I misspoke, I won’t have time to be a *mentor* but the champion role
is what I’ve done so far and leads to the vote. so in the interest of not
blocking the submission, I would suggest that I stay as champion and be
removed as mentor while we add the volunteers who chimed in on this thread.

https://incubator.apache.org/policy/roles_and_responsibilities.html#champion
Champion

A candidate project shall be sponsored by an Officer
 orMember
 of the Foundation. The
Champion assists the candidate on their initial submission to a Sponsor.
While private conversations are not generally encouraged within the Apache
community, the Champion’s relationship with the Candidate should allow for
this in order to educate the Candidate about the Apache Way and prepare the
project for the questions and issues likely to be raised by the community.

Before incubation begins, the Champion is expected to: * help with any
process/ASF related hurdles before the Candidate enters incubation * help
find the right people in the ASF to speak with * help to find Mentors *
drive the process of entering the Incubator, leading to a vote to accept
the proposed podling

On Sat, Jan 5, 2019 at 14:56 Justin Mclean  wrote:

> Hi,
>
> > I’m currently listed as the champion for this proposal but I just had a
> new
> > baby and I’m currently on paternity leave. I don’t think I’ll have the
> > bandwidth to properly champion the project.
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

[CANCELLED][VOTE] Release Apache MXNet (incubating) version 1.4.0.rc0

[Steffen Rochel]

Dear community -
I'm cancelling the vote due to -1 feedback from Justin due to outstanding
licensing issues.  For details see
https://lists.apache.org/thread.html/ebb8c4c00fb66dd98da13621c7dcb8753fee57562a861d61379d31e9@%3Cgeneral.incubator.apache.org%3E


The MXNet community will address the issues raised and  and send out rc1
for another vote.

Regards,
Steffen

Re: Official releases vs unreleased code

[Mark Thomas]

On 07/01/2019 12:05, Geertjan Wielenga wrote:
> So, just to be clear what this means in the context of Apache NetBeans.
> 
> Here's two different scenarios that relate to this:
> 
> 1. CoolBeans (coolbeans.xyz) is a distribution of Apache NetBeans, with the
> difference that it includes the 'enterprise' cluster (i.e., Jakarta/Java EE
> features) of Apache NetBeans, which we have not yet released. We are
> working to release this as part of our upcoming release and have several
> licensing issues remaining. However, since CoolBeans is not distributed by
> Apache, CoolBeans is not constrained by Apache's licensing concerns.
> 
> Reading Justin's e-mail, I interpret him to state that it is not allowed to
> promote releases to the wider community that contain not released code,
> i.e., on the Apache NetBeans webpage, we cannot promote CoolBeans, on
> Apache NetBeans Twitter, we cannot promote CoolBeans, on the Apache
> NetBeans mailing lists, we cannot promote CoolBeans.
> 
> Is this interpretation correct?

I would suggest reading "promote" in this context as "advertise as an
official ASF release" rather than "make people aware it exists".

Scenario 1 is a different issue. Coolbeans is a non-ASF product. That
makes it more of a branding / community issue than one of release policy.

Generally, projects don't promote down stream releases. Doing so creates
a risk of the ASF being viewed as biased (in favour of the organisation
producing the downstream release) rather than independent.

That said, if the community views it is in the best interest of the
community to promote Coolbeans then the community can do so. The
expectation is that the community would be equally happy to promote any
similar downstream project. If there are criteria about what the
community is and is not willing to promote then those criteria should be
(publicly) documented up front.


> 2. Even though we have not released the 'enterprise' cluster, we do have
> plugins from before we were an Apache project for Java/Jakarta EE features.
> These are available from a plugin portal and are built from the the same
> code as is found in the Apache NetBeans GitHub, though created from before
> that code was at Apache.
> 
> Can we promote these plugins?

Again, as non-ASF releases "make people aware they exist" is fine (same
caveats as above) but "advertise them as official ASF releases" then no.


Generally, I would only expect to see official ASF releases on:
- announcement e-mails from the project
- project main download page
- etc.

HTH,

Mark

> 
> Thanks,
> 
> Gj
> 
> 
> 
> 
> 
> On Sun, Jan 6, 2019 at 12:21 AM Justin Mclean 
> wrote:
> 
>> Hi,
>>
>> Over the last few months I’ve run into 1/2 dozen podlings who are making
>> and promoting releases to the wider community that contain unreleased code,
>> and I’m a little surprised that they were unaware that this is not allowed.
>> This also has come up in feedback received from the exit questionnaire.
>>
>> In the release policy [3] it clearly states:
>> "Projects MUST direct outsiders towards official releases rather than raw
>> source repositories, nightly builds, snapshots, release candidates, or any
>> other similar packages.”
>>
>> This has been discussed many times but these two legal JIRAs [1][2] spell
>> it out quite clearly. And while these tickets refer to docker the same
>> applies to any distribution mechanism.
>>
>> In short “It is appropriate to distribute official releases through
>> downstream channels, but inappropriate to distribute unreleased materials
>> through them.”
>>
>> So if your projects is using docker, PiPY, GitHub releases, npm or any
>> other ways of distribution please make sure that the wider community is
>> only pointed at official release and the best way to do this is not to
>> publish unreleased code on those platforms. Ask yourself is someone outside
>> of the project likely to use this and if the answer is yes then reconsider
>> how you are using that distribution channel and make sure it only contains
>> official releases.
>>
>> Thanks,
>> Justin
>>
>> 1. https://issues.apache.org/jira/browse/LEGAL-270
>> 2. https://issues.apache.org/jira/browse/LEGAL-427
>> 3. http://www.apache.org/legal/release-policy.html#publication
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
> 


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

Re: Official releases vs unreleased code

[Geertjan Wielenga]

So, just to be clear what this means in the context of Apache NetBeans.

Here's two different scenarios that relate to this:

1. CoolBeans (coolbeans.xyz) is a distribution of Apache NetBeans, with the
difference that it includes the 'enterprise' cluster (i.e., Jakarta/Java EE
features) of Apache NetBeans, which we have not yet released. We are
working to release this as part of our upcoming release and have several
licensing issues remaining. However, since CoolBeans is not distributed by
Apache, CoolBeans is not constrained by Apache's licensing concerns.

Reading Justin's e-mail, I interpret him to state that it is not allowed to
promote releases to the wider community that contain not released code,
i.e., on the Apache NetBeans webpage, we cannot promote CoolBeans, on
Apache NetBeans Twitter, we cannot promote CoolBeans, on the Apache
NetBeans mailing lists, we cannot promote CoolBeans.

Is this interpretation correct?

2. Even though we have not released the 'enterprise' cluster, we do have
plugins from before we were an Apache project for Java/Jakarta EE features.
These are available from a plugin portal and are built from the the same
code as is found in the Apache NetBeans GitHub, though created from before
that code was at Apache.

Can we promote these plugins?

Thanks,

Gj





On Sun, Jan 6, 2019 at 12:21 AM Justin Mclean 
wrote:

> Hi,
>
> Over the last few months I’ve run into 1/2 dozen podlings who are making
> and promoting releases to the wider community that contain unreleased code,
> and I’m a little surprised that they were unaware that this is not allowed.
> This also has come up in feedback received from the exit questionnaire.
>
> In the release policy [3] it clearly states:
> "Projects MUST direct outsiders towards official releases rather than raw
> source repositories, nightly builds, snapshots, release candidates, or any
> other similar packages.”
>
> This has been discussed many times but these two legal JIRAs [1][2] spell
> it out quite clearly. And while these tickets refer to docker the same
> applies to any distribution mechanism.
>
> In short “It is appropriate to distribute official releases through
> downstream channels, but inappropriate to distribute unreleased materials
> through them.”
>
> So if your projects is using docker, PiPY, GitHub releases, npm or any
> other ways of distribution please make sure that the wider community is
> only pointed at official release and the best way to do this is not to
> publish unreleased code on those platforms. Ask yourself is someone outside
> of the project likely to use this and if the answer is yes then reconsider
> how you are using that distribution channel and make sure it only contains
> official releases.
>
> Thanks,
> Justin
>
> 1. https://issues.apache.org/jira/browse/LEGAL-270
> 2. https://issues.apache.org/jira/browse/LEGAL-427
> 3. http://www.apache.org/legal/release-policy.html#publication
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache MXNet (incubating) version 1.4.0.rc0

[Hagay Lupesko]

Thanks for clarifying Justin.

On Mon, Jan 7, 2019 at 1:06 AM Justin Mclean 
wrote:

> Hi,
>
> > Good call. I will work with my colleagues in Amazon to try and help with
> > this.
>
> Great if you need any help just ask.
>
> > I'm not sure what is the best approach with 3P code issues though: you
> call
> > out 3rdparty/onnx-tensorrt as having a mix of license types and having
> > other issues. However, this is part of another repo, integrated into
> MXNet
> > as a git submodule (https://github.com/onnx/onnx-tensorrt.git).
> > Is it necessary to "fix" licensing of 3P packages as well? I think this
> > will be very difficult…
>
> Fixing downstream is good but not required, it all comes down to the
> guiding principle [1].  You need to look inside and 3rd party code to see
> what it contains and list all licenses that are bundled.
>
> A simple example is jQuery which is MIT licensed but includes MIT licensed
> Sizzle so both of these need to mention in the LICENSE file.
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/dev/licensing-howto.html#guiding-principle
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Apache MXNet (incubating) version 1.4.0.rc0

[Justin Mclean]

Hi,

> Good call. I will work with my colleagues in Amazon to try and help with
> this.

Great if you need any help just ask.

> I'm not sure what is the best approach with 3P code issues though: you call
> out 3rdparty/onnx-tensorrt as having a mix of license types and having
> other issues. However, this is part of another repo, integrated into MXNet
> as a git submodule (https://github.com/onnx/onnx-tensorrt.git).
> Is it necessary to "fix" licensing of 3P packages as well? I think this
> will be very difficult…

Fixing downstream is good but not required, it all comes down to the guiding 
principle [1].  You need to look inside and 3rd party code to see what it 
contains and list all licenses that are bundled.

A simple example is jQuery which is MIT licensed but includes MIT licensed 
Sizzle so both of these need to mention in the LICENSE file.

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#guiding-principle
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache MXNet (incubating) version 1.4.0.rc0

[Hagay Lupesko]

Justin,

Good call. I will work with my colleagues in Amazon to try and help with
this.

I'm not sure what is the best approach with 3P code issues though: you call
out 3rdparty/onnx-tensorrt as having a mix of license types and having
other issues. However, this is part of another repo, integrated into MXNet
as a git submodule (https://github.com/onnx/onnx-tensorrt.git).
Is it necessary to "fix" licensing of 3P packages as well? I think this
will be very difficult...

Curious to get your thoughts and perspective.

Hagay


On Sat, Jan 5, 2019 at 5:50 PM Justin Mclean 
wrote:

> Hi,
>
> I’m still -1 (binding) there are also some LICENSE issues that need to be
> looked into.
>
> I checked:
> - incubating in name
> - signature and hashes good
> - DISCLAIMER exists
> - LICENSE and NOTICE need some work (see below)
> - No unexpected binary files
> - A number of files are missing headers and it’s unclear how some of these
> are licensed
> - I didn’t try to compile
>
> These LICENSE files mentioned in LICENSE do not exist:
> - 3rdparty/tvm/dmlc-core/LICENSE
> - 3rdparty/tvm/nnvm/LICENSE
> - R-package/LICENSE
> - nnvm/tvm/HalideIR/LICENSE
>
> LICENSE is missing mention of:
> - ./docs/_static/js/clipboard.min.js (MIT licensed © Zeno Rocha) You may
> also want to include the non-minified code as that could be considered to
> being “compiled" code and could be thought of as category X.
> - ./julia
> - ./perl-package ? (unclear if this was developed at the ASF or not)
> - 3rdparty/openmp/LICENSE.txt
> -
> /apache-mxnet-src-1.4.0.rc0-incubating/3rdparty/mkldnn/src/cpu/xbyak/xbyak.h
> and other .h files in that directory - note the double headers
> - apache-mxnet-src-1.4.0.rc0-incubating/3rdparty/cub/test/mersenne.h
>
> And probably other files. It’s very hard to review when the copyright
> owners are not clearly indicated in LICENSE. It would help if all license
> file were placed in one directory, that way it would be easy to search if
> all required licenses have been included.
>
> I think a lot more work is needed on the LICENSE here for instance taking
> a look at one directory:
> 3rdparty/onnx-tensorrt
>
> With the LICENSE file containing:
> MIT License
> Copyright (c) 2018, NVIDIA CORPORATION. All rights reserved.
> Copyright (c) 2018 Open Neural Network Exchange
>
> However searching for license and copyright under that you can see it
> contains a mix of different licensed files, including MIT, BSD, Apache and
> at least 30 different copyright statements. I can see some of the
> sub-directory are also referenced but it doesn’t seem complete to me.
>
> There are lots of other files missing headers, in some cases it could be
> assumed that they are 3rd party files, but in some cases it is unclear. For
> instance:
>
> File in ./docs/_static/js/*.,js are missing headers. How are theses
> licensed?
>
> This files are missing headers - how are they licensed?
>   ./src/operator/special_functions-inl.h
>   ./src/operator/contrib/nn/deformable_im2col.cuh
>   ./src/operator/contrib/nn/deformable_im2col.h
>   ./src/operator/nn/im2col.cuh
>   ./src/operator/nn/im2col.h
>   ./src/operator/nn/pool.h
>
> It might help you if you used a tool like https://www.fossology.org to
> track everything a you have a large number of 3rd party licensed software
> from a large number of authors.
>
> Thanks,
> Justin
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>