Reverting my vote [was: Re: [VOTE] 2.0.57 candidate]
On Apr 20, 2006, at 3:34 PM, Sander Temme wrote: +1 for release on Ubuntu/x86, FreeBSD 6-STABLE/x86, Darwin/PPC. Sorry, I think we should re-roll with the reverted copyright statements. Since the code is the same and no one reported any technical problems, the new vote should be pretty swift. -1 for release. S. -- [EMAIL PROTECTED]http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] 2.0.57 candidate
On Fri, Apr 21, 2006 at 10:31:25PM -0500, William A. Rowe, Jr. wrote: Appears to be Colm's choice of 1. nothing extra, 2. revert date changes/reroll, or 3. revert date changes (w/ any other changes he wishes), bump and reroll. That's my preference, in descending order, but support whichever he chooses. My preference is similar, I'd prefer to ship 2.0.57 as it is now rather than either confuse the whole process by introducing another candidate. So, unless people revert their votes for release, we can release the present candidate very shortly after 2.2.2. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [VOTE] 2.0.57 candidate
Colm MacCarthaigh wrote: My preference is similar, I'd prefer to ship 2.0.57 as it is now rather than either confuse the whole process by introducing another candidate. So, unless people revert their votes for release, we can release the present candidate very shortly after 2.2.2. Something occured to me Friday, but the very late date of Jim's proposed 1.3.35 tarball makes this possibly unrealistic... wouldn't it make more sense only to broadcast a single Announcement message (perhaps, next friday) to make it completely clear to the outside communities when 2.2.2 is released, that there are updates to 2.0.57 and 1.3.35 for users of this legacy software? Roy's framed the question (paraphrasing) why the heck continue to release 2.0 versions? Long answer, as long as it gets votes/attention from the community, but my personal answer is whenever 2.2.x is what we say it is, the best version available. The moment the bugtraq system and user reports clearly document that 2.2.x is 'as stable' as 2.0.x, I'm all for mostly dumping it. I'd also like to see us dump 1.3 in the not-so-distant future, but again, it's all about how long those stable releases have communities. Bill
Re: [VOTE] 2.0.57 candidate
Passes perl test framework and others on: Sol8/Sparc, OS X 10.4.6, Suse 9.2, Suse 10.0 +1 On Apr 19, 2006, at 12:59 PM, Colm MacCarthaigh wrote: Candidate tarballs for 2.0.57 are now available for testing/voting at; http://httpd.apache.org/dev/dist/ This doesn't include a changed notice-of-license text though, which is a potential open issue. -- Colm MacCárthaighPublic Key: colm [EMAIL PROTECTED]
Re: [VOTE] 2.0.57 candidate
-Ursprüngliche Nachricht- Von: Plüm, Rüdiger, Also +1 (compiled and started) on Solaris 8, gcc 3.3.2 Solaris 9, gcc 3.3.2 Forgot to mention: Both Solaris SPARC Regards Rüdiger
Re: [VOTE] 2.0.57 candidate
Like in 2.0.55 it builds not mod_deflate with zlib 1.2.3 , its complaining that some files are not found, like srclib\zlib\infblock.h , srclib\zlib\infcodes.h, srclib\zlib\infutil.h. There is a patch for mod_deflate 2.053 at http://smithii.com/files/httpd-2.0.54_zlib-1.2.2.patch (did not tried that one). Steffen
Re: [VOTE] 2.0.57 candidate
On 4/19/2006 at 10:59:48 am, in message [EMAIL PROTECTED], Colm MacCarthaigh [EMAIL PROTECTED] wrote: Candidate tarballs for 2.0.57 are now available for testing/voting at; http://httpd.apache.org/dev/dist/ This doesn't include a changed notice-of-license text though, which is a potential open issue. +1 NetWare Brad
Re: [VOTE] 2.0.57 candidate
On 4/19/06, Colm MacCarthaigh [EMAIL PROTECTED] wrote: Candidate tarballs for 2.0.57 are now available for testing/voting at; http://httpd.apache.org/dev/dist/ This doesn't include a changed notice-of-license text though, which is a potential open issue. I'm -1 due to the copyright notice changes. A bunch of files magically added years to copyright notices (i.e. from -2004 to -2006) when those files didn't actually substantively change during that period. That's a no-no. Let's just add Jackrabbit's disclaimer and be done with the whole year thing forever. The best thing of course would be to not have done anything at all (g); but that train left the station when all of those commits got made prematurely... -- justin
Re: [VOTE] 2.0.57 candidate
Justin Erenkrantz wrote: On 4/19/06, Colm MacCarthaigh [EMAIL PROTECTED] wrote: Candidate tarballs for 2.0.57 are now available for testing/voting at; http://httpd.apache.org/dev/dist/ This doesn't include a changed notice-of-license text though, which is a potential open issue. I'm -1 due to the copyright notice changes. A bunch of files magically added years to copyright notices (i.e. from -2004 to -2006) when those files didn't actually substantively change during that period. That's a no-no. You know, this is hardly the first time we've done that... Yes, it's been awhile since we made those unilateral changes, but by the above standards, what we had even before wasn't really correct, since those had changed copyrights on files that hadn't substantially changed as well. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: [VOTE] 2.0.57 candidate
On Fri, Apr 21, 2006 at 10:21:18AM -0700, Justin Erenkrantz wrote: I'm -1 due to the copyright notice changes. A bunch of files magically added years to copyright notices (i.e. from -2004 to -2006) when those files didn't actually substantively change during that period. That's a no-no. We know that now, but those commits went through before it became so clear that our previous practise was so wrong. Let's just add Jackrabbit's disclaimer and be done with the whole year thing forever. The best thing of course would be to not have done anything at all (g); but that train left the station when all of those commits got made prematurely... o.k., I think we can change the notice without a version bump too and without erasing the existing votes, since it's a non-code change, but we should probably have a clear vote on changing the notice, I'll start one now :) -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [VOTE] 2.0.57 candidate
On Apr 21, 2006, at 10:21 AM, Justin Erenkrantz wrote: Let's just add Jackrabbit's disclaimer and be done with the whole year thing forever. The best thing of course would be to not have done anything at all (g); but that train left the station when all of those commits got made prematurely... -- justin Can't we just revert that commit? S. smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] 2.0.57 candidate
On 4/21/06, Colm MacCarthaigh [EMAIL PROTECTED] wrote: We know that now, but those commits went through before it became so clear that our previous practise was so wrong. The entire email exchange happened while the US West Coasters were asleep. I sent an email saying, Don't do that as soon as I saw the thread the next morning. But, the commits had already been made by then based on false conceptions about what our practice was. Let's just add Jackrabbit's disclaimer and be done with the whole year thing forever. The best thing of course would be to not have done anything at all (g); but that train left the station when all of those commits got made prematurely... o.k., I think we can change the notice without a version bump too and without erasing the existing votes, since it's a non-code change, but we should probably have a clear vote on changing the notice, I'll start one now :) We should probably do a version bump, but at a minimum, the votes do go away. *shrug* -- justin
Re: [VOTE] 2.0.57 candidate
On 4/21/06, Jim Jagielski [EMAIL PROTECTED] wrote: You know, this is hardly the first time we've done that... Yes, it's been awhile since we made those unilateral changes, but by the above standards, what we had even before wasn't really correct, since those had changed copyrights on files that hadn't substantially changed as well. It matters that we've now said on a public list that we know the notices are incorrect. Before, we actually believed that those changes were right. That's a huge difference. -- justin
Re: [VOTE] 2.0.57 candidate
Justin Erenkrantz wrote: On 4/19/06, Colm MacCarthaigh [EMAIL PROTECTED] wrote: Candidate tarballs for 2.0.57 are now available for testing/voting at; http://httpd.apache.org/dev/dist/ This doesn't include a changed notice-of-license text though, which is a potential open issue. I'm -1 due to the copyright notice changes. A bunch of files magically added years to copyright notices (i.e. from -2004 to -2006) when those files didn't actually substantively change during that period. That's a no-no. How is this a showstopper? As has been pointed out, your comments are late to the table, and this certainly isn't a change in existing practice, and most certainly doesn't invalidate the (initial and appropriate) copyrights. -1 to adopting Jackrabbits' license until Roy's (very reasonable) nit on the language is addressed. -1 to removing copyright until we have an absolute, documented policy from ASF legal. I'm glad you and Roy feel entirely assured that you speak for legal/privy to its workings and, of course, its final conclusions. For the sanity of all the rest of us project members, let us please work from documented policy though, can we? And feh - let's just have done with this tarball release and revisit once policy is *set*. I don't concur with Colm, the tarball is the release and changing the legal text is more significant, perhaps, than even the code itself. So it's yet another bump that strikes me as silly. Bill
Re: [VOTE] 2.0.57 candidate
On Fri, Apr 21, 2006 at 12:39:12PM -0500, William A. Rowe, Jr. wrote: I don't concur with Colm, the tarball is the release and changing the legal text is more significant, perhaps, than even the code itself. So it's yet another bump that strikes me as silly. Just to be clear, I didn't mean it that way. I was going to start an explicit vote on the mailing list for changing the notice-of-license text, accross all branches and future releases, for the sake of efficiency and clarity. But in the last few minutes even more options have emerged that make me question if it's that's sensible, as there's no consensus on what options to vote on. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [VOTE] 2.0.57 candidate
Justin Erenkrantz wrote: It matters that we've now said on a public list that we know the notices are incorrect. Before, we actually believed that those changes were right. That's a huge difference. -- justin You've said so. Roy's said so. Colm said it's irrelevant. I've seen no statement by the ASF (board of directors, VP legal affairs) so it's well written, stylishly composed hot air until the ASF asserts an explicit policy.
Re: [VOTE] 2.0.57 candidate
On 4/21/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: How is this a showstopper? As has been pointed out, your comments are late to the table, and this certainly isn't a change in existing practice, and most certainly doesn't invalidate the (initial and appropriate) copyrights. Bah. I posted my complaint against changing the years within 12 hours of your initial post. We can not make statements in the code that we know to be inaccurate. Once you decided to open this can of worms, we must resolve it before publishing a release. -- justin
Re: [VOTE] 2.0.57 candidate
Justin Erenkrantz wrote: On 4/21/06, Jim Jagielski [EMAIL PROTECTED] wrote: You know, this is hardly the first time we've done that... Yes, it's been awhile since we made those unilateral changes, but by the above standards, what we had even before wasn't really correct, since those had changed copyrights on files that hadn't substantially changed as well. It matters that we've now said on a public list that we know the notices are incorrect. Before, we actually believed that those changes were right. That's a huge difference. -- justin So does this mean that no ASF project can release any code until we get this resolved *and* that they all incorporate those changes to fix the copyright notice changes? I'm not being a pain, I'm really curious. If so, then that's a major thing and (1) we better be fully sure, and actually have real legal advice on it and (2) inform the PMCs. If the issue is that we know that the copyright notices may have issues, then that's a universal concern, with all projects, since I'm pretty confident that they have all done substantially the same thing. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: [VOTE] 2.0.57 candidate
On Fri, Apr 21, 2006 at 12:51:19PM -0500, William A. Rowe, Jr. wrote: Justin Erenkrantz wrote: It matters that we've now said on a public list that we know the notices are incorrect. Before, we actually believed that those changes were right. That's a huge difference. -- justin You've said so. Roy's said so. Colm said it's irrelevant. I've seen no statement by the ASF (board of directors, VP legal affairs) so it's well written, stylishly composed hot air until the ASF asserts an explicit policy. O.k., I'll try and give some background, IANAL and I'm just trying to fill in, based on my own understanding here. Justin is entirely correct that we shouldn't be saying Copyright N-2006 where those files lack significant changes within the latter year. This is fraud, and us knowing about it makes it willful fraud which a) can have an effect on damages in some jurisdictions, b) harms our credibility, both in the context of any related legal cases and just in general. However the nature of the fraud isn't exactly a big deal from a risk-assessment point of view. Because it's very hard to identify any harm caused by the error. After all, we publish the code under a very liberal license. In theory, in about 60 years time, someone could argue that we deprived them of the correct notice as to when they could start using the code in non-ASL compliant ways, but could they really show that they had made any effort to mitigate the problem? After all, there's already published voluminous discussion about it in the list archive? So really, what it does boil down to is the PR/credibility aspect of it. For starters, if the ASF ever did have a case in the IP law area (not all unlikely), they opposing side can point to things like this and use it to create an impression of general sloppiness and use it as supporting evidence of a kind. In the public arena, well it just looks bad to knowlingly mess things up. So, that's why it's important that it be fixed, and presumably why the ASF legal team are working on it. So, I think our real options are; 's/-//' and simply delete the latter year entirely. This is minimal change, but assumes that I actually have a clue here and get what the legal issue is. And this hasn't been approved by ASF legal. Migrate to the jackrabbit notice, because at least it has been approved and we judge the inconvience of seemingly slightly adversarial to users less bad than the inconvience of having less credibility in legal matters. Personally, I'd prefer the latter, though I'm also entirely happy to live with the risk/credibility issue of the existing text, this really is hair-splitting hypotheticial territory. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: [VOTE] 2.0.57 candidate
Colm MacCarthaigh wrote: So, I think our real options are; 's/-//' and simply delete the latter year entirely. This is minimal change, but assumes that I actually have a clue here and get what the legal issue is. And this hasn't been approved by ASF legal. Migrate to the jackrabbit notice, because at least it has been approved and we judge the inconvience of seemingly slightly adversarial to users less bad than the inconvience of having less credibility in legal matters. Personally, I'd prefer the latter, though I'm also entirely happy to live with the risk/credibility issue of the existing text, this really is hair-splitting hypotheticial territory. If the latter has full approval from our true legal team, then I'm ++1 for handling is right now and being done with it. As mentioned before, this should be a universal ASF change, not just httpd. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ If you can dodge a wrench, you can dodge a ball.
Re: [VOTE] 2.0.57 candidate
Jim Jagielski wrote: So does this mean that no ASF project can release any code until we get this resolved *and* that they all incorporate those changes to fix the copyright notice changes? I'm not being a pain, I'm really curious. If so, then that's a major thing and (1) we better be fully sure, and actually have real legal advice on it and (2) inform the PMCs. Ya that's my question, there are votes pending in lots of projects. httpd is not unique here. I'm _happy_ to follow *any* policy, if one exists. Failing that, it's back to best practices/past procedure. The last thread I remembered on the issue is 'don't bump copyrights on files which are untouched' and so - we followed that policy. Short of a full hold on all releases originating with your /board hat on to committers@, I consider this whole thread overblown and your arguement against (specifically) 2.0.57 irrelevant. I really have no problem if Cliff posts to the list telling us It is not necessary to update copyright dates - and if he does that, we will revert before rolling 2.2.0. Bill
Re: [VOTE] 2.0.57 candidate
On 4/21/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: I really have no problem if Cliff posts to the list telling us It is not necessary to update copyright dates - and if he does that, we will revert before rolling 2.2.0. http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200601.mbox/[EMAIL PROTECTED] Feel free to read the whole thread. It has Cliff and Roy giving the same answer: Don't update copyright years. -- justin
Re: [VOTE] 2.0.57 candidate
Jim Jagielski wrote: Colm MacCarthaigh wrote: Migrate to the jackrabbit notice, because at least it has been approved and we judge the inconvience of seemingly slightly adversarial to users less bad than the inconvience of having less credibility in legal matters. If the latter has full approval from our true legal team, then I'm ++1 for handling is right now and being done with it. As mentioned before, this should be a universal ASF change, not just httpd. This just isn't making sense as I read the svn tree for jackrabbit however. Individual files contain -no- copyright, -no- indicication of where the copyright claim is http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit/src/main/java/org/apache/jackrabbit/ has JcrConstants.java pointing to http://www.apache.org/licenses/LICENSE-2.0 and claiming the license but no copyright. That LICENSE.txt is bundled in the tree (not, you'll note, LICENSE-2.0) at that level. NOTICE.txt tells us... This product includes software developed by The Apache Software Foundation (http://www.apache.org/). Based on source code originally developed by Day Software (http://www.day.com/). which is all well and good, but doesn't assert copyrights. It's not until you climb all the way up to http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit/ (outside of even the src/ tree!) that you discover... http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit/README.txt = Welcome to Apache Jackrabbit http://jackrabbit.apache.org/ = License (see also LICENSE.txt) == Collective work: Copyright 2006 The Apache Software Foundation. Licensed under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. [more chewy README.txt goodness] I'm really completely unclear how this protects the files we author, the files authored by others (which we have appropriately appropriated) and the files on which no copyright is claimed (e.g. apr/ examples public domain.)
License text in source files [Re: [VOTE] 2.0.57 candidate]
On Apr 21, 2006, at 10:51 AM, Justin Erenkrantz wrote: We can not make statements in the code that we know to be inaccurate. Once you decided to open this can of worms, we must resolve it before publishing a release. -- justin So, basically, we're dead in the water until we develop and apply the appropriate license text? That means no releases can be made on any branch until this issue is resolved? Or would we be OK with: a) reverting the mass change (r395235 on 2.0.x, r395231 on 2.2.x, r395229, r395228 on trunk, looks like Jim already took care of 1.3, what am I missing?) b) Dredge svn for files updated during the current year and change the notice accordingly c) Re-roll ? That would get us moving forward again. We can then wait for guidance from the board/legal. S. smime.p7s Description: S/MIME cryptographic signature
Copyright Dates (Was: Re: [VOTE] 2.0.57 candidate)
As I read it, yes it appears that even just changing the last date does not make sense. For example assuming a valid 1999-2004 and the file is updated in 2006, 1999-2006 would not be correct, if I understand it, but instead 1999-2004,2006 would be more correct... I think :) In any case, I reverted the 1.3-related patch and will hold off releasing 1.3.35 until this is resolved. This should be added (if not already) to next week's board meeting since it's a policy change that all projects should adhere to (the Jackrabbit method)...
Re: [VOTE] 2.0.57 candidate
Justin Erenkrantz wrote: On 4/21/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: I really have no problem if Cliff posts to the list telling us It is not necessary to update copyright dates - and if he does that, we will revert before rolling 2.2.0. Feel free to read the whole thread. It has Cliff and Roy giving the same answer: Don't update copyright years. -- justin That is not what Cliff says http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200601.mbox/[EMAIL PROTECTED] you should only update the year when some substantial addition is made to the work. For instance, adding or rewriting a method/function would sound to me like new copyrightable expression; but, changing the value of a constant or renaming something would not likely be protected under copyright law. Does httpd 1.3.x justify a collected-works bump to 2006? I doubt it (a few few-line patches). Does httpd 2.0.x justify one? More likely, but still debatable. Does 2.2.x? I'd think so (major code fixes in proxy handling etc.) Does trunk? Certainly, some major rewrites in that code. You are right that we don't update *all* the copyrights, nobody debated that. We had a simple (too simple) search of touched files to refresh copyright, and I have no issue if we should undo that and selectively update copyrights on the significantly changed elements of the work. Consider new doc pages, where even a new paragraph is substantial enough, but touching the formatting/xml tags is irrelevant. We are so far from 'solving' this it's absurd. But please don't claim that Cliff stated copyrights are never updated. Only that they should be selectively updated based on real changes to content, e.g. not spelling corrections in docs, nor trivial bug fixes in code.
Re: Copyright Dates (Was: Re: [VOTE] 2.0.57 candidate)
On 4/21/06, Martin Cooper [EMAIL PROTECTED] wrote: You are correct. Only the years in which the file was actually changed should be listed in the copyright. If we want to get pedantic, it should only be year of first publication. ;-) For reference, here's Larry Rosen's post to legal-discuss@ on the form of copyright notice: http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200503.mbox/[EMAIL PROTECTED] (There are some other things in that post that are policy issues instead of legal issues - which is where we tend to get diverging opinions; but Larry's description of the form of notice is accurate.) HTH. -- justin
Re: [VOTE] 2.0.57 candidate
On 4/21/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: You are right that we don't update *all* the copyrights, nobody debated that. We had a simple (too simple) search of touched files to refresh copyright, and I have no issue if we should undo that and selectively update copyrights on the significantly changed elements of the work. Good - because that's all that I based my -1 on for 2.0.57. -- justin
Re: [VOTE] 2.0.57 candidate
On Fri, Apr 21, 2006 at 01:46:21PM -0500, William A. Rowe, Jr. wrote: which is all well and good, but doesn't assert copyrights. And that's fine, there is no need to assert a copyright :) I'm really completely unclear how this protects the files we author, the files authored by others (which we have appropriately appropriated) and the files on which no copyright is claimed (e.g. apr/ examples public domain.) A line such as Copyright Colm MacCarthaigh gives me no protection copyright didn't already afford me in the absense of that line. The only thing it does do is serve as a courtesy to potential licensees letting them know who to contact if they wish to license the work. It's an advertisement. At a stretch, the inclusion of the line might allow you to argue the Wow you must be really dumb not to have seen the copyright notice argument, but that wouldn't hold much weight, since if it were absent there would still be an assumption of copyright. A line such as Copyright 2004-2006 Colm MacCarthaigh serves as a courtesy to the world, letting them figure out when the copyright will expire. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: Copyright Dates (Was: Re: [VOTE] 2.0.57 candidate)
Justin Erenkrantz wrote: On 4/21/06, Martin Cooper [EMAIL PROTECTED] wrote: You are correct. Only the years in which the file was actually changed should be listed in the copyright. If we want to get pedantic, it should only be year of first publication. ;-) Yes. What is publication? When we release a major update of the code, that's a new publication (e.g. if the work is rewritten, as 2.0 was from 1.3, then it's a single copyright date of the new 2.0 work.) If we adopt the 'publication' of an ASF work as it's release (collective) than this whole mumbo jumbo goes away. The date is the release date of the work, e.g. the date we released 2.0 GA. For 2.2? I don't know if that's a work or an incremental change to 2.0. It would certainly save much grief only to coordinate copyright when the work is tagged from trunk/ to a branch/ and released the first time. For reference, here's Larry Rosen's post to legal-discuss@ on the form of copyright notice: http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200503.mbox/[EMAIL PROTECTED] Which contradicts the implemetation adopted by Jackrabbit (recently endorsed as our model?) We assert our license in every file, yet Larry's post indicates that is overkill. We fail to assert our copyright in the Jackrabbit src/ tree. (Although Larry's post suggests a copyright on the web site download page is enough - which gets interesting on copyright dates since what date would you brand the page http://www.apache.org/dist/httpd/ ?). Larry is clear that it's the copyright that binds the license, not the license that binds the copyright, so asserting a license where you don't assert a copyright seems oddish. E.g. it doesn't matter if we give you one license, or 100, if we've told you the file is copyrighted - you can only use it with our permission (the license.)
Re: [VOTE] 2.0.57 candidate
Justin Erenkrantz wrote: On 4/21/06, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: You are right that we don't update *all* the copyrights, nobody debated that. We had a simple (too simple) search of touched files to refresh copyright, and I have no issue if we should undo that and selectively update copyrights on the significantly changed elements of the work. Good - because that's all that I based my -1 on for 2.0.57. -- justin And the weight of this issue doesn't even merit reconsidering a reroll for 2.0.57 tarball given the host of other copyright/license issues raised in this thread. So I'm asking you directly, is this a vote -1 for release? Or are you vetoing the copyright commit to 2.0.57? The distinction is important for the RM to consider.
Re: [VOTE] 2.0.57 candidate
On Apr 21, 2006, at 10:39 AM, William A. Rowe, Jr. wrote: -1 to adopting Jackrabbits' license until Roy's (very reasonable) nit on the language is addressed. -1 to removing copyright until we have an absolute, documented policy from ASF legal. I'm glad you and Roy feel entirely assured that you speak for legal/privy to its workings and, of course, its final conclusions. For the sanity of all the rest of us project members, let us please work from documented policy though, can we? And feh - let's just have done with this tarball release and revisit once policy is *set*. FTR, we are not going to vote on legal policy. The board will vote, if anyone. Legal policies are not a PMC thing. I implement them as needed or directed by the board. I don't really care about the nit (it is present in the existing header text). It is just something I noticed while implementing the changes for Jackrabbit. I don't concur with Colm, the tarball is the release and changing the legal text is more significant, perhaps, than even the code itself. So it's yet another bump that strikes me as silly. *shrug* version numbers are cheap. I thought we only required them to change if the compiled bits would change or if the release was already announced. Roy
Re: [VOTE] 2.0.57 candidate
Roy T. Fielding wrote: On Apr 21, 2006, at 10:39 AM, William A. Rowe, Jr. wrote: For the sanity of all the rest of us project members, let us please work from documented policy though, can we? And feh - let's just have done with this tarball release and revisit once policy is *set*. FTR, we are not going to vote on legal policy. The board will vote, if anyone. Legal policies are not a PMC thing. I implement them as needed or directed by the board. Ack, +1. (voting to not be voting :) I don't really care about the nit (it is present in the existing header text). It is just something I noticed while implementing the changes for Jackrabbit. +1 and thank you for the observation. I don't concur with Colm, the tarball is the release and changing the legal text is more significant, perhaps, than even the code itself. So it's yet another bump that strikes me as silly. *shrug* version numbers are cheap. I thought we only required them to change if the compiled bits would change or if the release was already announced. Thanks for clarifying your position, as you were the only one I was thinking of (still around these parts) who argued tag x.y.z - tarball x.y.z is involitile. So if this is your position, then I guess there is no reason not to retain the number, if this is what Colm wants to do. Appears to be Colm's choice of 1. nothing extra, 2. revert date changes/reroll, or 3. revert date changes (w/ any other changes he wishes), bump and reroll. That's my preference, in descending order, but support whichever he chooses. Thanks again for all the detailed comments Roy. With a Board policy in place, we stand ready to resolve this. In the interim, we can eot the subject. Cool. Bill
Re: [VOTE] 2.0.57 candidate
-Ursprüngliche Nachricht- Von: Colm MacCarthaigh Candidate tarballs for 2.0.57 are now available for testing/voting at; http://httpd.apache.org/dev/dist/ This doesn't include a changed notice-of-license text though, which is a potential open issue. Also +1 (compiled and started) on Solaris 8, gcc 3.3.2 Solaris 9, gcc 3.3.2 Regards Rüdiger
Re: [VOTE] 2.0.57 candidate
On Apr 19, 2006, at 9:59 AM, Colm MacCarthaigh wrote: Candidate tarballs for 2.0.57 are now available for testing/voting at; http://httpd.apache.org/dev/dist/ This doesn't include a changed notice-of-license text though, which is a potential open issue. Linux sarlacc 2.6.12-10-686 #1 Sat Mar 11 16:22:51 UTC 2006 i686 GNU/ Linux (Ubuntu Breezy) worker: All tests successful (1 subtest UNEXPECTEDLY SUCCEEDED), 10 tests and 12 subtests skipped. Files=75, Tests=2804, 131 wallclock secs (61.51 cusr + 7.70 csys = 69.21 CPU) prefork: All tests successful (1 subtest UNEXPECTEDLY SUCCEEDED), 10 tests and 12 subtests skipped. Files=75, Tests=2806, 131 wallclock secs (61.15 cusr + 7.98 csys = 69.13 CPU) FreeBSD bagheera.sandla.org. 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #2: Wed Mar 22 10:13:16 PST 2006 [EMAIL PROTECTED]:/ usr/obj/usr/src/sys/GENERIC i386 prefork: Hangs on test 2 of t/protocol/nntp-like. It does this for both the drop and trunk. Darwin Graymalkin.local 8.6.0 Darwin Kernel Version 8.6.0: Tue Mar 7 16:58:48 PST 2006; root:xnu-792.6.70.obj~1/RELEASE_PPC Power Macintosh powerpc PGP signatures and MD5 checksums validate for both gz and bz2 drops. prefork: All tests successful (1 subtest UNEXPECTEDLY SUCCEEDED), 10 tests and 12 subtests skipped. Files=75, Tests=2802, 273 wallclock secs (80.68 cusr + 30.37 csys = 111.05 CPU worker: All tests successful (1 subtest UNEXPECTEDLY SUCCEEDED), 10 tests and 12 subtests skipped. Files=75, Tests=2800, 313 wallclock secs (82.10 cusr + 31.01 csys = 113.11 CPU) Given that the hang on FreeBSD 6 STABLE occurs for both this drop and trunk, and the unexpected success may be a stale todo test in the t/modules/include suite: +1 for release on Ubuntu/x86, FreeBSD 6-STABLE/x86, Darwin/PPC. S. smime.p7s Description: S/MIME cryptographic signature
