wave copyright issues committed in r1239088

On Wed, Feb 1, 2012 at 12:49 AM, Ate Douma <[email protected]> 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<[email protected]>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<[email protected]>
>> To:     [email protected],
>> 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:[email protected]]
>>>> Sent: Thursday, January 26, 2012 8:56 PM
>>>> To: [email protected]
>>>> 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<[email protected]>
>>>> To:     [email protected],
>>>> 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 -- [email protected] -- profiles.google.com/pmlindner

Reply via email to