shindig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <>
Subject NOTICE and LICENSE files
Date Thu, 26 Jan 2012 03:04:50 GMT
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):

and in addition the following LEGAL JIRA tickets for additional background:

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 
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:
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:

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 

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
- 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:
- slf4j-api-1.5.11.jar & slf4j-jdk14-1.5.11.jar: requires MIT license, see:
- xmlpull- public domain, see: , this requires 
attribution in the NOTICE file, see:
- xpp3_min-1.1.4c.jar: requires Indiana University Extreme! Lab Software License 
1.1, find it in source distribution at

- xstream-1.4.2.jar: requires a BSD license, see:


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

View raw message