You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@shindig.apache.org by Ate Douma <at...@douma.nu> on 2012/01/26 04:04:50 UTC

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://apache.org/legal/resolved.html
   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-62
   https://issues.apache.org/jira/browse/LEGAL-118
   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
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-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
- 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/
- slf4j-api-1.5.11.jar & slf4j-jdk14-1.5.11.jar: requires MIT license, see: 
http://www.slf4j.org/license.html
- xmlpull-1.1.3.1.jar: public domain, see: 
http://www.xmlpull.org/v1/download/unpacked/LICENSE.txt , this requires 
attribution in the NOTICE file, see: 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-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

==========

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

RE: NOTICE and LICENSE files

Posted by Stanton Sievers <ss...@us.ibm.com>.

If you could write up the JIRA, that would be great Jesse.  This is 
something we need to fix before we declare 3.0.0.....or is it 2.5.0 now 
:).

Thanks,
-Stanton



From:   "Ciancetta, Jesse E." <jc...@mitre.org>
To:     "dev@shindig.apache.org" <de...@shindig.apache.org>, 
Date:   01/27/2012 07:57
Subject:        RE: NOTICE and LICENSE files



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.

>-----Original Message-----
>From: Ryan J Baxter [mailto:rjbaxter@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 <at...@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://apache.org/legal/resolved.html
>   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-62
>   https://issues.apache.org/jira/browse/LEGAL-118
>   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
>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-
>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
>- 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/
>- slf4j-api-1.5.11.jar & slf4j-jdk14-1.5.11.jar: requires MIT license,
>see:
>http://www.slf4j.org/license.html
>- xmlpull-1.1.3.1.jar: public domain, see:
>http://www.xmlpull.org/v1/download/unpacked/LICENSE.txt , this requires
>attribution in the NOTICE file, see: 
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-
>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
>
>==========
>
>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
>

Re: NOTICE and LICENSE files

Posted by Ate Douma <at...@douma.nu>.

On 02/01/2012 10:30 PM, Ate Douma wrote:
> On 02/01/2012 04:59 PM, Ate Douma wrote:
>> On 02/01/2012 12:39 PM, Paul Lindner wrote:
>>> wave copyright issues committed in r1239088
>>
>> Great!
>>
>> Thanks Paul, that clears 1.f
>> I'll adjust our NOTICE for rave-shindig accordingly.
>
> BTW: this commit does move the copyright statement to *a* NOTICE
> (/extra/NOTICE), but it still won't end up in the shindig-extra jar, nor in any
> other release artifact (e.g. shindig-server), nor in the root NOTICE file of the
> source distributions.
>
> Then again, if the other suggestions I've made earlier are applied as well this
> should get resolved then 'automatically' :)

I've upload a patch to reviewboard to resolve the remaining NOTICE and LICENSE 
issues as reported earlier. Which includes 'fixing' the above and fixes for 
Shindig PHP as well.

AFAIK if these changes are applied Shindig should be conforming the ASF N&L 
requirements. But of course IANAL, so please make your own judgment!

Regards, Ate

>
> Ate
>
>>
>> Regards, Ate
>>
>>>
>>>
>>> On Wed, Feb 1, 2012 at 12:49 AM, Ate Douma<at...@douma.nu> wrote:
>>>
>>>> Thanks Ryan,
>>>>
>>>>
>>>> On 02/01/2012 03:34 AM, Ryan J Baxter wrote:
>>>>
>>>>> Here are my 2 cents...
>>>>>
>>>>> For 1.c and 2.a I am not sure how true that is anymore...while some of
>>>>> those files still exist in Shindig, I am willing to guess that have been
>>>>> modified and are no longer the same as what is in
>>>>> http://opensocial-resources.**googlecode.com/svn/spec/0.8/<http://opensocial-resources.googlecode.com/svn/spec/0.8/>.
>>>>>
>>>>>
>>>>> Would we have
>>>>> to go through and check to make sure whether each file has changed?
>>>>>
>>>>
>>>> I've just looked into it a bit further, and I think 1.c no longer is an
>>>> issue.
>>>> IMO that notice for the 0.8 spec no longer (and never was) needed.
>>>> I checked every file of that spec and the only thing I found were Apache 2
>>>> License headers and no further NOTICE claims. Which means that, by the
>>>> Apache 2 License, we're not required to carry any further either. If these
>>>> files are still used or not (and they are) thus isn't an issue.
>>>>
>>>> Concerning 2.a, about the separate (Apache 2.0 License based) "Copyright
>>>> (c) 2009 The OpenSocial Foundation" claim as appended to the /LICENSE file,
>>>> this isn't 100% clear to me yet.
>>>> The problem is: it claims (and probably rightfully so) copyright for the
>>>> OpenSocial Foundation, but *nowhere* in the specification, the website (
>>>> docs.opensocial.org), or the opensources-resources project on
>>>> code.google.com can I find *any* copyright claim at all...
>>>>
>>>> Now, I assume the OpenSocial Foundation does have (and then should claim)
>>>> copyright on the specifications, but then they should make that clear and
>>>> explicit somewhere.
>>>>
>>>> Backtracking through svn history, I discovered that this particular
>>>> license inclusion was added *because* of 1.c in the NOTICE file, as
>>>> feedback on general@incubator of the Shindig 1.0 (Incubator) release
>>>> vote, see:
>>>>
>>>> http://s.apache.org/xD9
>>>>
>>>> Relevant section (quote from sebb's email):
>>>>
>>>> "NOTICE mentions opensocial-resources, PHPUnit and Zend, but
>>>> LICENSE mentions PHPUnit, Zend and jsmin.php.
>>>>
>>>> I would expect LICENSE to include a mention of opensocial-resources
>>>> NOTICE should probably have a mention of jsmin.php"
>>>>
>>>>
>>>> But I cannot check if the added license was actually provided by the
>>>> OpenSocial Foundation itself, or just added for the purpose.
>>>>
>>>> Because of the above, I'm going to send a request to
>>>> opensocial-and-gadgets-spec@**googlegroups.com<op...@googlegroups.com>to
>>>>
>>>> ask if and how we should attribute usage of the spec.
>>>>
>>>> For the record: the above feedback from general@incubator does mention
>>>> several of the same issues I've raised here...
>>>>
>>>>
>>>>
>>>>> Seems like 1.f is reasonable.
>>>>>
>>>> I think so too. I can (will) create a patch specifically for that one, but
>>>> as said before that one should only be committed by a Google
>>>> representative, e.g. like Paul!
>>>>
>>>> Regards,
>>>>
>>>> Ate
>>>>
>>>>
>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> RYAN J. BAXTER
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> From: Ate Douma<at...@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:rjbaxter@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<at...@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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>

Re: NOTICE and LICENSE files

Posted by Ate Douma <at...@douma.nu>.

On 02/01/2012 04:59 PM, Ate Douma wrote:
> On 02/01/2012 12:39 PM, Paul Lindner wrote:
>> wave copyright issues committed in r1239088
>
> Great!
>
> Thanks Paul, that clears 1.f
> I'll adjust our NOTICE for rave-shindig accordingly.

BTW: this commit does move the copyright statement to *a* NOTICE 
(/extra/NOTICE), but it still won't end up in the shindig-extra jar, nor in any 
other release artifact (e.g. shindig-server), nor in the root NOTICE file of the 
source distributions.

Then again, if the other suggestions I've made earlier are applied as well this 
should get resolved then 'automatically' :)

Ate

>
> Regards, Ate
>
>>
>>
>> On Wed, Feb 1, 2012 at 12:49 AM, Ate Douma<at...@douma.nu> wrote:
>>
>>> Thanks Ryan,
>>>
>>>
>>> On 02/01/2012 03:34 AM, Ryan J Baxter wrote:
>>>
>>>> Here are my 2 cents...
>>>>
>>>> For 1.c and 2.a I am not sure how true that is anymore...while some of
>>>> those files still exist in Shindig, I am willing to guess that have been
>>>> modified and are no longer the same as what is in
>>>> http://opensocial-resources.**googlecode.com/svn/spec/0.8/<http://opensocial-resources.googlecode.com/svn/spec/0.8/>.
>>>>
>>>> Would we have
>>>> to go through and check to make sure whether each file has changed?
>>>>
>>>
>>> I've just looked into it a bit further, and I think 1.c no longer is an
>>> issue.
>>> IMO that notice for the 0.8 spec no longer (and never was) needed.
>>> I checked every file of that spec and the only thing I found were Apache 2
>>> License headers and no further NOTICE claims. Which means that, by the
>>> Apache 2 License, we're not required to carry any further either. If these
>>> files are still used or not (and they are) thus isn't an issue.
>>>
>>> Concerning 2.a, about the separate (Apache 2.0 License based) "Copyright
>>> (c) 2009 The OpenSocial Foundation" claim as appended to the /LICENSE file,
>>> this isn't 100% clear to me yet.
>>> The problem is: it claims (and probably rightfully so) copyright for the
>>> OpenSocial Foundation, but *nowhere* in the specification, the website (
>>> docs.opensocial.org), or the opensources-resources project on
>>> code.google.com can I find *any* copyright claim at all...
>>>
>>> Now, I assume the OpenSocial Foundation does have (and then should claim)
>>> copyright on the specifications, but then they should make that clear and
>>> explicit somewhere.
>>>
>>> Backtracking through svn history, I discovered that this particular
>>> license inclusion was added *because* of 1.c in the NOTICE file, as
>>> feedback on general@incubator of the Shindig 1.0 (Incubator) release
>>> vote, see:
>>>
>>> http://s.apache.org/xD9
>>>
>>> Relevant section (quote from sebb's email):
>>>
>>> "NOTICE mentions opensocial-resources, PHPUnit and Zend, but
>>> LICENSE mentions PHPUnit, Zend and jsmin.php.
>>>
>>> I would expect LICENSE to include a mention of opensocial-resources
>>> NOTICE should probably have a mention of jsmin.php"
>>>
>>>
>>> But I cannot check if the added license was actually provided by the
>>> OpenSocial Foundation itself, or just added for the purpose.
>>>
>>> Because of the above, I'm going to send a request to
>>> opensocial-and-gadgets-spec@**googlegroups.com<op...@googlegroups.com>to
>>> ask if and how we should attribute usage of the spec.
>>>
>>> For the record: the above feedback from general@incubator does mention
>>> several of the same issues I've raised here...
>>>
>>>
>>>
>>>> Seems like 1.f is reasonable.
>>>>
>>> I think so too. I can (will) create a patch specifically for that one, but
>>> as said before that one should only be committed by a Google
>>> representative, e.g. like Paul!
>>>
>>> Regards,
>>>
>>> Ate
>>>
>>>
>>>
>>>>
>>>> Regards,
>>>>
>>>> RYAN J. BAXTER
>>>>
>>>>
>>>>
>>>>
>>>> From: Ate Douma<at...@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:rjbaxter@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<at...@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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>

Re: NOTICE and LICENSE files

Posted by Ate Douma <at...@douma.nu>.

On 02/01/2012 12:39 PM, Paul Lindner wrote:
> wave copyright issues committed in r1239088

Great!

Thanks Paul, that clears 1.f
I'll adjust our NOTICE for rave-shindig accordingly.

Regards, Ate

>
>
> On Wed, Feb 1, 2012 at 12:49 AM, Ate Douma<at...@douma.nu>  wrote:
>
>> Thanks Ryan,
>>
>>
>> On 02/01/2012 03:34 AM, Ryan J Baxter wrote:
>>
>>> Here are my 2 cents...
>>>
>>> For 1.c and 2.a I am not sure how true that is anymore...while some of
>>> those files still exist in Shindig, I am willing to guess that have been
>>> modified and are no longer the same as what is in
>>> http://opensocial-resources.**googlecode.com/svn/spec/0.8/<http://opensocial-resources.googlecode.com/svn/spec/0.8/>.
>>>   Would we have
>>> to go through and check to make sure whether each file has changed?
>>>
>>
>> I've just looked into it a bit further, and I think 1.c no longer is an
>> issue.
>> IMO that notice for the 0.8 spec no longer (and never was) needed.
>> I checked every file of that spec and the only thing I found were Apache 2
>> License headers and no further NOTICE claims. Which means that, by the
>> Apache 2 License, we're not required to carry any further either. If these
>> files are still used or not (and they are) thus isn't an issue.
>>
>> Concerning 2.a, about the separate (Apache 2.0 License based) "Copyright
>> (c) 2009 The OpenSocial Foundation" claim as appended to the /LICENSE file,
>> this isn't 100% clear to me yet.
>> The problem is: it claims (and probably rightfully so) copyright for the
>> OpenSocial Foundation, but *nowhere* in the specification, the website (
>> docs.opensocial.org), or the opensources-resources project on
>> code.google.com can I find *any* copyright claim at all...
>>
>> Now, I assume the OpenSocial Foundation does have (and then should claim)
>> copyright on the specifications, but then they should make that clear and
>> explicit somewhere.
>>
>> Backtracking through svn history, I discovered that this particular
>> license inclusion was added *because* of 1.c in the NOTICE file, as
>> feedback on general@incubator of the Shindig 1.0 (Incubator) release
>> vote, see:
>>
>>    http://s.apache.org/xD9
>>
>> Relevant section (quote from sebb's email):
>>
>>   "NOTICE mentions opensocial-resources, PHPUnit and Zend, but
>>    LICENSE mentions  PHPUnit, Zend and jsmin.php.
>>
>>    I would expect LICENSE to include a mention of opensocial-resources
>>    NOTICE should probably have a mention of jsmin.php"
>>
>>
>> But I cannot check if the added license was actually provided by the
>> OpenSocial Foundation itself, or just added for the purpose.
>>
>> Because of the above, I'm going to send a request to
>> opensocial-and-gadgets-spec@**googlegroups.com<op...@googlegroups.com>to ask if and how we should attribute usage of the spec.
>>
>> For the record: the above feedback from general@incubator does mention
>> several of the same issues I've raised here...
>>
>>
>>
>>> Seems like 1.f is reasonable.
>>>
>> I think so too. I can (will) create a patch specifically for that one, but
>> as said before that one should only be committed by a Google
>> representative, e.g. like Paul!
>>
>> Regards,
>>
>> Ate
>>
>>
>>
>>>
>>> Regards,
>>>
>>> RYAN J. BAXTER
>>>
>>>
>>>
>>>
>>> From:   Ate Douma<at...@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:rjbaxter@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<at...@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
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>

Re: NOTICE and LICENSE files

Posted by Paul Lindner <li...@inuus.com>.

wave copyright issues committed in r1239088


On Wed, Feb 1, 2012 at 12:49 AM, Ate Douma <at...@douma.nu> wrote:

> Thanks Ryan,
>
>
> On 02/01/2012 03:34 AM, Ryan J Baxter wrote:
>
>> Here are my 2 cents...
>>
>> For 1.c and 2.a I am not sure how true that is anymore...while some of
>> those files still exist in Shindig, I am willing to guess that have been
>> modified and are no longer the same as what is in
>> http://opensocial-resources.**googlecode.com/svn/spec/0.8/<http://opensocial-resources.googlecode.com/svn/spec/0.8/>.
>>  Would we have
>> to go through and check to make sure whether each file has changed?
>>
>
> I've just looked into it a bit further, and I think 1.c no longer is an
> issue.
> IMO that notice for the 0.8 spec no longer (and never was) needed.
> I checked every file of that spec and the only thing I found were Apache 2
> License headers and no further NOTICE claims. Which means that, by the
> Apache 2 License, we're not required to carry any further either. If these
> files are still used or not (and they are) thus isn't an issue.
>
> Concerning 2.a, about the separate (Apache 2.0 License based) "Copyright
> (c) 2009 The OpenSocial Foundation" claim as appended to the /LICENSE file,
> this isn't 100% clear to me yet.
> The problem is: it claims (and probably rightfully so) copyright for the
> OpenSocial Foundation, but *nowhere* in the specification, the website (
> docs.opensocial.org), or the opensources-resources project on
> code.google.com can I find *any* copyright claim at all...
>
> Now, I assume the OpenSocial Foundation does have (and then should claim)
> copyright on the specifications, but then they should make that clear and
> explicit somewhere.
>
> Backtracking through svn history, I discovered that this particular
> license inclusion was added *because* of 1.c in the NOTICE file, as
> feedback on general@incubator of the Shindig 1.0 (Incubator) release
> vote, see:
>
>   http://s.apache.org/xD9
>
> Relevant section (quote from sebb's email):
>
>  "NOTICE mentions opensocial-resources, PHPUnit and Zend, but
>   LICENSE mentions  PHPUnit, Zend and jsmin.php.
>
>   I would expect LICENSE to include a mention of opensocial-resources
>   NOTICE should probably have a mention of jsmin.php"
>
>
> But I cannot check if the added license was actually provided by the
> OpenSocial Foundation itself, or just added for the purpose.
>
> Because of the above, I'm going to send a request to
> opensocial-and-gadgets-spec@**googlegroups.com<op...@googlegroups.com>to ask if and how we should attribute usage of the spec.
>
> For the record: the above feedback from general@incubator does mention
> several of the same issues I've raised here...
>
>
>
>> Seems like 1.f is reasonable.
>>
> I think so too. I can (will) create a patch specifically for that one, but
> as said before that one should only be committed by a Google
> representative, e.g. like Paul!
>
> Regards,
>
> Ate
>
>
>
>>
>> Regards,
>>
>> RYAN J. BAXTER
>>
>>
>>
>>
>> From:   Ate Douma<at...@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:rjbaxter@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<at...@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
>>>>
>>>>
>>>
>>
>>
>>
>


-- 
Paul Lindner -- lindner@inuus.com -- profiles.google.com/pmlindner

Re: NOTICE and LICENSE files

Posted by Ate Douma <at...@douma.nu>.

Thanks Ryan,

On 02/01/2012 03:34 AM, Ryan J Baxter wrote:
> Here are my 2 cents...
>
> For 1.c and 2.a I am not sure how true that is anymore...while some of
> those files still exist in Shindig, I am willing to guess that have been
> modified and are no longer the same as what is in
> http://opensocial-resources.googlecode.com/svn/spec/0.8/.  Would we have
> to go through and check to make sure whether each file has changed?

I've just looked into it a bit further, and I think 1.c no longer is an issue.
IMO that notice for the 0.8 spec no longer (and never was) needed.
I checked every file of that spec and the only thing I found were Apache 2 
License headers and no further NOTICE claims. Which means that, by the Apache 2 
License, we're not required to carry any further either. If these files are 
still used or not (and they are) thus isn't an issue.

Concerning 2.a, about the separate (Apache 2.0 License based) "Copyright (c) 
2009 The OpenSocial Foundation" claim as appended to the /LICENSE file, this 
isn't 100% clear to me yet.
The problem is: it claims (and probably rightfully so) copyright for the 
OpenSocial Foundation, but *nowhere* in the specification, the website 
(docs.opensocial.org), or the opensources-resources project on code.google.com 
can I find *any* copyright claim at all...

Now, I assume the OpenSocial Foundation does have (and then should claim) 
copyright on the specifications, but then they should make that clear and 
explicit somewhere.

Backtracking through svn history, I discovered that this particular license 
inclusion was added *because* of 1.c in the NOTICE file, as feedback on 
general@incubator of the Shindig 1.0 (Incubator) release vote, see:

    http://s.apache.org/xD9

Relevant section (quote from sebb's email):

   "NOTICE mentions opensocial-resources, PHPUnit and Zend, but
    LICENSE mentions  PHPUnit, Zend and jsmin.php.

    I would expect LICENSE to include a mention of opensocial-resources
    NOTICE should probably have a mention of jsmin.php"


But I cannot check if the added license was actually provided by the OpenSocial 
Foundation itself, or just added for the purpose.

Because of the above, I'm going to send a request to 
opensocial-and-gadgets-spec@googlegroups.com to ask if and how we should 
attribute usage of the spec.

For the record: the above feedback from general@incubator does mention several 
of the same issues I've raised here...

>
> Seems like 1.f is reasonable.
I think so too. I can (will) create a patch specifically for that one, but as 
said before that one should only be committed by a Google representative, e.g. 
like Paul!

Regards,

Ate

>
>
> Regards,
>
> RYAN J. BAXTER
>
>
>
>
> From:   Ate Douma<at...@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:rjbaxter@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<at...@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://apache.org/legal/resolved.html
>>>     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-62
>>>     https://issues.apache.org/jira/browse/LEGAL-118
>>>     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
>>> 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-
>>> 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
>>> - 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/
>>> - slf4j-api-1.5.11.jar&   slf4j-jdk14-1.5.11.jar: requires MIT license,
>>> see:
>>> http://www.slf4j.org/license.html
>>> - xmlpull-1.1.3.1.jar: public domain, see:
>>> http://www.xmlpull.org/v1/download/unpacked/LICENSE.txt , this requires
>>> attribution in the NOTICE file, see:
> 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-
>>> 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
>>>
>>> ==========
>>>
>>> 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
>>>
>>
>
>
>

Re: NOTICE and LICENSE files

Posted by Ryan J Baxter <rj...@us.ibm.com>.

Here are my 2 cents...

For 1.c and 2.a I am not sure how true that is anymore...while some of 
those files still exist in Shindig, I am willing to guess that have been 
modified and are no longer the same as what is in 
http://opensocial-resources.googlecode.com/svn/spec/0.8/.  Would we have 
to go through and check to make sure whether each file has changed?

Seems like 1.f is reasonable.


Regards,

RYAN J. BAXTER




From:   Ate Douma <at...@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:rjbaxter@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<at...@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://apache.org/legal/resolved.html
>>    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-62
>>    https://issues.apache.org/jira/browse/LEGAL-118
>>    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
>> 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-
>> 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
>> - 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/
>> - slf4j-api-1.5.11.jar&  slf4j-jdk14-1.5.11.jar: requires MIT license,
>> see:
>> http://www.slf4j.org/license.html
>> - xmlpull-1.1.3.1.jar: public domain, see:
>> http://www.xmlpull.org/v1/download/unpacked/LICENSE.txt , this requires
>> attribution in the NOTICE file, see: 
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-
>> 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
>>
>> ==========
>>
>> 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
>>
>

RE: NOTICE and LICENSE files

Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.

>-----Original Message-----
>From: Ate Douma [mailto:ate@douma.nu]
>Sent: Friday, January 27, 2012 9:55 AM
>To: dev@shindig.apache.org
>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.

Understood -- we'll be sure to validate all of your suggestions/comments before making any changes.  I'm hoping to get some time early next week to dig through all of this and follow up with some responses to the open questions you have.

>
>If you create a JIRA ticket for it, I can and will try to create patches for the
>most important of the issues.

JIRA ticket created:  https://issues.apache.org/jira/browse/SHINDIG-1689

Thanks for the help with this Ate!

Re: NOTICE and LICENSE files

Posted by Ate Douma <at...@douma.nu>.

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:rjbaxter@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<at...@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://apache.org/legal/resolved.html
>>    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-62
>>    https://issues.apache.org/jira/browse/LEGAL-118
>>    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
>> 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-
>> 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
>> - 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/
>> - slf4j-api-1.5.11.jar&  slf4j-jdk14-1.5.11.jar: requires MIT license,
>> see:
>> http://www.slf4j.org/license.html
>> - xmlpull-1.1.3.1.jar: public domain, see:
>> http://www.xmlpull.org/v1/download/unpacked/LICENSE.txt , this requires
>> attribution in the NOTICE file, see: 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-
>> 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
>>
>> ==========
>>
>> 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
>>
>

RE: NOTICE and LICENSE files

Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.

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.

>-----Original Message-----
>From: Ryan J Baxter [mailto:rjbaxter@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 <at...@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://apache.org/legal/resolved.html
>   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-62
>   https://issues.apache.org/jira/browse/LEGAL-118
>   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
>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-
>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
>- 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/
>- slf4j-api-1.5.11.jar & slf4j-jdk14-1.5.11.jar: requires MIT license,
>see:
>http://www.slf4j.org/license.html
>- xmlpull-1.1.3.1.jar: public domain, see:
>http://www.xmlpull.org/v1/download/unpacked/LICENSE.txt , this requires
>attribution in the NOTICE file, see: 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-
>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
>
>==========
>
>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
>

Re: NOTICE and LICENSE files

Posted by Ryan J Baxter <rj...@us.ibm.com>.

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 <at...@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://apache.org/legal/resolved.html
   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-62
   https://issues.apache.org/jira/browse/LEGAL-118
   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
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-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
- 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/
- slf4j-api-1.5.11.jar & slf4j-jdk14-1.5.11.jar: requires MIT license, 
see: 
http://www.slf4j.org/license.html
- xmlpull-1.1.3.1.jar: public domain, see: 
http://www.xmlpull.org/v1/download/unpacked/LICENSE.txt , this requires 
attribution in the NOTICE file, see: 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-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

==========

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