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-documentation
[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
