Paul,
1. Yes, no third party source code was used/included.
2. As far as SGA I believe we have to submit it before graduation. There's
no requirement to get it done for the 1st release.
3. Our binary is an all-inclusive JAR that bundles all dependencies (except
for GPLv3 licensed ones).

Thanks,
--
Aaron Radzinski



On Thu, Apr 9, 2020 at 5:05 PM Paul King <[email protected]> wrote:

> The source code license looks good to me (on the presumption that no third
> party source code is included which I believe is the case).
> There was mention earlier of DataLingvo executing an SGA. Has that
> occurred? (question for Nikita?)
>
> The NOTICE file for source code shouldn't have the additional
> entries, e.g.:
>
>> OpenZipkin
>> Copyright 2015-2020 The OpenZipkin Authors
>> ASLv2 License
>
> would be needed only if you had a source file from OpenZipkin included in
> NLPCraft source code.
>
> For "Complementary Binary Release", is that a jar which is just the
> compiled source code or a zip bundle with dependencies?
> In general, a convenience binary jar would not need to address
> license/notice issues for transitive dependencies.
> A zip bundle would need something close to your suggestion.
>
> Cheers, Paul.
>
> On Thu, Apr 9, 2020 at 1:41 PM Aaron Radzinski <[email protected]>
> wrote:
>
>> Paul, et. al.,
>> Based on these examples here's what I've come up with. NLPCraft will have
>> both ASF (source) release and complimentary binaries, and they will have
>> separate LICENSE files.
>>
>> ASF (source code) Release:
>> - LICENSE
>> https://github.com/apache/incubator-nlpcraft/blob/master/LICENSE
>> - NOTICE https://github.com/apache/incubator-nlpcraft/blob/master/NOTICE
>>
>> Complimentary Binary Release:
>> - LICENSE
>> https://github.com/apache/incubator-nlpcraft/blob/master/bindist/LICENSE
>> - NOTICE https://github.com/apache/incubator-nlpcraft/blob/master/NOTICE
>>
>> NOTE: NOTICE file is the same for both releases.
>>
>> Thoughts, comments?
>> --
>> Aaron Radzinski
>>
>>
>>
>> On Tue, Apr 7, 2020 at 5:40 AM Furkan KAMACI <[email protected]>
>> wrote:
>>
>>> Hi,
>>>
>>> Here is another example which has been graduated just a couple of months
>>> ago: https://github.com/apache/druid/blob/master/LICENSE
>>>
>>> Kind Regards,
>>> Furkan KAMACI
>>>
>>> On Tue, Apr 7, 2020 at 2:49 PM Paul King <[email protected]> wrote:
>>>
>>> > The LICENSE and NOTICE from NIFI look good to me for the source
>>> artifact:
>>> > https://github.com/apache/nifi
>>> >
>>> > The LICENSE and NOTICE for the NIFI bundle also look good to me:
>>> > https://github.com/apache/nifi/tree/master/nifi-assembly
>>> >
>>> > HTH, Paul.
>>> >
>>> >
>>> > On Tue, Apr 7, 2020 at 9:43 PM Paul King <[email protected]> wrote:
>>> >
>>> > > Most projects should be the same. I am most familiar with Groovy and
>>> > > believe it is done correctly there. Gradle is used for building which
>>> > might
>>> > > make it harder to mimic given NLPCraft is using maven. I'll take a
>>> quick
>>> > > look at some others ...
>>> > >
>>> > > On Tue, Apr 7, 2020 at 6:53 PM Aaron Radzinski <
>>> > [email protected]>
>>> > > wrote:
>>> > >
>>> > >> Paul,
>>> > >> Can you point to some ASF project(s) that has done it right? I've
>>> looked
>>> > >> at several and they all seem to be doing differently...
>>> > >>
>>> > >> Thank you,
>>> > >> --
>>> > >> Aaron Radzinski
>>> > >>
>>> > >>
>>> > >>
>>> > >> On Mon, Apr 6, 2020 at 9:21 PM Paul King <[email protected]>
>>> wrote:
>>> > >>
>>> > >>> Another important concept is that for any artifact, the included
>>> > >>> NOTICE/LICENSE should be the minimum required for that artifact (or
>>> > >>> instead
>>> > >>> of thinking it as the minimum, think just accurately specified for
>>> that
>>> > >>> artifact).
>>> > >>>
>>> > >>> So, the list you provide would possibly be appropriate for a zip
>>> > >>> distribution, assuming that is desirable. If that is needed, I'd
>>> change
>>> > >>> the
>>> > >>> wording from:
>>> > >>> "NLPCraft project uses or integrates with the following 3rd party
>>> > >>> software
>>> > >>> (binary dependencies) that is licensed under non-Apache License
>>> 2.0"
>>> > >>> to something like:
>>> > >>> "This NLPCraft distribution bundles 3rd party binary dependencies
>>> that
>>> > >>> are
>>> > >>> licensed as outlined below."
>>> > >>>
>>> > >>> In general, the source distribution LICENSE would not need (and
>>> > therefore
>>> > >>> should not have) those entries listed.
>>> > >>>
>>> > >>> A binary jar artifact suitable for publishing in a repo, assuming
>>> one
>>> > is
>>> > >>> needed, would also not need most (if not all) of those entries. The
>>> > >>> LICENSE
>>> > >>> and NOTICE pertain to the artifact itself not listed dependencies
>>> > (which
>>> > >>> will already contain their own LICENSE/NOTICE info).
>>> > >>>
>>> > >>> I'd also expect in general modifications to the NOTICE file. It
>>> would
>>> > >>> include any copyright notice sections from even ASF2 licensed
>>> > >>> dependencies
>>> > >>> which aren't specifically "copyright ASF", e.g. might be
>>> individuals.
>>> > In
>>> > >>> addition, if any of the third party licenses request some kind of
>>> > >>> acknowledgement, that would go in the NOTICE file(s).
>>> > >>>
>>> > >>> Cheers, Paul.
>>> > >>>
>>> > >>>
>>> > >>> On Tue, Apr 7, 2020 at 10:58 AM Aaron Radzinski <
>>> > >>> [email protected]>
>>> > >>> wrote:
>>> > >>>
>>> > >>> > Paul, Roman, et. al.,
>>> > >>> > I've listed non-ASF2.0 licenses for our dependencies here:
>>> > >>> > https://github.com/apache/incubator-nlpcraft/blob/master/LICENSE
>>> > >>> >
>>> > >>> > Please review and let me know if this passes the muster.
>>> > >>> >
>>> > >>> > Thank you,
>>> > >>> > --
>>> > >>> > Aaron Radzinski
>>> > >>> >
>>> > >>> >
>>> > >>> >
>>> > >>> > On Mon, Apr 6, 2020 at 2:58 PM Roman Shaposhnik <
>>> > [email protected]>
>>> > >>> > wrote:
>>> > >>> >
>>> > >>> > > On Mon, Apr 6, 2020 at 12:48 PM Aaron Radzinski
>>> > >>> > > <[email protected]> wrote:
>>> > >>> > > >
>>> > >>> > > > Mentors,
>>> > >>> > > > I'm confused on how to (and why) list licenses for all
>>> project's
>>> > >>> > > > dependencies. To do it explicitly is a major time sink and
>>> it's
>>> > >>> very
>>> > >>> > hard
>>> > >>> > > > to maintain it this way going forward. How do projects
>>> approach
>>> > >>> this in
>>> > >>> > > an
>>> > >>> > > > automated way? Will this be enough to provide an Apache RAT
>>> > report?
>>> > >>> > >
>>> > >>> > > It depends on what you want to distribute. There are two
>>> artifacts
>>> > >>> that
>>> > >>> > > you can
>>> > >>> > > distribute:
>>> > >>> > >    #1 source code tarball
>>> > >>> > >    #2 binary convenience archives (of any kind)
>>> > >>> > >
>>> > >>> > > For both your downstream consumers have know *exactly* what
>>> > licenses
>>> > >>> > > are covering:
>>> > >>> > >    #1 every single line of code in every file
>>> > >>> > >    #2 every single bit
>>> > >>> > >
>>> > >>> > > Now, #1 is somewhat easier since all the new code is going to
>>> be
>>> > >>> licensed
>>> > >>> > > under ALv2. Still, there will be cases when you (or your build
>>> > >>> system)
>>> > >>> > > statically pulls source code in that ends up in your release
>>> source
>>> > >>> > tarball
>>> > >>> > > that wasn't developed by you and is available under a different
>>> > >>> license.
>>> > >>> > > That has to be tracked very, very carefully.
>>> > >>> > >
>>> > >>> > > In fact, that is exactly why a lot of downstream consumers
>>> trust
>>> > ASF
>>> > >>> > > (that we won't subject them to anything by ALv2 compatible
>>> > licenses)
>>> > >>> > > and don't trust a random GH project where somebody simply
>>> slapped
>>> > >>> > > an ALv2 license on their repo.
>>> > >>> > >
>>> > >>> > > As for #2 -- this is where the hell typically breaks lose and
>>> > that's
>>> > >>> > where
>>> > >>> > > you either do the same good job you do with #1 (there are not
>>> > >>> > > shortcuts -- sorry)
>>> > >>> > >
>>> > >>> > > OR
>>> > >>> > >
>>> > >>> > > You simply decide NOT to release binary artifacts and make them
>>> > >>> > > responsibility of somebody else. A typical example of somebody
>>> > >>> > > else would be a Linux Distribution company.
>>> > >>> > >
>>> > >>> > > Or it can even be yourself with your individual's hat on -- it
>>> just
>>> > >>> can
>>> > >>> > NOT
>>> > >>> > > be ASF unless we can do the same due diligence we do for #1.
>>> > >>> > >
>>> > >>> > > Thanks,
>>> > >>> > > Roman.
>>> > >>> > >
>>> > >>> >
>>> > >>>
>>> > >>
>>> >
>>>
>>

Reply via email to