You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by Ate Douma <at...@douma.nu> on 2012/01/30 02:30:33 UTC
[DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE requirements
Hi team,
The next 0.8-incubating release candidate is scheduled for tomorrow, however I'm
afraid I'm not ready (hardly started to be honest) with JIRA-437.
And as IMO that issue really needs to be addressed properly before we can tag
and create the next release candidate, I've now upgraded that issue to priority
BLOCKER.
As I expect JIRA-437 will take me at least several hours to complete, requiring
many recent new dependencies to be 'cleared' as well as dealing with the shindig
situation (missing, incomplete NOTICE and LICENSE files), see SHINDIG-1689, I
won't be able to complete this before the planned 0.8-incubating release tag...
So, I think we have three options:
a) delay the 0.8-incubator release tag a few more days
b) someone else chimes in to (help with) complete JIRA-437
c) branch the trunk for a later (this week) 0.8-incubating release tag so work
on 0.9-incubating can continue right away in trunk, merging fixes from the
branch when they arrive
I expect I can get JIRA-437 finished by myself, at least if it doesn't turn up
something new/unexpected needing further investigation/actions, before end of
this week, hopefully already by Wednesday evening.
WDYT?
Regards, Ate
Re: [DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE requirements
Posted by Jasha Joachimsthal <j....@onehippo.com>.
On 30 January 2012 11:26, Ate Douma <at...@douma.nu> wrote:
> On 01/30/2012 08:33 AM, Jasha Joachimsthal wrote:
>
>> On 30 January 2012 02:30, Ate Douma<at...@douma.nu> wrote:
>>
>> Hi team,
>>>
>>> The next 0.8-incubating release candidate is scheduled for tomorrow,
>>> however I'm afraid I'm not ready (hardly started to be honest) with
>>> JIRA-437.
>>>
>>> And as IMO that issue really needs to be addressed properly before we can
>>> tag and create the next release candidate, I've now upgraded that issue
>>> to
>>> priority BLOCKER.
>>>
>>> As I expect JIRA-437 will take me at least several hours to complete,
>>> requiring many recent new dependencies to be 'cleared' as well as dealing
>>> with the shindig situation (missing, incomplete NOTICE and LICENSE
>>> files),
>>> see SHINDIG-1689, I won't be able to complete this before the planned
>>> 0.8-incubating release tag...
>>>
>>> So, I think we have three options:
>>> a) delay the 0.8-incubator release tag a few more days
>>> b) someone else chimes in to (help with) complete JIRA-437
>>> c) branch the trunk for a later (this week) 0.8-incubating release tag so
>>> work on 0.9-incubating can continue right away in trunk, merging fixes
>>> from
>>> the branch when they arrive
>>>
>>> I expect I can get JIRA-437 finished by myself, at least if it doesn't
>>> turn up something new/unexpected needing further investigation/actions,
>>> before end of this week, hopefully already by Wednesday evening.
>>>
>>> WDYT?
>>>
>>> Regards, Ate
>>>
>>>
>> With some help the delay of the 0.8-incubator release can be minimal. A
>> branch for only a few days is maybe an overkill if the release can be done
>> by Friday instead of Wednesday.
>>
> FYI: the release date was set to today (Monday), not Wednesday.
> Wednesday might even still be possible but I'm in a rather tight squeeze
> the next few days so I cannot promise I'll have enough time until then.
Today is not the last day of the month, neither is Wednesday, but tomorrow
(Tuesday).
>
>
> Regarding the NOTICE entries that are needed due to the incorrect Shindig
>> notice file: can you indicate them in the NOTICE file or otherwise keep a
>> list in a separate file so we can remove them easily after Shindig has
>> cleaned up its NOTICE file?
>>
> No, thats not how it works: our (Rave) NOTICE and LICENSE files need to be
> fully self contained, e.g. cannot/should not 'delegate' to (future) N&L
> files provided for instance by Shindig. If anything, the Rave N&L entries
> needed for using Shindig might be helpful for them to fix their N&L files.
> So there is nothing to be 'cleaned up' afterwards.
Thanks for the explanation
>
>
> BTW you're referring to JIRA-437, but that should be RAVE-437:
>> https://issues.apache.org/**jira/browse/RAVE-437<https://issues.apache.org/jira/browse/RAVE-437>
>>
> Ah, good point :)
>
> Ate
>
>>
>> Jasha
>>
>>
>
Re: [DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE requirements
Posted by Ate Douma <at...@douma.nu>.
On 01/30/2012 08:33 AM, Jasha Joachimsthal wrote:
> On 30 January 2012 02:30, Ate Douma<at...@douma.nu> wrote:
>
>> Hi team,
>>
>> The next 0.8-incubating release candidate is scheduled for tomorrow,
>> however I'm afraid I'm not ready (hardly started to be honest) with
>> JIRA-437.
>>
>> And as IMO that issue really needs to be addressed properly before we can
>> tag and create the next release candidate, I've now upgraded that issue to
>> priority BLOCKER.
>>
>> As I expect JIRA-437 will take me at least several hours to complete,
>> requiring many recent new dependencies to be 'cleared' as well as dealing
>> with the shindig situation (missing, incomplete NOTICE and LICENSE files),
>> see SHINDIG-1689, I won't be able to complete this before the planned
>> 0.8-incubating release tag...
>>
>> So, I think we have three options:
>> a) delay the 0.8-incubator release tag a few more days
>> b) someone else chimes in to (help with) complete JIRA-437
>> c) branch the trunk for a later (this week) 0.8-incubating release tag so
>> work on 0.9-incubating can continue right away in trunk, merging fixes from
>> the branch when they arrive
>>
>> I expect I can get JIRA-437 finished by myself, at least if it doesn't
>> turn up something new/unexpected needing further investigation/actions,
>> before end of this week, hopefully already by Wednesday evening.
>>
>> WDYT?
>>
>> Regards, Ate
>>
>
> With some help the delay of the 0.8-incubator release can be minimal. A
> branch for only a few days is maybe an overkill if the release can be done
> by Friday instead of Wednesday.
FYI: the release date was set to today (Monday), not Wednesday.
Wednesday might even still be possible but I'm in a rather tight squeeze the
next few days so I cannot promise I'll have enough time until then.
> Regarding the NOTICE entries that are needed due to the incorrect Shindig
> notice file: can you indicate them in the NOTICE file or otherwise keep a
> list in a separate file so we can remove them easily after Shindig has
> cleaned up its NOTICE file?
No, thats not how it works: our (Rave) NOTICE and LICENSE files need to be fully
self contained, e.g. cannot/should not 'delegate' to (future) N&L files provided
for instance by Shindig. If anything, the Rave N&L entries needed for using
Shindig might be helpful for them to fix their N&L files. So there is nothing to
be 'cleaned up' afterwards.
> BTW you're referring to JIRA-437, but that should be RAVE-437:
> https://issues.apache.org/jira/browse/RAVE-437
Ah, good point :)
Ate
>
> Jasha
>
Re: [DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE requirements
Posted by Jasha Joachimsthal <j....@onehippo.com>.
On 30 January 2012 02:30, Ate Douma <at...@douma.nu> wrote:
> Hi team,
>
> The next 0.8-incubating release candidate is scheduled for tomorrow,
> however I'm afraid I'm not ready (hardly started to be honest) with
> JIRA-437.
>
> And as IMO that issue really needs to be addressed properly before we can
> tag and create the next release candidate, I've now upgraded that issue to
> priority BLOCKER.
>
> As I expect JIRA-437 will take me at least several hours to complete,
> requiring many recent new dependencies to be 'cleared' as well as dealing
> with the shindig situation (missing, incomplete NOTICE and LICENSE files),
> see SHINDIG-1689, I won't be able to complete this before the planned
> 0.8-incubating release tag...
>
> So, I think we have three options:
> a) delay the 0.8-incubator release tag a few more days
> b) someone else chimes in to (help with) complete JIRA-437
> c) branch the trunk for a later (this week) 0.8-incubating release tag so
> work on 0.9-incubating can continue right away in trunk, merging fixes from
> the branch when they arrive
>
> I expect I can get JIRA-437 finished by myself, at least if it doesn't
> turn up something new/unexpected needing further investigation/actions,
> before end of this week, hopefully already by Wednesday evening.
>
> WDYT?
>
> Regards, Ate
>
With some help the delay of the 0.8-incubator release can be minimal. A
branch for only a few days is maybe an overkill if the release can be done
by Friday instead of Wednesday.
Regarding the NOTICE entries that are needed due to the incorrect Shindig
notice file: can you indicate them in the NOTICE file or otherwise keep a
list in a separate file so we can remove them easily after Shindig has
cleaned up its NOTICE file?
BTW you're referring to JIRA-437, but that should be RAVE-437:
https://issues.apache.org/jira/browse/RAVE-437
Jasha
Re: [DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE
requirements
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 2/2/12 11:06 AM, "Ate Douma" <at...@douma.nu> wrote:
>On 02/02/2012 04:50 AM, Franklin, Matthew B. wrote:
>>
>>
>> On 2/1/12 12:24 PM, "Ate Douma"<at...@douma.nu> wrote:
>>
>>> On 02/01/2012 05:45 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.
>>>>
>>>> I have gone through every jar in rave-portal and checked licenses&
>>>> NOTICE entries. I am going to call it done unless anyone finds
>>>> something I didn't.
>>>>
>>>> Assuming lazy consensus, we make the recent changes to the combined
>>>> LICENSE& NOTICE files in the binary release this evening/tomorrow.
>>>
>>> Great Matt.
>>>
>>> I've not had time to review the final result, but I can and will do so
>>> later
>>> this evening. So if you can hold off until then, I'd appreciate it :)
>>
>> Ate and I found a few more changes, but we think we have the
>>rave-shindig
>> & rave-portal L&N ironed out. I took a first pass at a merge between
>>the
>> two for the binary dist and have committed that back for review. The
>>last
>> piece of the puzzle is to add any licenses or notices that tomcat or
>>other
>> software in the dist have.
>>
>> From what I can tell, tomcat only has 1 EPL jar, the rest is all ASL.
>>I
>> will add the license& notice tomorrow.
>
>Yup, I checked it myself and it looks like the only thing extra needed
>(which
>got lost since the merge, so need to be brought back in) is a notice for:
>
> Java compilation software for JSP pages is provided by Eclipse,
> which is open source software. The original software and
> related information is available at
> http://www.eclipse.org.
>
>and indicating the EPL 1.0 license, which we already have appended to
>LICENSE,
>also applies "For the Eclipse JDT Java compiler".
These entries have been completed. I am going to call this issue complete
and will close the ticket tomorrow morning (assuming noone catches
anything before then and now). We can then go for a release candidate.
>
>Ate
>
>>
>>>
>>> Regards, Ate
>>>
>>
>
Re: [DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE requirements
Posted by Ate Douma <at...@douma.nu>.
On 02/02/2012 04:50 AM, Franklin, Matthew B. wrote:
>
>
> On 2/1/12 12:24 PM, "Ate Douma"<at...@douma.nu> wrote:
>
>> On 02/01/2012 05:45 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.
>>>
>>> I have gone through every jar in rave-portal and checked licenses&
>>> NOTICE entries. I am going to call it done unless anyone finds
>>> something I didn't.
>>>
>>> Assuming lazy consensus, we make the recent changes to the combined
>>> LICENSE& NOTICE files in the binary release this evening/tomorrow.
>>
>> Great Matt.
>>
>> I've not had time to review the final result, but I can and will do so
>> later
>> this evening. So if you can hold off until then, I'd appreciate it :)
>
> Ate and I found a few more changes, but we think we have the rave-shindig
> & rave-portal L&N ironed out. I took a first pass at a merge between the
> two for the binary dist and have committed that back for review. The last
> piece of the puzzle is to add any licenses or notices that tomcat or other
> software in the dist have.
>
> From what I can tell, tomcat only has 1 EPL jar, the rest is all ASL. I
> will add the license& notice tomorrow.
Yup, I checked it myself and it looks like the only thing extra needed (which
got lost since the merge, so need to be brought back in) is a notice for:
Java compilation software for JSP pages is provided by Eclipse,
which is open source software. The original software and
related information is available at
http://www.eclipse.org.
and indicating the EPL 1.0 license, which we already have appended to LICENSE,
also applies "For the Eclipse JDT Java compiler".
Ate
>
>>
>> Regards, Ate
>>
>
Re: [DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE
requirements
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 2/1/12 12:24 PM, "Ate Douma" <at...@douma.nu> wrote:
>On 02/01/2012 05:45 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.
>>
>> I have gone through every jar in rave-portal and checked licenses&
>>NOTICE entries. I am going to call it done unless anyone finds
>>something I didn't.
>>
>> Assuming lazy consensus, we make the recent changes to the combined
>>LICENSE& NOTICE files in the binary release this evening/tomorrow.
>
>Great Matt.
>
>I've not had time to review the final result, but I can and will do so
>later
>this evening. So if you can hold off until then, I'd appreciate it :)
Ate and I found a few more changes, but we think we have the rave-shindig
& rave-portal L&N ironed out. I took a first pass at a merge between the
two for the binary dist and have committed that back for review. The last
piece of the puzzle is to add any licenses or notices that tomcat or other
software in the dist have.
>From what I can tell, tomcat only has 1 EPL jar, the rest is all ASL. I
will add the license & notice tomorrow.
>
>Regards, Ate
>
Re: [DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE requirements
Posted by Ate Douma <at...@douma.nu>.
On 02/01/2012 05:45 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.
>
> I have gone through every jar in rave-portal and checked licenses& NOTICE entries. I am going to call it done unless anyone finds something I didn't.
>
> Assuming lazy consensus, we make the recent changes to the combined LICENSE& NOTICE files in the binary release this evening/tomorrow.
Great Matt.
I've not had time to review the final result, but I can and will do so later
this evening. So if you can hold off until then, I'd appreciate it :)
Regards, Ate
RE: [DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE
requirements
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
<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.
I have gone through every jar in rave-portal and checked licenses & NOTICE entries. I am going to call it done unless anyone finds something I didn't.
Assuming lazy consensus, we make the recent changes to the combined LICENSE & NOTICE files in the binary release this evening/tomorrow.
Re: [DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE requirements
Posted by Ate Douma <at...@douma.nu>.
On 01/31/2012 11:34 PM, Ate Douma wrote:
> On 01/31/2012 11:10 PM, Franklin, Matthew B. wrote:
>>
>>
>>> -----Original Message-----
>>> From: Ate Douma [mailto:ate@douma.nu]
>>> Sent: Tuesday, January 31, 2012 3:02 PM
>>> To: rave-dev@incubator.apache.org
>>> 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?
> Not by the project but by the ASF itself.
> EPL/CDDL/MPL/etc are all so called "Weak Copyleft" license, or in ASF
> 'terminology' licensed from category B, see:
>
> http://apache.org/legal/resolved.html#category-b
>
> Those licenses need special handling (and only allow for binary inclusion). The
> above link says that these licensed may only be used "[...] if the inclusion is
> appropriate labeled[...]".
>
> And this is exactly where NOTICE files are meant for, thus if you include
> software based on a category-b license, we (the ASF) require you to provide such
> a notice, regardless of any possible additional notice requirements the 3rd
> party might add to that.
>
> Note: I've used the same 'policy' for usages of software licensed to the public
> domain. That might be debatable and I've seen different opinions about it.
> Public domain licensed software isn't without its problems in general so should
> not be automatically regarded as 'easy' to include. See also:
>
>
> http://apache.org/legal/resolved.html#can_works_placed_in_the_public_domain_be_included_in_apache_products
>
>
>>
>>> 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?
> If the attributions are valid/needed then yes. In the example above, for
> apache-shindig the 3rd party notice embedded within the spring-aop jar concerns
> possible usage/inclusion of the asm-2.2.3.jar. Which in the apache-shindig case
> doesn't apply as we don't use/bundle, so I didn't move (copy) that specific
> notice to our NOTICE file.
Correction: I intended to say 'in the rave-shindig' case [...]. Apache Shindig
itself doesn't use or include springframework.
>
>>
>>>
>>>
>>> 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.
> Cool.
> My point was nobody (besides you) should get the impression this could maybe
> easily or even partly be automated, which it cannot. As long as that is clear to
> everyone, I'm fine :)
>
> Good luck with the task!
>
> Ate
>
>>
>>> 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
>
Re: [DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE requirements
Posted by Ate Douma <at...@douma.nu>.
On 01/31/2012 11:10 PM, Franklin, Matthew B. wrote:
>
>
>> -----Original Message-----
>> From: Ate Douma [mailto:ate@douma.nu]
>> Sent: Tuesday, January 31, 2012 3:02 PM
>> To: rave-dev@incubator.apache.org
>> 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?
Not by the project but by the ASF itself.
EPL/CDDL/MPL/etc are all so called "Weak Copyleft" license, or in ASF
'terminology' licensed from category B, see:
http://apache.org/legal/resolved.html#category-b
Those licenses need special handling (and only allow for binary inclusion). The
above link says that these licensed may only be used "[...] if the inclusion is
appropriate labeled[...]".
And this is exactly where NOTICE files are meant for, thus if you include
software based on a category-b license, we (the ASF) require you to provide such
a notice, regardless of any possible additional notice requirements the 3rd
party might add to that.
Note: I've used the same 'policy' for usages of software licensed to the public
domain. That might be debatable and I've seen different opinions about it.
Public domain licensed software isn't without its problems in general so should
not be automatically regarded as 'easy' to include. See also:
http://apache.org/legal/resolved.html#can_works_placed_in_the_public_domain_be_included_in_apache_products
>
>> 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?
If the attributions are valid/needed then yes. In the example above, for
apache-shindig the 3rd party notice embedded within the spring-aop jar concerns
possible usage/inclusion of the asm-2.2.3.jar. Which in the apache-shindig case
doesn't apply as we don't use/bundle, so I didn't move (copy) that specific
notice to our NOTICE file.
>
>>
>>
>> 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.
Cool.
My point was nobody (besides you) should get the impression this could maybe
easily or even partly be automated, which it cannot. As long as that is clear to
everyone, I'm fine :)
Good luck with the task!
Ate
>
>> 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
RE: [DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE
requirements
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
>-----Original Message-----
>From: Ate Douma [mailto:ate@douma.nu]
>Sent: Tuesday, January 31, 2012 3:02 PM
>To: rave-dev@incubator.apache.org
>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
Re: [DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE requirements
Posted by Ate Douma <at...@douma.nu>.
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.
> 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.
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 needed
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).
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:
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
RE: [DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE
requirements
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
<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; which will result in more attributions, not less based on what I have found. I don't know if EPL or CDDL have similar provisions, but I will need to read to get a better idea.
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.
Does everyone agree this is the correct approach or should I take this back to legal?
RE: [DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE
requirements
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
-----Original Message-----
>From: Franklin, Matthew B. [mailto:mfranklin@mitre.org]
>Sent: Tuesday, January 31, 2012 12:49 PM
>To: rave-dev@incubator.apache.org
>Subject: RE: [DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE
>requirements
>
><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; which will result in
>more attributions, not less based on what I have found. I don't know if EPL or
>CDDL have similar provisions, but I will need to read to get a better idea.
>
>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.
Or not. Here are links:
http://people.apache.org/~mfranklin/LICENSE_COMBINED
http://people.apache.org/~mfranklin/NOTICE_COMBINED
>
>Does everyone agree this is the correct approach or should I take this back to
>legal?
Re: [DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE
requirements
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 1/30/12 7:50 PM, "Ate Douma" <at...@douma.nu> wrote:
>On 01/30/2012 11:00 AM, Ate Douma wrote:
>> On 01/30/2012 02:44 AM, Franklin, Matthew B. wrote:
>>> On 1/29/12 8:30 PM, "Ate Douma"<at...@douma.nu> wrote:
>
><snip/>
>
>>>> I expect I can get JIRA-437 finished by myself, at least if it doesn't
>>>> turn up
>>>> something new/unexpected needing further investigation/actions, before
>>>> end of
>>>> this week, hopefully already by Wednesday evening.
>>>
>>> Let's figure out a division of labor that makes sense.
>>
>> The most of the work is related to the rave-shindig and rave-portal war
>>modules,
>> as they pull in and bundle all kinds of 3rd party dependencies.
>>
>> What we could start with is split the work between these modules. As
>>I've
>> already done many/most of the work on reviewing shindig-server, and
>>need to
>> follow up on that with shindig PMC anyway, I will start myself with
>> rave-shindig. If you can start with rave-portal that would be very
>>helpful.
>>
>> Further background and steps to be taken I think I've already described
>> reasonably well in my email to dev@shindig last week [1], but if you
>>have any
>> further questions just ping me.
>
>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.
>
>
>>
>> Thanks, Ate
>>
>>
>> [1]
>>
>>http://mail-archives.apache.org/mod_mbox/shindig-dev/201201.mbox/%3C4F20C
>>2D2.9030000@douma.nu%3E
>>
>>>
>>>>
>>>> WDYT?
>>>>
>>>> Regards, Ate
>>>
>>
>
Re: [DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE requirements
Posted by Ate Douma <at...@douma.nu>.
On 01/30/2012 11:00 AM, Ate Douma wrote:
> On 01/30/2012 02:44 AM, Franklin, Matthew B. wrote:
>> On 1/29/12 8:30 PM, "Ate Douma"<at...@douma.nu> wrote:
<snip/>
>>> I expect I can get JIRA-437 finished by myself, at least if it doesn't
>>> turn up
>>> something new/unexpected needing further investigation/actions, before
>>> end of
>>> this week, hopefully already by Wednesday evening.
>>
>> Let's figure out a division of labor that makes sense.
>
> The most of the work is related to the rave-shindig and rave-portal war modules,
> as they pull in and bundle all kinds of 3rd party dependencies.
>
> What we could start with is split the work between these modules. As I've
> already done many/most of the work on reviewing shindig-server, and need to
> follow up on that with shindig PMC anyway, I will start myself with
> rave-shindig. If you can start with rave-portal that would be very helpful.
>
> Further background and steps to be taken I think I've already described
> reasonably well in my email to dev@shindig last week [1], but if you have any
> further questions just ping me.
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.
>
> Thanks, Ate
>
>
> [1]
> http://mail-archives.apache.org/mod_mbox/shindig-dev/201201.mbox/%3C4F20C2D2.9030000@douma.nu%3E
>
>>
>>>
>>> WDYT?
>>>
>>> Regards, Ate
>>
>
Re: [DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE requirements
Posted by Ate Douma <at...@douma.nu>.
On 01/30/2012 02:44 AM, Franklin, Matthew B. wrote:
> On 1/29/12 8:30 PM, "Ate Douma"<at...@douma.nu> wrote:
>
>> Hi team,
>>
>> The next 0.8-incubating release candidate is scheduled for tomorrow,
>> however I'm
>> afraid I'm not ready (hardly started to be honest) with JIRA-437.
>>
>> And as IMO that issue really needs to be addressed properly before we can
>> tag
>> and create the next release candidate, I've now upgraded that issue to
>> priority
>> BLOCKER.
>
> +1
>
>>
>> As I expect JIRA-437 will take me at least several hours to complete,
>> requiring
>> many recent new dependencies to be 'cleared' as well as dealing with the
>> shindig
>> situation (missing, incomplete NOTICE and LICENSE files), see
>> SHINDIG-1689, I
>> won't be able to complete this before the planned 0.8-incubating release
>> tag...
>>
>> So, I think we have three options:
>> a) delay the 0.8-incubator release tag a few more days
>
> I think this is probably the easiest
I fully agree.
>
>> b) someone else chimes in to (help with) complete JIRA-437
>
> I can help you take on this task and I think we delay 0.8 until this is
> completed.
Cool and thanks Matt!
>
>> c) branch the trunk for a later (this week) 0.8-incubating release tag so
>> work
>> on 0.9-incubating can continue right away in trunk, merging fixes from
>> the
>> branch when they arrive
>>
>> I expect I can get JIRA-437 finished by myself, at least if it doesn't
>> turn up
>> something new/unexpected needing further investigation/actions, before
>> end of
>> this week, hopefully already by Wednesday evening.
>
> Let's figure out a division of labor that makes sense.
The most of the work is related to the rave-shindig and rave-portal war modules,
as they pull in and bundle all kinds of 3rd party dependencies.
What we could start with is split the work between these modules. As I've
already done many/most of the work on reviewing shindig-server, and need to
follow up on that with shindig PMC anyway, I will start myself with
rave-shindig. If you can start with rave-portal that would be very helpful.
Further background and steps to be taken I think I've already described
reasonably well in my email to dev@shindig last week [1], but if you have any
further questions just ping me.
Thanks, Ate
[1]
http://mail-archives.apache.org/mod_mbox/shindig-dev/201201.mbox/%3C4F20C2D2.9030000@douma.nu%3E
>
>>
>> WDYT?
>>
>> Regards, Ate
>
Re: [DISCUSS] Next 0.8-incubating release: LICENSE and NOTICE
requirements
Posted by "Franklin, Matthew B." <mf...@mitre.org>.
On 1/29/12 8:30 PM, "Ate Douma" <at...@douma.nu> wrote:
>Hi team,
>
>The next 0.8-incubating release candidate is scheduled for tomorrow,
>however I'm
>afraid I'm not ready (hardly started to be honest) with JIRA-437.
>
>And as IMO that issue really needs to be addressed properly before we can
>tag
>and create the next release candidate, I've now upgraded that issue to
>priority
>BLOCKER.
+1
>
>As I expect JIRA-437 will take me at least several hours to complete,
>requiring
>many recent new dependencies to be 'cleared' as well as dealing with the
>shindig
>situation (missing, incomplete NOTICE and LICENSE files), see
>SHINDIG-1689, I
>won't be able to complete this before the planned 0.8-incubating release
>tag...
>
>So, I think we have three options:
>a) delay the 0.8-incubator release tag a few more days
I think this is probably the easiest
>b) someone else chimes in to (help with) complete JIRA-437
I can help you take on this task and I think we delay 0.8 until this is
completed.
>c) branch the trunk for a later (this week) 0.8-incubating release tag so
>work
>on 0.9-incubating can continue right away in trunk, merging fixes from
>the
>branch when they arrive
>
>I expect I can get JIRA-437 finished by myself, at least if it doesn't
>turn up
>something new/unexpected needing further investigation/actions, before
>end of
>this week, hopefully already by Wednesday evening.
Let's figure out a division of labor that makes sense.
>
>WDYT?
>
>Regards, Ate