Re: [VOTE] Apache Slider (incubating) release 0.90.2-incubating
+1 (binding) Regards JB On 01/04/2016 08:34 PM, Steve Loughran wrote: Hello, This is a call for a vote on the Apache Slider (incubating) release 0.90.2-incubating. This release candidate, 0.90.2-incubating-RC1 has successfully passed a vote for a release on the slider developer mailing list. Vote thread: http://mail-archives.apache.org/mod_mbox/incubator-slider-dev/201505.mbox/%3CD17220E0.D0AD%25gsaha%40hortonworks.com%3E Results: http://mail-archives.apache.org/mod_mbox/incubator-slider-dev/201505.mbox/%3CD177A7D8.D521%25gsaha%40hortonworks.com%3E Issues fixed: https://issues.apache.org/jira/browse/SLIDER/fixforversion/12334370/ Release Notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315422&version=12334370 Source artifacts: https://dist.apache.org/repos/dist/release/incubator/slider/0.90.2-incubating-RC1 Staged artifacts: https://repository.apache.org/content/repositories/orgapacheslider-1013/ Git source: https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;a=commit;h=9bb379f83c78b61aeb4110b93796bc02c08c4226 Git commit SHA1: 9bb379f83c78b61aeb4110b93796bc02c08c4226 PGP key: http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=ste...@apache.org Please vote on releasing this package as Apache Slider 0.90.2-incubating: This vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) stevel on behalf of the Apache Slider (incubating) team - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating
+1 (non-binding) Trafodion has the rich SQL feature to complement NoSQL DB's shortage. -- View this message in context: http://apache-incubator-general.996316.n3.nabble.com/VOTE-Release-Apache-Trafodion-incubating-1-3-0-incubating-tp47745p47760.html Sent from the Apache Incubator - General mailing list archive at Nabble.com. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: File headers for third party utility code
On Mon, Jan 4, 2016 at 3:02 PM, Roman Shaposhnik wrote: > On Mon, Jan 4, 2016 at 2:50 PM, Todd Lipcon wrote: >> Hi all, >> >> I'm working on verifying licenses and copyrights, etc, in Apache Kudu >> (incubating). There is one area I wanted to confirm the right way to >> document in our LICENSE/NOTICE files: >> >> Kudu makes use of a lot of open source utility code borrowed from (or >> adapted from) other open source projects. In particular, we've borrowed a >> lot of code from Chromium's "base" module[1] which is licensed under a BSD >> 3-clause license[2]. We also have some code from Google Supersonic[3] >> licensed under the Apache License[4]. The majority of this borrowed code is >> under a 'gutil' directory in the Kudu tree[5]. We also have some small >> amounts of code borrowed from LevelDB under the BSD license[6]. > > I am in exactly the same boat dealing with Copyright statements of code > borrowed from Postgres. > >> Given that all of the borrowed code is under the Apache or BSD licenses, >> the inclusion of the code is completely allowable under the license terms. >> The only question is the best way to document the inclusion to best follow >> established ASF practices. My understanding is that we should: >> >> 1) Maintain the original copyright notices and license headers in the files. > > Correct. Unless you're a copyright holder or an authorized representative > of one, you're not allowed to touch existing copyright notices in files. +1 >> 2) In the cases that we've made non-trivial changes to the source, we >> should additionally add the ASF copyright notice at the top of the file, >> and amend the original copyright statement with the words "Some portions" >> as we've done for example in cache.cc[7]. > > I don't think you need to do that, but you do need an ASF license header. > > I don't think ASF encourages "Portions Copyright ... ASF" statements > on individual files. See below... >> 3) In all files (regardless of whether we've made changes), we should add >> the Apache license header above any existing license headers, while >> maintaining the existing one. > > Correct and it should also solve #2 Alex got to this link before I did, which answers the question more authoritatively: http://www.apache.org/legal/src-headers.html#3party As to where to draw the line between major and minor modifications, I don't recall having seen a conversation about that on either general@incubator or legal-discuss@apache in the last several years. (Though maybe it happened and memory fails.) I suggest bringing this topic up on legal-discuss@apache. >> 4) In the LICENSE file, we should make note of the included code and its >> copyrights as we have done here[8]. > > I tend to be in the camp that values simplicity of LICENSE file. IOW, > this need to be a succinct communication of what an overall license > for the source bundle is and that's ALv2. Perhaps I'm misinterpreting, but this advice seems to be "The LICENSE file should contain the ALv2 and nothing more." The position that only the ALv2 should go into LICENSE is legally defensible, but it contradicts both ASF Release Policy and other documentation such as the Licensing How-To[1]. http://www.apache.org/legal/release-policy#license-file When a package bundles code under several licenses, the LICENSE file MUST contain details of all these licenses. For each component which is not Apache licensed, details of the component MUST be appended to the LICENSE file I think it's important that the Incubator avoid offering guidance on such matters which conflicts with policy, even if the position is defensible. Arguing about this stuff is boring and time-sucking. The more formulaic we can make licensing, the less of a drain it will be on our volunteers. > You do need to update NOTICE files accordingly though. This is hard to disagree with, but ambiguous -- so please bear with me while I restate with different emphasis... There are a handful of things which need absolutely need to go in NOTICE. Anything else needs to be kept out. Here is a non-exhaustive list of things which people seem quite tempted to put into NOTICE files but which don't belong there: * Details of non-bundled dependencies * Details of dependencies which are bundled with a convenience binary but not with the official source release * Details of bundled MIT-licensed dependencies * Details of bundled BSD2-licensed/BSD3-licensed dependencies * Details of bundled ALv2-licensed dependencies which do not themselves provide a NOTICE file. Please folks, keep LICENSE and NOTICE correct but minimal, so that downstream consumers are spared from having to deal with needlessly complicated licensing. Marvin Humphrey [1] http://www.apache.org/dev/licensing-howto - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@
Help for the Log4cxx podling
Hi all, I happened to stumble upon the log4cxx mailing list where there is concern over mentor participation. It appears that they may need help, more mentor participation to help get reports through. They're a small podling, so I'm wondering if there's ways to help them out? It seems like Christian G was their main mentor, but he may be a bit busy right now. John
Re: [VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating
+1 (binding) Source looks fine. Didn't try to build, missing libs locally to build. Some items for next release: - Preferable to use NOTICE, LICENSE, DISCLAIMER over NOTICE.TXT, LICENSE.TXT, DISCLAIMER.TXT - Update copyright years to 2016. John On Mon, Jan 4, 2016 at 5:41 PM Roberta Marton wrote: > Hello, > > > > The Apache Trafodion community has voted on and approved its first release > > – Apache Trafodion 1.3.0 –incubating (release candidate 5) > > > > Vote request on dev list: > > > http://mail-archives.apache.org/mod_mbox/incubator-trafodion-dev/201512.mbox/ajax/%3C835f19bc6267f402358a71221c2b6afc%40mail.gmail.com%3E > > > > Vote result on dev list: > > > http://mail-archives.apache.org/mod_mbox/incubator-trafodion-dev/201601.mbox/ajax/%3Cf41e5961dcf6f0d0d86ee766a6a93833%40mail.gmail.com%3E > > > > The commit id is 6ae976fdc60a683e954d867dab6ff30c55146c8f which corresponds > to tag 1.3.0rc5: > > > https://git-wip-us.apache.org/repos/asf?p=incubator-trafodion.git;a=tag;h=5af956f989f1f32664bbec768e4f354516daa96b > > > > The release artifacts can be downloaded from: > > > https://dist.apache.org/repos/dist/dev/incubator/trafodion/apache-trafodion-1.3.0-incubating > > > > Instructions on how to build and run Apache Trafodion are described here: > > http://trafodion.apache.org/download.html > > > > The source tar file has been signed with pgp key A44C5A05 which is included > in the download location’s KEYS file: > > https://dist.apache.org/repos/dist/dev/incubator/trafodion/KEYS > > > > For changes included in the release, please see the release notes: > > http://trafodion.apache.org/release-notes-1-3-0.html > > > > The RAT tool was run on the source and the excluded are defined in the > > RAT_README.txt file found in the top level source directory. > > > > The following is a list of issues found during the podling review. It was > determined that these issues can be fixed in a subsequent release, Jira’s, > as noted, were created for each issue. > > > > TRAFODION-1733: Incorrect information included in LICENSE file > > The Facebook copyright is already Apache and does not need to be in the > LICENSE file > > Asciidocs is included but not used > > TRAFODION-1725: missing licenses for: > > MooTools Framework MIT licensed Copyright Valerio Proietti > > swscanf.cpp/swprintf.cpp BSD license copyright Chris Torek > > JQuery files - JQuery Foundation, Inc > > TRAFODION-1734: Suggestions for licensing improvements: > > Should specify the type of license in the LICENSE file instead of > requiring a lookup in the corresponding license text. > > Should copy all license text to Apache Trafodion instead of specifying an > external link. The external license could change. > > TRAFODION-1735: There was a concern that changes made to some of the BSD > copyrighted files were more than minor so additional copyright information > may be required. > > > > > > Pursuant to the Release section of the Incubation Policy and with the > > endorsement of our mentors we would now like to request the permission of > > the Incubator PMC to publish the release. > > > > The vote will be open for 72 hours. > > > > [ ] +1 approve > > [ ] +0 no opinion > > [ ] -1 disapprove (and reason why) > > > >Regards, > > Roberta Marton >
Re: January 2016 Report
On Mon, Jan 4, 2016 at 4:04 PM, Deron Eriksson wrote: > My Incubator wiki login is: DeronEriksson > Mike's Incubator wiki login is: MikeDusenberry You've been whitelisted. Happy wikifying! Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: January 2016 Report
Hello Marvin, My Incubator wiki login is: DeronEriksson Mike's Incubator wiki login is: MikeDusenberry Thank you! Deron On Mon, Jan 4, 2016 at 3:35 PM, Marvin Humphrey wrote: > On Mon, Jan 4, 2016 at 3:24 PM, Deron Eriksson > wrote: > > > Would it be possible for a couple SystemML project committers to be given > > edit capabilities to the report page, such as Fred Reiss (freiss), Deron > > Eriksson (deron), and Mike Dusenberry (dusenberrymw)? Where can I make > such > > a request? If we can't request edit capabilities, should the status > > information be emailed to a particular address? > > The wiki is protected by a whitelist of contributors as an anti-spam > measure. What we need to know are your logins for the Incubator wiki, > which are not the same as your Apache IDs. Those look like Apache IDs > above. Can you please supply us with your Incubator wiki logins? > > Marvin Humphrey >
Re: File headers for third party utility code
On 1/4/16, 3:41 PM, "Todd Lipcon" wrote: > >Right, I guess I'm not sure what qualifies minor vs major. In some cases, >we've done trivial edits like putting things in a "kudu" namespace or >removing some portability code. In other cases, we've made more >substantial >alterations to fit our codebase (eg >https://github.com/cloudera/kudu/commit/0ee3218b9edcd7e5e9d450307bc22d0ead >fb53be >) but still kept the overall API/design. At what point do we go ahead and >add the Apache License header? The way I think of it is that every line of code has a home. The home for 3rd-party code is not in the ASF repo or the source package you downloaded from Apache, so we want to warn folks that more care is needed when mucking in a particular file/folder. When there are lines of code whose home is the ASF mixed with code whose home is not at the ASF, IMO, that still needs to be pointed out in LICENSE until the amount of non-ASF code is reduced to the point where mucking with that code isn't going to matter to the home community. The uber ASF license in the LICENSE file grants permission to all lines whose home is the ASF regardless of what the header looks like. I would put annotations in the source code about what code in a mixed file does have a home at the ASF if I thought it would be helpful. I would not add all of that information to the LICENSE. An attorney for my employer said that these headers are just sign posts provided as a convenience to the consumer. The code is owned and has a home regardless of header. The header and any other annotations in a source file are just to save the consumer time in figuring out who owns what and where the "canonical copy" lives. The LICENSE file is IMO, also a sign post. So, when grabbing a release for use, LICENSE ought to give me a quick idea of the ingredients (which is why I prefer pointers to 3rd party licenses vs whole copies of licenses). Then if I feel the need to go change some source code, the headers and other annotations in that file give me a warning that the contents may not all have a home at the ASF. After that it is a judgement call as to whether it is worth making the file more bloated at the line-level to define the boundaries of the mixing or make it an exercise of the consumer to figure it out. But at least they've been warned. My 2 cents, -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: File headers for third party utility code
On Mon, Jan 4, 2016 at 3:29 PM, Alex Harui wrote: > > > On 1/4/16, 3:02 PM, "shaposh...@gmail.com on behalf of Roman Shaposhnik" > wrote: >> >>> 2) In the cases that we've made non-trivial changes to the source, we >>> should additionally add the ASF copyright notice at the top of the file, >>> and amend the original copyright statement with the words "Some >>>portions" >>> as we've done for example in cache.cc[7]. >> >>I don't think you need to do that, but you do need an ASF license header. >> >>I don't think ASF encourages "Portions Copyright ... ASF" statements >>on individual files. >> >>> 3) In all files (regardless of whether we've made changes), we should >>>add >>> the Apache license header above any existing license headers, while >>> maintaining the existing one. >> >>Correct and it should also solve #2 > > Doesn't #3 from http://www.apache.org/legal/src-headers.html#3party > contradict this? Hm. This is tricky, now that I re-read the language of the ASF license header I'm not sure anymore. I *think* the language there should allow you to slap said header on a compatible license code. Besides, the alternative is much messier: every time somebody touches that file he/she needs to decide whether it is time for an ASF header or not. I *think* (but I'd love for old-timers to chime in and correct me) that #3-5 were written from though-shall-not-fork-communities perspective. WDOT? Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: File headers for third party utility code
On Mon, Jan 4, 2016 at 3:29 PM, Alex Harui wrote: > > > On 1/4/16, 3:02 PM, "shaposh...@gmail.com on behalf of Roman Shaposhnik" > wrote: > > > >> 2) In the cases that we've made non-trivial changes to the source, we > >> should additionally add the ASF copyright notice at the top of the file, > >> and amend the original copyright statement with the words "Some > >>portions" > >> as we've done for example in cache.cc[7]. > > > >I don't think you need to do that, but you do need an ASF license header. > > > >I don't think ASF encourages "Portions Copyright ... ASF" statements > >on individual files. > > > >> 3) In all files (regardless of whether we've made changes), we should > >>add > >> the Apache license header above any existing license headers, while > >> maintaining the existing one. > > > >Correct and it should also solve #2 > > Doesn't #3 from http://www.apache.org/legal/src-headers.html#3party > contradict this? > > > 0. The term "third-party work" refers to a work not submitted directly to > the ASF by the copyright owner or owner's agent. > 1. Do not modify or remove any copyright notices or licenses within > third-party works. > 2. Do ensure that every third-party work includes its associated license, > even if that requires adding a copy of the license from the third-party > download site into the distribution. > 3. Do not add the standard Apache License header to the top of third-party > source files. > 4. Minor modifications/additions to third-party source files should > typically be licensed under the same terms as the rest of the rest of the > third-party source for convenience. > 5. Major modifications/additions to third-party should be dealt with on a > case-by-case basis by the PMC. > Right, I guess I'm not sure what qualifies minor vs major. In some cases, we've done trivial edits like putting things in a "kudu" namespace or removing some portability code. In other cases, we've made more substantial alterations to fit our codebase (eg https://github.com/cloudera/kudu/commit/0ee3218b9edcd7e5e9d450307bc22d0eadfb53be ) but still kept the overall API/design. At what point do we go ahead and add the Apache License header? -Todd -- Todd Lipcon Software Engineer, Cloudera
Re: January 2016 Report
On Mon, Jan 4, 2016 at 3:24 PM, Deron Eriksson wrote: > Would it be possible for a couple SystemML project committers to be given > edit capabilities to the report page, such as Fred Reiss (freiss), Deron > Eriksson (deron), and Mike Dusenberry (dusenberrymw)? Where can I make such > a request? If we can't request edit capabilities, should the status > information be emailed to a particular address? The wiki is protected by a whitelist of contributors as an anti-spam measure. What we need to know are your logins for the Incubator wiki, which are not the same as your Apache IDs. Those look like Apache IDs above. Can you please supply us with your Incubator wiki logins? Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: January 2016 Report
On Mon, Jan 4, 2016 at 3:24 PM, Deron Eriksson wrote: > Hello, > > This is Deron Eriksson from the SystemML Apache Incubator project. I think > Luciano Resende (lresende) (who filed the last monthly report) may be on > vacation for another week, and the Apache Incubator status report is due > this Wednesday Jan 6th. I logged on to > https://wiki.apache.org/incubator/January2016 but I see it listed as > "Immutable Page" for me. > > Would it be possible for a couple SystemML project committers to be given > edit capabilities to the report page, such as Fred Reiss (freiss), Deron > Eriksson (deron), and Mike Dusenberry (dusenberrymw)? Where can I make such > a request? If we can't request edit capabilities, should the status > information be emailed to a particular address? > > Thank you! > Deron > > > > Is there a draft ? I or any other mentor can add to the wiki while others are seeking for wiki permissions. -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
Re: File headers for third party utility code
On 1/4/16, 3:02 PM, "shaposh...@gmail.com on behalf of Roman Shaposhnik" wrote: > >> 2) In the cases that we've made non-trivial changes to the source, we >> should additionally add the ASF copyright notice at the top of the file, >> and amend the original copyright statement with the words "Some >>portions" >> as we've done for example in cache.cc[7]. > >I don't think you need to do that, but you do need an ASF license header. > >I don't think ASF encourages "Portions Copyright ... ASF" statements >on individual files. > >> 3) In all files (regardless of whether we've made changes), we should >>add >> the Apache license header above any existing license headers, while >> maintaining the existing one. > >Correct and it should also solve #2 Doesn't #3 from http://www.apache.org/legal/src-headers.html#3party contradict this? 0. The term "third-party work" refers to a work not submitted directly to the ASF by the copyright owner or owner's agent. 1. Do not modify or remove any copyright notices or licenses within third-party works. 2. Do ensure that every third-party work includes its associated license, even if that requires adding a copy of the license from the third-party download site into the distribution. 3. Do not add the standard Apache License header to the top of third-party source files. 4. Minor modifications/additions to third-party source files should typically be licensed under the same terms as the rest of the rest of the third-party source for convenience. 5. Major modifications/additions to third-party should be dealt with on a case-by-case basis by the PMC. Thanks, -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: January 2016 Report
Hello,
This is Deron Eriksson from the SystemML Apache Incubator project. I think
Luciano Resende (lresende) (who filed the last monthly report) may be on
vacation for another week, and the Apache Incubator status report is due
this Wednesday Jan 6th. I logged on to
https://wiki.apache.org/incubator/January2016 but I see it listed as
"Immutable Page" for me.
Would it be possible for a couple SystemML project committers to be given
edit capabilities to the report page, such as Fred Reiss (freiss), Deron
Eriksson (deron), and Mike Dusenberry (dusenberrymw)? Where can I make such
a request? If we can't request edit capabilities, should the status
information be emailed to a particular address?
Thank you!
Deron
On Wed, Dec 30, 2015 at 2:05 PM, Marvin Humphrey wrote:
> Greetings, {podling} developers!
>
> This is a reminder that your report is due next Wednesday, January
> 6th. Details below.
>
> Best,
>
> Marvin Humphrey, Report Manager for January, on behalf of the
> Incubator PMC
>
> ---
>
> Dear podling,
>
> This email was sent by an automated system on behalf of the Apache
> Incubator PMC. It is an initial reminder to give you plenty of time to
> prepare your quarterly board report.
>
> The board meeting is scheduled for Wed, 20 January 2016, 10:30 am PDT.
> The report for your podling will form a part of the Incubator PMC
> report. The Incubator PMC requires your report to be submitted 2 weeks
> before the board meeting, to allow sufficient time for review and
> submission (Wed, January 6th).
>
> Please submit your report with sufficient time to allow the Incubator
> PMC, and subsequently board members to review and digest. Again, the
> very latest you should submit your report is 2 weeks prior to the board
> meeting.
>
> Thanks,
>
> The Apache Incubator PMC
>
> Submitting your Report
>
> --
>
> Your report should contain the following:
>
> * Your project name
> * A brief description of your project, which assumes no knowledge of
> the project or necessarily of its field
> * A list of the three most important issues to address in the move
> towards graduation.
> * Any issues that the Incubator PMC or ASF Board might wish/need to be
> aware of
> * How has the community developed since the last report
> * How has the project developed since the last report.
>
> This should be appended to the Incubator Wiki page at:
>
> http://wiki.apache.org/incubator/January2016
>
> Note: This is manually populated. You may need to wait a little before
> this page is created from a template.
>
> Mentors
> ---
>
> Mentors should review reports for their project(s) and sign them off on
> the Incubator wiki page. Signing off reports shows that you are
> following the project - projects that are not signed may raise alarms
> for the Incubator PMC.
>
> Incubator PMC
>
>
Re: File headers for third party utility code
On Mon, Jan 4, 2016 at 2:50 PM, Todd Lipcon wrote: > Hi all, > > I'm working on verifying licenses and copyrights, etc, in Apache Kudu > (incubating). There is one area I wanted to confirm the right way to > document in our LICENSE/NOTICE files: > > Kudu makes use of a lot of open source utility code borrowed from (or > adapted from) other open source projects. In particular, we've borrowed a > lot of code from Chromium's "base" module[1] which is licensed under a BSD > 3-clause license[2]. We also have some code from Google Supersonic[3] > licensed under the Apache License[4]. The majority of this borrowed code is > under a 'gutil' directory in the Kudu tree[5]. We also have some small > amounts of code borrowed from LevelDB under the BSD license[6]. I am in exactly the same boat dealing with Copyright statements of code borrowed from Postgres. > Given that all of the borrowed code is under the Apache or BSD licenses, > the inclusion of the code is completely allowable under the license terms. > The only question is the best way to document the inclusion to best follow > established ASF practices. My understanding is that we should: > > 1) Maintain the original copyright notices and license headers in the files. Correct. Unless you're a copyright holder or an authorized representative of one, you're not allowed to touch existing copyright notices in files. > 2) In the cases that we've made non-trivial changes to the source, we > should additionally add the ASF copyright notice at the top of the file, > and amend the original copyright statement with the words "Some portions" > as we've done for example in cache.cc[7]. I don't think you need to do that, but you do need an ASF license header. I don't think ASF encourages "Portions Copyright ... ASF" statements on individual files. > 3) In all files (regardless of whether we've made changes), we should add > the Apache license header above any existing license headers, while > maintaining the existing one. Correct and it should also solve #2 > 4) In the LICENSE file, we should make note of the included code and its > copyrights as we have done here[8]. I tend to be in the camp that values simplicity of LICENSE file. IOW, this need to be a succinct communication of what an overall license for the source bundle is and that's ALv2. You do need to update NOTICE files accordingly though. Thanks, Roman. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
File headers for third party utility code
Hi all, I'm working on verifying licenses and copyrights, etc, in Apache Kudu (incubating). There is one area I wanted to confirm the right way to document in our LICENSE/NOTICE files: Kudu makes use of a lot of open source utility code borrowed from (or adapted from) other open source projects. In particular, we've borrowed a lot of code from Chromium's "base" module[1] which is licensed under a BSD 3-clause license[2]. We also have some code from Google Supersonic[3] licensed under the Apache License[4]. The majority of this borrowed code is under a 'gutil' directory in the Kudu tree[5]. We also have some small amounts of code borrowed from LevelDB under the BSD license[6]. Given that all of the borrowed code is under the Apache or BSD licenses, the inclusion of the code is completely allowable under the license terms. The only question is the best way to document the inclusion to best follow established ASF practices. My understanding is that we should: 1) Maintain the original copyright notices and license headers in the files. 2) In the cases that we've made non-trivial changes to the source, we should additionally add the ASF copyright notice at the top of the file, and amend the original copyright statement with the words "Some portions" as we've done for example in cache.cc[7]. 3) In all files (regardless of whether we've made changes), we should add the Apache license header above any existing license headers, while maintaining the existing one. 4) In the LICENSE file, we should make note of the included code and its copyrights as we have done here[8]. I'm aware that there is a notion that Apache projects should ask for permission to borrow code rather than forking communities. However, this is all very generic utility code with no standalone project community or releases. In fact, many of these files can already be found copy-pasted into many different open source projects beyond just Chromium or LevelDB. So, I don't think there are any viable alternatives to copy-pasting. Thanks -Todd [1] https://chromium.googlesource.com/chromium/src/base/+/master/ [2] https://chromium.googlesource.com/chromium/src/+/master/LICENSE [3] https://github.com/google/supersonic [4] https://github.com/google/supersonic/blob/master/LICENSE [5] https://github.com/cloudera/kudu/tree/master/src/kudu/gutil [6] https://github.com/google/leveldb/blob/master/LICENSE [7] https://github.com/cloudera/kudu/blob/master/src/kudu/util/cache.cc#L15 [8] https://github.com/cloudera/kudu/blob/master/LICENSE.txt#L205
[VOTE] Release Apache Trafodion (incubating) 1.3.0-incubating
Hello, The Apache Trafodion community has voted on and approved its first release – Apache Trafodion 1.3.0 –incubating (release candidate 5) Vote request on dev list: http://mail-archives.apache.org/mod_mbox/incubator-trafodion-dev/201512.mbox/ajax/%3C835f19bc6267f402358a71221c2b6afc%40mail.gmail.com%3E Vote result on dev list: http://mail-archives.apache.org/mod_mbox/incubator-trafodion-dev/201601.mbox/ajax/%3Cf41e5961dcf6f0d0d86ee766a6a93833%40mail.gmail.com%3E The commit id is 6ae976fdc60a683e954d867dab6ff30c55146c8f which corresponds to tag 1.3.0rc5: https://git-wip-us.apache.org/repos/asf?p=incubator-trafodion.git;a=tag;h=5af956f989f1f32664bbec768e4f354516daa96b The release artifacts can be downloaded from: https://dist.apache.org/repos/dist/dev/incubator/trafodion/apache-trafodion-1.3.0-incubating Instructions on how to build and run Apache Trafodion are described here: http://trafodion.apache.org/download.html The source tar file has been signed with pgp key A44C5A05 which is included in the download location’s KEYS file: https://dist.apache.org/repos/dist/dev/incubator/trafodion/KEYS For changes included in the release, please see the release notes: http://trafodion.apache.org/release-notes-1-3-0.html The RAT tool was run on the source and the excluded are defined in the RAT_README.txt file found in the top level source directory. The following is a list of issues found during the podling review. It was determined that these issues can be fixed in a subsequent release, Jira’s, as noted, were created for each issue. TRAFODION-1733: Incorrect information included in LICENSE file The Facebook copyright is already Apache and does not need to be in the LICENSE file Asciidocs is included but not used TRAFODION-1725: missing licenses for: MooTools Framework MIT licensed Copyright Valerio Proietti swscanf.cpp/swprintf.cpp BSD license copyright Chris Torek JQuery files - JQuery Foundation, Inc TRAFODION-1734: Suggestions for licensing improvements: Should specify the type of license in the LICENSE file instead of requiring a lookup in the corresponding license text. Should copy all license text to Apache Trafodion instead of specifying an external link. The external license could change. TRAFODION-1735: There was a concern that changes made to some of the BSD copyrighted files were more than minor so additional copyright information may be required. Pursuant to the Release section of the Incubation Policy and with the endorsement of our mentors we would now like to request the permission of the Incubator PMC to publish the release. The vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Regards, Roberta Marton
[VOTE] Apache Slider (incubating) release 0.90.2-incubating
Hello, This is a call for a vote on the Apache Slider (incubating) release 0.90.2-incubating. This release candidate, 0.90.2-incubating-RC1 has successfully passed a vote for a release on the slider developer mailing list. Vote thread: http://mail-archives.apache.org/mod_mbox/incubator-slider-dev/201505.mbox/%3CD17220E0.D0AD%25gsaha%40hortonworks.com%3E Results: http://mail-archives.apache.org/mod_mbox/incubator-slider-dev/201505.mbox/%3CD177A7D8.D521%25gsaha%40hortonworks.com%3E Issues fixed: https://issues.apache.org/jira/browse/SLIDER/fixforversion/12334370/ Release Notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315422&version=12334370 Source artifacts: https://dist.apache.org/repos/dist/release/incubator/slider/0.90.2-incubating-RC1 Staged artifacts: https://repository.apache.org/content/repositories/orgapacheslider-1013/ Git source: https://git-wip-us.apache.org/repos/asf?p=incubator-slider.git;a=commit;h=9bb379f83c78b61aeb4110b93796bc02c08c4226 Git commit SHA1: 9bb379f83c78b61aeb4110b93796bc02c08c4226 PGP key: http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=ste...@apache.org Please vote on releasing this package as Apache Slider 0.90.2-incubating: This vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) stevel on behalf of the Apache Slider (incubating) team - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Permission to edit incubator wiki / Jan2016 status?
On Mon, Jan 4, 2016 at 10:07 AM, Aaron D. Mihalik wrote: > All, > > I wanted to post the update for Rya for Jan 2016, but I don't have > permissions to edit the wiki. > > I created a new user (aaronmihalik). Can you give me permissions? Done. Looking forward to the report! Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Permission to edit incubator wiki / Jan2016 status?
All, I wanted to post the update for Rya for Jan 2016, but I don't have permissions to edit the wiki. I created a new user (aaronmihalik). Can you give me permissions? Thanks, Aaron
Re: [VOTE] Apache Wave Release 0.4.0-incubating (RC10)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello,
No issues. I have now managed to compile it with no problems on Ubuntu
14.04. (Thanks for the reminder :) )
+1
Cheers,
Ian
On 29/12/2015 08:02, Yuri Z wrote:
> Hi Ian Are there any more issues that hold you from voting on the
> Apache Wave release on general@apache?
>
> On Sat, Nov 7, 2015 at 3:25 AM Ali Lown wrote:
>
>> Hi Ian,
>>
>> I am not sure about the best way to import this into eclipse, I
>> have always used the CLI tools directly. I have CC'd the dev-list
>> in case they have a better answer for you.
>>
>> The inability to find ${build.classpath.path},
>> ${build.macros.path} suggests that you are
>> missing/failed-to-import/failed-to-reference the build.properties
>> file which contains the values for these macros.
>>
>> The follow-up problem about missing define-gxpc is to be
>> expected because of the above problem resulting in it not
>> importing build-macros.xml, which defines "define-gxpc" amongst
>> other things.
>>
>> Ali
>>
>> On 6 November 2015 at 14:51, Ian Dunlop
>> wrote:
> Hello,
>
> I'll give it at 0 the moment since I encountered a build issue. I
> downloaded the src zip and imported the code into Eclipse Mars
> (4.50) with jdk 1.7.0_79 & ANT 1.9.4 but found the following
> issues:
>
> 1) BUILD FAILED C:\Users\idunlop\workspace\waveinabox\build.xml:28:
> Cannot find
> C:\Users\idunlop\workspace\waveinabox\${build.classpath.path}
> imported from C:\Users\idunlop\workspace\waveinabox\build.xml
>
> Resolved by commenting out
>
>
>
>
>
> and tried again
>
> 2)
>
> BUILD FAILED Target "define-gxpc" does not exist in the project
> "waveinabox". It is used from target "gen-gxp".
>
> Resolved by removing define-gxpc from
>
> depends="init, define-gxpc, gen-gxp-dep" unless="skip.gen-gxp">
> destdir="${gen.dir}/gxp" target="org.waveprotocol.box.server.gxp"
> />
>
> 3)
>
> BUILD FAILED C:\Users\idunlop\workspace\waveinabox\build.xml:120:
> Problem: failed to create task or type buildproto Cause: The name
> is undefined. Action: Check the spelling. Action: Check that any
> custom tasks/types have been declared. Action: Check that any
> / declarations have taken place.
>
> At that point I figured it best to report the issues here:
>
> Is there a procedure for building in eclipse, am I missing an ant
> setting somewhere?
>
> So, apart fromn the compile issue everything else looks good:
>
> signatures are good artifact/hashes good DISCLAIMER OK LICENCE OK
> NOTICE OK
>
> Cheers,
>
> Ian
>
>
>
> On 04/11/2015 07:14, Justin Mclean wrote:
> Hi,
>
> +1 binding.
>
> Could you please fix the LICENCE Appendix in the next
> release. The text should be "Copyright [] [name of
> copyright owner]” not "Copyright 2013 The Apache Software
> Foundation”.
>
> I checked: - artefact has incubating in name - signatures
> and hashes good - DISCLAIMER exists - LICENSE has minor
> issue with the copyright in the appendix. Not required but
> it could also use the sort form in LICENSE [1] particularly
> as you bundle the software LICENSE files. - NOTICE good. -
> All source files have Apache headers - No unexpected binary
> file in source release (but see below) - can compile from
> source - test pass
>
> I notice there’s a couple of photographs in the source
> release, I assume you have permission from the person who
> took them to use these? IF so you may want to put that in
> the LICENSE.
>
> There's a number of binary file without extensions in
> /thumbnail_patterns/ but they all look to be PNGs is this
> the case? Where did these images come from?
>
> I had a quick look at the binary release and the LICENCE
> and NOTICE appear comprehensive. I didn;t do a though
> check. I did notice that the year is incorrect in the
> NOTICE file and LICENSE appendix has the same issue. It’s
> actually wrong here as non ASF Apache licensed software is
> mentioned. There no need to mean Apache licensed software
> in the LICENCE but no harm is done by donning so. [2]
>
> Thanks, Justin
>
> 1.
> http://www.apache.org/dev/licensing-howto.html#permissive-deps
>
>
2. http://www.apache.org/dev/licensing-howto.html#alv2-dep
>
>
>
> --
- ---
>
>
>
>
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail:
> general-h...@incubator.apache.org
>
>
>>>
>>>
- -
>>>
>>>
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail:
>>> general-h...@incubator.apache.org
>>>
>>
>
- --
Ian Dunlop, eScience Lab
School of Computer Science
The University of Manchester
http://orcid.org/-0001-7066-3350
