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