On 01/31/2012 11:10 PM, Franklin, Matthew B. wrote:
-----Original Message-----
From: Ate Douma [mailto:[email protected]]
Sent: Tuesday, January 31, 2012 3:02 PM
To: [email protected]
Subject: Re: [DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE
requirements
On 01/31/2012 06:49 PM, Franklin, Matthew B. wrote:
<snip>
I think I've just finished with the NOTICE (and some LICENSE)
modifications
needed for rave-shindig.
Quite some changes which I tried to do as much as atomic as possible so
everybody can review why I did many removals and additions/changes.
@Matt: I don't expect to have much or even any time tomorrow to
continue
with
the same work needed for rave-portal, but Wednesday I probably can
help
or dive
into it myself.
I am working on it now and hope to have everything in rave-portal
wrapped
up by tomorrow evening
</snip>
After reading through the legal discuss JIRA tickets and some of the
background info on this issue, it is clear that we only need to include
attributions in the NOTICE file that are required by the license, which is
something we have discussed before.
However, there is no definitive guide as to which licenses require
attribution in the NOTICE files and which do not. Some, are very self-
explanatory, but others are not. One specifically is the ASL 2.0, which states
If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
This indicates, to me at least, that any NOTICES contained in any
dependency we package need to be concatenated to our NOTICE file;
Yes, that is, for as much as it pertains your (our) distribution.
None relevant parts should not be copied/appended verbatim.
And really, this requirement from our AL 2.0 is the main reason why there was
quite some discussion recently concerning what should go into the NOTICE
and
what not. And for that reason the NOTICE file should contain only what is
really
required and nothing more.
IMO these have been answered pretty well through the following LEGAL jira
issues
and thereafter reflected in updated clarifications on the policy pages
concerning these:
https://issues.apache.org/jira/browse/LEGAL-62
https://issues.apache.org/jira/browse/LEGAL-118
https://issues.apache.org/jira/browse/LEGAL-119
which will result in more attributions, not less based on what I have found.
Actually, as you can review from my changes for rave-shindig NOTICE file it can
easily end up becoming less (which more or less is the intend).
What is important to note here is that, although our AL 2.0 license requires us
to include pertaining NOTICES from 3rd parties, many do not have any... For
instance almost all 3rd party dependencies we include from google code for
rave-shindig don't. And most of those are AL 2.0 licensed as well, meaning
there
really isn't any need for any other attribution than providing the ASL 2.0
license which we already do.
In these cases, I completely agree.
I don't know if EPL or CDDL have similar provisions, but I will need to read to
get a better idea.
No, they don't. And neither do MIT or new BSD.
But the devil can be in the details, and be project specific.
I noticed attributions for EPL licensed jars that you kept in rave-shindig.
Were these required by the project?
Not by the project but by the ASF itself.
EPL/CDDL/MPL/etc are all so called "Weak Copyleft" license, or in ASF
'terminology' licensed from category B, see:
http://apache.org/legal/resolved.html#category-b
Those licenses need special handling (and only allow for binary inclusion). The
above link says that these licensed may only be used "[...] if the inclusion is
appropriate labeled[...]".
And this is exactly where NOTICE files are meant for, thus if you include
software based on a category-b license, we (the ASF) require you to provide such
a notice, regardless of any possible additional notice requirements the 3rd
party might add to that.
Note: I've used the same 'policy' for usages of software licensed to the public
domain. That might be debatable and I've seen different opinions about it.
Public domain licensed software isn't without its problems in general so should
not be automatically regarded as 'easy' to include. See also:
http://apache.org/legal/resolved.html#can_works_placed_in_the_public_domain_be_included_in_apache_products
So just checking the license by itself is not enough, you really need to check
if the *project* requires possible (additional) notices, but only for that
specific artifact your including. And I discovered many/most of the 3rd party
artifacts (jars) themselves are not sufficient to rely on possible contained
LICENSE/NOTICE files either. Take for example shindig-server: it became clear
last week they currently don't provide correct NOTICE/LICENSE files. However
that doesn't mean we thus don't need to care either. On the contrary: we
(PMC)
ultimately are responsible for ensuring the appropriate and required
attributions are provided, because it concerns *our* (re)distribution.
And another opposite example would be an earlier release of ourselves,
where we
(as we now understand) simply provided too much attributions in our NOTICE
file,
thereby making life more difficult for our own downstream users (and
possibly
further re-distributors).
My strategy now is to gather and concatenate any NOTICE files in our
dependencies and simply add them to our own. A rough cut from a script I
wrote is attached to this e-mail.
In theory that might be helpful. However, as I expected and saw in effect
reviewing those concatenated files (link from your follow up email), I don't
think they really are that helpful
a) you can't rely on the content to be valid/complete/too much
b) some don't come with any, but for instance their website, or their *source*
distribution will need to be reviewed and then clear up sometimes
(additional)
attribution is need
I agree that we should be (I have been) checking the website for additional
attribution, especially when nothing is included in the distribution.
c) the output typically is very much polluted, like with all the unneeded ASF
project attributions and license inclusions which are not required anyway
d) some may provide (required) attribution requirements in files not named
'NOTICE' which naming really is just an ASF requirement (example:
spring-aop-3.1.0.RELEASE.jar/META-INF/license.txt).
I think in these cases, we should be moving the attributions that are relevant
from such licenses to the NOTICE, right?
If the attributions are valid/needed then yes. In the example above, for
apache-shindig the 3rd party notice embedded within the spring-aop jar concerns
possible usage/inclusion of the asm-2.2.3.jar. Which in the apache-shindig case
doesn't apply as we don't use/bundle, so I didn't move (copy) that specific
notice to our NOTICE file.
Bottom line, I think this task really isn't fit for automation. It really needs
your (and all our) best personal effort and judgment. Your script might be
helpful for a first cut, but only for a first one. Once a complete and validated
NOTICE and LICENSE file has been established, the responsibility won't be
over:
I definitely am not suggesting completely automating it. For each of the
concatenated NOTICE files, I was planning on reviewing the specific
attributions and adding the ones that are required. I just wanted something to
base it on. I am going to continue working on this and follow the same commit
per dependency model you were using.
Cool.
My point was nobody (besides you) should get the impression this could maybe
easily or even partly be automated, which it cannot. As long as that is clear to
everyone, I'm fine :)
Good luck with the task!
Ate
every future dependency change/upgrade might require a renewed
validation, and
nasty side-effects of transitive dependencies causing an avalanche of updates
to
be taken into account.
Does everyone agree this is the correct approach or should I take this back
to legal?
I hope I've given enough feedback for now to further chew on.
But I'm sure there are more questions to raise thereafter :)
Ate
