Many thanks for all these details. Two things jump out at me: 1. "those NOTICE and LICENSE files *only* refer and apply to what has been checked into the (that!) git/subversion source tree, *nothing else*. So no references to 3rd party dependencies which are pulled in at build time!"
That's very interesting and it means that the NOTICE and LICENSE will be very short and sweet -- i.e., the only license will be Apache, since all the source files will be relicensed to Apache. Everything else has been removed prior to the donation, i.e., everything that did not belong to Oracle, anything that has been licensed to anyone other than Oracle, has been removed prior to the donation. Yes, we need to prove that within the incubator and document how we prove that. However, I believe based on having gone through the donation process from the Oracle side, that the only license of the source tree is Apache. What does this mean for dependencies pulled in at build time? I.e., can they then be licensed in any way at all -- i.e., where are the rules/guidelines for dependencies pulled in at build time? 2. "NOTICE and LICENSE files *must* be provided in the root of *each* package or distribution, or a practical/common equivalent thereof (e.g. in a jar-file these should go under META-INF/)" I had assumed there is one NOTICE and one LICENSE file, in the root of the repo. From the above, there could be hundreds, i.e., for each package, it would seem. Can you point to somewhere as a reference point for that, e.g., a project where this is done? It sounds to me like we're going to have hundreds of NOTICE and LICENSE files in Apache NetBeans? Thanks, Geertjan On Tue, Sep 19, 2017 at 12:17 AM, Ate Douma <a...@douma.nu> wrote: > On 2017-09-16 08:28, Geertjan Wielenga wrote: > >> Hi all, >> >> Created https://issues.apache.org/jira/browse/NETBEANS-57. >> >> Trying to find an Apache project to use as reference point, looked around >> a >> bit, and Apache Spark seems to be complex enough in terms of its >> dependencies to follow: >> >> https://github.com/apache/spark >> >> I.e., there's a folder in the above named "licenses": >> >> https://github.com/apache/spark/tree/master/licenses >> >> Should such a folder be created in >> https://github.com/apache/incubator-netbeans? >> >> And then, reference those licenses in the LICENSE file: >> >> https://github.com/apache/spark/blob/master/LICENSE >> >> And also a NOTICE file should be created, like this one: >> >> https://github.com/apache/spark/blob/master/NOTICE >> >> Is that the correct approach and should anything else be considered? >> > > Warning TL;DR; ahead, but please hang on anyway... > > I'll offer *my* preferences, and a bit of opinion, but do note that there > is no > single 'best' or 'perfect' solution, fit for all projects. > > The ground rules are spelled out and documented at [1] and [2], and IMO > should be regarded as the *legal* requirements every solution needs to > comply > to. > > [1] http://www.apache.org/legal/release-policy.html#licensing-do > cumentation > [2] http://apache.org/legal/src-headers.html#notice > > However, how these ground rules or legal requirements are interpreted and > applied differs on detail level for just about every ASF project I've been > directly involved with ... > Also the common understanding and current expected way how this should or > must > be done has changed (or progressed if you will) over the years as well. > > Bottom line is: the IPMC (Incubator PMC) will have to validate and agree > with > the chosen solution to accept a release candidate, or not. Or may give some > initial lenience for acceptable first-time mistakes, to be fixed in future > releases. > Again: there is no one-fits-all solution, when in doubt do ask on > gene...@incubator.apache.org. > And preferably *before* starting a vote for a release candidate to reduce > the > number of times a release candidate is voted down (which AFAICR almost > *always* > happens the first one or few time...). > > Furthermore, please accept my personal disclaimer that in most cases I also > tend to overlook or miss a few bits and bytes the first few times a new > project > needs to get its LICENSE and NOTICE file(s) in order. > > It can and typically will be a tiresome exercise in the beginning, nobody > should > take this lightly. But once the basic process has been fleshed out and a > first > complete and verified release has gone through successfully, things will > get > easier, promise :-) > > Now concerning the 'correct approach'. > I'd like to provide some guidelines or rules of the thumb of my own, as > I've > been using and advocating over the years, and which worked, and still > work, for > several ASF projects. > But feel free to discuss/question these 'rules', to get a better > understanding > or possibly (hopefully) improve/fix/refine them as needed. > In the end, its the Netbeans PPMC, and during incubation ultimately the > IPMC, > which needs to decide and accept the approach taken. > > > a) NOTICE and LICENSE files *only* apply to what is contained within a > 'package' > or distribution. They do NOT and should NOT refer to or address anything > NOT > within that package or distribution. > > b) NOTICE and LICENSE files *must* be provided in the root of *each* > package or > distribution, or a practical/common equivalent thereof (e.g. in a jar-file > these > should go under META-INF/) > > c) The ASF git (or likewise subversion) repository should also be regarded > as a > 'distribution' of its own. It therefore also requires a NOTICE and LICENSE > file > checked in the root folder of the git tree. > Per rule a) those NOTICE and LICENSE files *only* refer and apply to what > has > been checked into the (that!) git/subversion source tree, *nothing else*. > So no references to 3rd party dependencies which are pulled in at build > time! > > d) A *source* release typically includes everything from the (that) git > source > tree, in which case the git tree root NOTICE and LICENSE files are 'good > to go'. > But it also may (also) combine multiple git repositories, or split them up. > For example a common approach is to also provide (distribute) one or more > 'convenient' <module>-sources.jar files. In which case possibly only a > subset of > the 'root' NOTICE and LICENSE file is needed/should be bundled. > > e) A binary 'convenience' distribution (which is NOT the release, and only > may > be distributed *together* with the corresponding source release), typically > also bundles 3rd party dependencies. The NOTICE and LICENSE file packaged > with > such binary distribution then also MUST cover those 3rd party > dependencies, see > also a) above. Which means *different* (extended) NOTICE and LICENSE files > will > be needed, compared to the source release. > For Netbeans I think this may apply to nbm files if I'm correct. And each > nbm > file may even require a different/dedicated NOTICE and LICENSE file, > depending > on its content. > Also notable is how to handle ASF, or for that matter, any 3rd party AL 2.0 > based dependencies: while their LICENSE is the same (AL 2.0), if these > 3rd party dependencies carry a NOTICE file (which every ASF project is > required > to do), any *applicable* content from those NOTICE files needs to carried > (merged) into your own NOTICE file as well (AL 2.0, 4.4d). > This also explains why NOTICE files should *only* contain notices which are > (legally) required, nothing more. > Do NOT put nice or friendly attributions ('thank you' or whatnot) in a > NOTICE > file, unless required. Friendly attributions may/should go in a non-legal > README > or something similar instead! > > f) All NOTICE attributes can/must only go into the one NOTICE file. > 3rd party LICENSEs may be appended to the main LICENSE file, or > referred/linked > to, as long as they are bundled within the distribution. Providing only > remote linking (e.g. using an url) is not allowed. > > g) Finally (and in practice this is often a nasty/tricky one): don't > blindly > trust or rely on 3rd party dependencies bundling (or not) 'a' LICENSE > (and/or NOTICE) file. While at the ASF we take these things very seriously > (and still > often make mistakes...) its not uncommon (or rather common in my > experience) > that other projects don't. > Either there is no LICENSE/NOTICE bundled, or it is clearly wrong, > outdated, incomplete or contains 'everything from the kitchen sink'. > We (the PMC, ultimately responsible for voting and accepting a release) > need to > do the proper thing and verify or hunt down the actual/current LICENSE > and/or > NOTICEs applicable to 3rd party dependencies. For as much > reasonable/feasible. > But often we can reuse verification/validation already done by other ASF > projects, so for common dependencies it usually isn't that bad. > > That's it :-) > > Note therefore that the above example NOTICE and LICENSE files from Apache > Spark > 'violate' the above guidelines on a) and c). > Which isn't legally incorrect, but unnecessary and unwanted. It is making > it > more difficult for downstream consumers to figure out which licenses > 'really' > apply, or even downright annoying as per AL 2.0 section 4.4d) the whole of > the > NOTICE file content *must* be copied by downstream re-distributers... > > HTH, > Ate > > > >> The SGA received from Oracle provides a starting point, i.e., a list of >> 3rd >> party references, which I propose taking as the first step, i.e., for the >> initial draft of the LICENSE and NOTICE, after which we will document the >> process by which we make sure that these are accurate. >> >> Thanks, >> >> Gj >> >> >
