Regards,
RYAN J. BAXTER
From: Ate Douma<a...@douma.nu>
To: dev@shindig.apache.org,
Date: 01/27/2012 09:54 AM
Subject: Re: NOTICE and LICENSE files
On 01/27/2012 01:57 PM, Ciancetta, Jesse E. wrote:
I've been working with Ate on the Rave project since its inception and
personally have 100% trust in his opinions and recommendations on these
types of matters (and many other matters as well). Ate has been helping
Rave work though these same type of issues from the start and he's been
active on the general@ list in many discussions regarding NOTICE and
LICENSE files with other ASF'ers as well.
And aside from my interactions with Ate on the Rave project I also know
that he's been involved with the ASF for quite a long time (he's an ASF
member, commiter on multiple projects, Incubator PMC member, mentor to
multiple projects, ...) so he's definitely drawing from a good wealth of
experience here.
So my vote would be to take Ate's recommendations and go ahead and
implement them. And if he's willing to submit patches for the changes
then all the better.
I think one JIRA issue would be sufficient -- if no one objects I can go
ahead and create a ticket for it later today.
Cool Jesse, and thanks for the flattery ;)
But please don't assume I'm all knowing in these matters, just trying to
be
concise here.
So don't just take my suggestions or comments for granted: in the end it
is the
Shindig PMC who is responsible to make the proper assessment on all this.
If you create a JIRA ticket for it, I can and will try to create patches
for the
most important of the issues.
But I can't do that (yet) for all, at least not until some of the
questions are
answered.
In particular the following need feedback and conclusion from the Shindig
PMC
itself:
- 1.c
- 1.f
- 2.a
Furthermore, those conclusions, especially like for 1.f, can have quite an
impact on which changes need to be done and where.
So, before I start creating patches (which may take a few days), I'd
prefer
having some feedback from the PMC specifically on the above 3 listed
issues.
Note: if 1.f is to be done, it'll need a Google representative to do the
actual
execution (commit)!
Thanks, Ate
-----Original Message-----
From: Ryan J Baxter [mailto:rjbax...@us.ibm.com]
Sent: Thursday, January 26, 2012 8:56 PM
To: dev@shindig.apache.org
Subject: Re: NOTICE and LICENSE files
Ate, these seem like valid concerns, but I am not a lawyer so not sure
I
understand all the implications :) What does the rest of the community
think? What is the best way to address these? I assume we want to
start
by creating JIRAs....
-Ryan
From: Ate Douma<a...@douma.nu>
To: dev@shindig.apache.org,
Date: 01/25/2012 10:05 PM
Subject: NOTICE and LICENSE files
Hi Shindig team,
Since some time the ASF rules and requirements for what should go into
NOTICE
and LICENSE have been further discussed, clarified and made more
explicit.
This for a large part happened within the Apache Incubator, but have
resulted in
updates to the online instructions and clarifications which applies to
whole of
the ASF.
For Apache Rave I'm currently reviewing our own compliance with these
rules, and
in particular with respect to the NOTICE files as those especially have
some
downstream consequences making it important to minimize the 'burden'
for
downstream users, and the guidelines for these have very recently been
updated.
As Apache Rave makes use of and extends and redistributes Apache
Shindig,
I've
been reviewing the NOTICE and LICENSE files provided (packaged) by
Shindig
to
make sure we're honoring the appropriate notices and license usages of
Shindig.
Note: I've only looked at Shindig Java, we're not using the PHP
implementation
and I'm definitely not qualified to properly review that side.
After this review though I've several questions as well as some
suggestions for
the NOTICE and LICENSE files, and some IMO concern omissions which are
required
to be fixed from a legal POV.
I apologize upfront for the lengthly email, unexpected by myself, this
ended up.
But I tried to be as clear and concise as possible. I hope some of you
can
endure reading through this and follow up on it, because some if the
issues
below are serious enough to potentially be blockers for a next release.
As reference, I'm trying to follow these rules and guidelines (some of
which
were recently updated or better clarified):
http://www.apache.org/legal/**src-headers.html<http://www.apache.org/legal/src-headers.html>
http://apache.org/legal/**resolved.html<http://apache.org/legal/resolved.html>
http://apache.org/legal/**resolved.html#required-third-**
party-notices<http://apache.org/legal/resolved.html#required-third-party-notices>
and in addition the following LEGAL JIRA tickets for additional
background:
https://issues.apache.org/**jira/browse/LEGAL-26<https://issues.apache.org/jira/browse/LEGAL-26>
https://issues.apache.org/**jira/browse/LEGAL-62<https://issues.apache.org/jira/browse/LEGAL-62>
https://issues.apache.org/**jira/browse/LEGAL-118<https://issues.apache.org/jira/browse/LEGAL-118>
https://issues.apache.org/**jira/browse/LEGAL-119<https://issues.apache.org/jira/browse/LEGAL-119>
An important note upfront: below I'm suggesting several *removals* of
attributions from NOTICE files. The reason for this is that *only*
required
attributions should be provided in the NOTICE file, and often even that
isn't
needed if the 3rd party license already provides the required
attribution
itself!
And the reason why only the minimal required attributions should be
provided in
the NOTICE file is because the Apache 2.0 license *requires* us to
retain
all
upstream (e.g. Apache Shindig) NOTICE attributions, if applicable to
the
redistribution.
But of course there should not be too little attribution because that
might make
the release and even further downstream (re)distributions illegal!
Here are my questions, suggestions and/or issues encountered:
1) file /NOTICE
===============
a. Suggestion: "Copyright 2010" should be updated to "Copyright 2012"
b. Notice for "This software includes software developed at the
ASF[...]"
occurs
twice. Suggestion to remove the duplicate.
c. Question: there is a notice that the product includes software
developed by
the OpenSocial Foundation, with a reference to [...]/spec/0.8.
Is that still valid? NB: the current/latest spec doesn't provide any
'software'
at all anymore. Is Shindig still embedding these 0.8 spec code?
d. There is a notice for both swfobject and OAuth code usage with a
reference to
their (both) MIT based license. However that license itself isn't
included
in
the (root) LICENSE file, while that is the *only* requirement of that
specific
license. What not is required by that license though is providing an
additional
attribution for it in the NOTICE file. Suggestion: append the MIT
license
to the
/LICENSE file (marked being used by both swfobject and OAuth) and
remove
both
notices from the NOTICE file.
NB: for swfobject its LICENSE *is* included in the /features/LICENSE
file,
however the root /LICENSE file should at least have it too (or only,
see
5)
further below) for the full source release distribution (as well in the
project
[tag] svn root folder itself as that is to be considered also a
'distribution').
e. There is a notice for including OpenAjax provided software. However,
the
OpenAjax software nor its foundation (website) doesn't require to
provide
a
notice. Their license is Apache 2.0 based, which does require
attributing
a
notice, *if* there is notice. But as there isn't any (not in the code
nor
anywhere specified on their website), Shindig doesn't need to attribute
them
either. Suggestion: remove the notice for OpenAjax.
NB: IMO the /extras/NOTICE file therefore isn't needed either.
f. The extras/src/main/javascript/**features-extras/wave/*.js files all
still have
a "Copyright 2010 Google Inc." header. It seems to me for these files
the
following rule is applicable:
http://www.apache.org/legal/**src-headers.html#header-**
existingcopyright<http://www.apache.org/legal/src-headers.html#header-existingcopyright>
Suggestion: A Google employee like Paul should do this and then move
the
copyright statement to the NOTICE file.
g. The /features/NOTICE file contains an additional attribution for
"sha 1
JS
impl" developed by Google Inc. This attribution however is missing from
the root
/NOTICE file. See also 5) further below.
2) file /LICENSE
================
a. See also 1.c) above. There is a license appended for the OpenSocial
Javascript API. Question: is that still valid/needed/applicable?
b. See also 1.d) above. the swfobject and OAuth MIT used license is
missing.
c. The /content/editor/CodeMirror-0.**8/LICENSE file should be appended
here.
3) file /extras/NOTICE
======================
See also 1.e) above. IMO this file can be removed. And it isn't used
anyway,
e.g. not embedded in a build artifact either.
4) module extras build artifacts
==============================**==
See also 1.f) above. If/when the "Copyright 2010 Google Inc." copyright
headers
are moved from the wave/*.js files to a NOTICE file, *then* that
attribution
will also be required to be packaged in the build artifacts for the
extras
module.
Suggestion (if/when applicable in this case): make use of
appended-resources
which will be automatically processed by the
maven-remote-resources-plugin
to
*append* additional NOTICE (and/or LICENSE) fragments to the
automatically
injected NOTICE/LICENSE files. This mechanism is common practice by
many
maven
based projects and probably the easiest to maintain extra notices and
licenses
needed for build artifacts.
For an example of how to use this, see:
https://svn.apache.org/repos/**asf/incubator/rave/trunk/rave-<https://svn.apache.org/repos/asf/incubator/rave/trunk/rave->
shindig/src/main/appended-**resources
Note: the META-INF/NOTICE fragment under the above location itself is
*not*
(yet) a proper example. I'm in the process of cleaning that one up
(probably
removing many/most of those attributions), similar to and even related
to
this
email itself ;)
5) module features
==================
a. See also 1.d) and 1.g) above: the /features/LICENSE and
/features/NOTICE
files contain fragments which should be moved to the root /LICENSE and
/NOTICE
files.
b. In addition, these files probably better be removed and be replaced
by
using
LICENSE and NOTICE fragment files under appended-resources, see 4)
above.
This
will reduce the maintenance (NOTICE copyright statement will
automatically
be
adjusted for the proper year(s) by maven-remote-resources-plugin for
instance).
When doing this, the current maven build resources configuration which
*only*
adds the /features/NOTICE file to the build artifacts can/should be
removed.
c. Doing 5.b) above then also will fix adding missing 3rd party
LICENSEs
(like
for MIT) in the build artifacts. As it is right now, the features
artifacts are
not ASF release compliant because of this...
d. Finally see also other remarks under 1) above for several of the
NOTICE
attributes which might not be needed or are duplicated (ASF
attribution).
6) module java
==============
a. See comments above for 1) and 5).
AFAIK the /java/LICENSE and /java/NOTICE files are only used (included)
by
the
assembly to produce the shindig-java package. They are not used
(included)
by
any of java sub modules, although that might have been the intention?
Suggestion: fix and then move these LICENSE and NOTICE files to the
assembly
module itself, whereas these then should contain the aggregated
LICENSEs
and
NOTICEs as relevant for the shindig-java package contents, e.g.
covering
(only)
for the -common, -features, -gadgets, -social-api and -extras modules.
b. As mention above, none of the java sub modules use the java LICENSE
or
NOTICE
files, and in fact none of the build artifacts have anything else than
the
base
ASF NOTICE and LICENSE file embedded... That clearly is not properly
covering
the ASF release requirements, which in particular is not valid for
shindig-server, which incorporates many 3rd party dependencies with
additional
NOTICE and LICENSE requirements.
c. module java/uber
As this module repackages and bundles several other shindig-*
artifacts,
it
should also bundle an aggregated NOTICE and LICENSE file based on those
merged
artifacts. Suggestion is to use a separate appended-resources
configuration like
described at 4) again. Regrettably this will mean some redundancy work
as
the
maven-remote-resources-plugin or the maven-shade-plugin cannot
auto-magically do
this themselves.
d. module java/server
This war module bundles practically all other shindig (java related)
modules,
except sample, so should at least also have an aggregated LICENSE and
NOTICE
file covering those other shindig modules. In addition, many 3rd party
dependencies are bundled which some also require additional notice and
licenses
to be covered.
As far as I have been able to determine this includes at least:
- joda-time-2.0.jar: requires a notice attribution (see embedded NOTICE
file)
- json-20070829.jar: requires
http://www.json.org/license.**html<http://www.json.org/license.html>
- jstl-1.2.jar: requires CDDL 1.0 license (see embedded LICENSE.txt)
- modules-0.3.2.jar: dual licensed under either LGPL or AS 2.0.
Therefore
this
dependency requires a notice saying under which license (AS 2.0 it is
used) it
is used.
- protobuf-java-2.4.1.jar: requires new BSD license, see:
http://code.google.com/p/**protobuf/<http://code.google.com/p/protobuf/>
- slf4j-api-1.5.11.jar& slf4j-jdk14-1.5.11.jar: requires MIT license,
see:
http://www.slf4j.org/license.**html<http://www.slf4j.org/license.html>
- xmlpull-1.1.3.1.jar: public domain, see:
http://www.xmlpull.org/v1/**download/unpacked/LICENSE.txt<http://www.xmlpull.org/v1/download/unpacked/LICENSE.txt>,
this requires
attribution in the NOTICE file, see:
http://apache.org/legal/**resolved.html<http://apache.org/legal/resolved.html>
- xpp3_min-1.1.4c.jar: requires Indiana University Extreme! Lab
Software
License
1.1, find it in source distribution at
http://www.extreme.indiana.**edu/dist/java-<http://www.extreme.indiana.edu/dist/java->
repository/xpp3/distributions/**xpp3-1.1.4c_src.tgz
- xstream-1.4.2.jar: requires a BSD license, see:
http://xstream.codehaus.org/**license.html<http://xstream.codehaus.org/license.html>
==========
The above list is quite extensive and if all valid and/or of concern,
will
take
some effort to resolve. If so desired, I'm willing to help out and
produce
patches, but it'll depend on which of the above issues do need
resolving
and
than in some cased a choice how exactly.
FWIW, for Apache Rave's dependency on shindig-server, we can now
already
start
fixing our own needed NOTICE and LICENSE files according the above
findings, but
of course it would be very helpful if/when we can rely on fixed LICENSE
and
NOTICE files produced by Shindig itself in the future to merge.
Many thanks for the attention already if you made it this far just
reading!
Thanks, Ate
Apache Rave
