Hi - (1) It is the Apache License v2. The abbreviation is ALv2 and not ASLv2.
(2) Fill out the copyright date in the license boilerplate. (3) Stanford CoreNLP is GPL3 and must not be included in the binary. It can be optional as long as the feature is noncritical and the user can easily control its inclusion. See http://www.apache.org/legal/resolved.html#category-x Helpful information is also here: http://www.apache.org/legal/src-headers.html#3party And here: http://www.apache.org/legal/src-headers.html#notice Regards, Dave > On Apr 8, 2020, at 8: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. >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >>
