Re: [RE-VOTE #3] adoption of mod_combine subproject
On Apr 3, 2012, at 9:37 PM, William A. Rowe Jr. wrote: I will absolutely not shirk my own responsibility, which in this matter, is neither the responsibility of a committer placing code at the ASF, an officer acting under the direction of the BoD, nor a a director of the ASF. Which is to say, my entire responsibility as a member of the project and the foundation consisted of bringing the concern to the chair of the project and VP Legal, and let you all have your fun. I'm done with this dialog. Cheers. I will be honest: I have no idea what this whole debate is about. From the vote within the PMC, it's clear that the consensus is to fold the code in, that we are satisfied that we are covered, IP-wise, due to Graham's iCLA on file as well as other guarantees noted in the (long) thread regarding the code submission. So what is the problem?? That someone doesn't like the result of the vote and is hoping to have it overturned, somehow?? I also fail to see how this codebase is any different from other modules which we've folded in from outside like mod_proxy_html and Paul's various heartbeat/cluster stuff which came in with hardly any debate and certainly not dragging legal into it all...
Fwd: Re: [RE-VOTE #3] adoption of mod_combine subproject
Response to Jim's post sent to legal@, with PMC-specific notes; Let's put just legal@ questions to legal and keep the rest for this list, eh? If you remain confused, I suggest you actually read the bugzilla ticket to understand how Sam confused the issue. Sam effectively concludes, after spending a month suggesting that Roy's guidance was insufficent, that (while refusing to say as much), yup, Roy was right throughout. No big surprise. I will update both apr and httpd dev pages in the coming days to clarify and the issue shouldn't come up again. Returning to PMC business; Graham, please proceed as Sam's questions on the ticket have been asked and answered and he raises no further concern. The firehose contribution is already in core, now correctly considered and with no further IP steps needed. The policy module into modules/test/ is equally ready for you to import. Sorry we didn't reach agreement on combine. Original Message Subject: Re: [RE-VOTE #3] adoption of mod_combine subproject Date: Wed, 04 Apr 2012 10:13:39 -0500 From: William A. Rowe Jr. wr...@rowe-clan.net To: legal-disc...@apache.org On 4/4/2012 7:52 AM, Jim Jagielski wrote: On Apr 3, 2012, at 9:37 PM, William A. Rowe Jr. wrote: I will absolutely not shirk my own responsibility, which in this matter, is neither the responsibility of a committer placing code at the ASF, an officer acting under the direction of the BoD, nor a a director of the ASF. Which is to say, my entire responsibility as a member of the project and the foundation consisted of bringing the concern to the chair of the project and VP Legal, and let you all have your fun. I'm done with this dialog. Cheers. I will be honest: I have no idea what this whole debate is about. From the vote within the PMC, it's clear that the consensus is to fold the code in, that we are satisfied that we are covered, IP-wise, due to Graham's iCLA on file as well as other guarantees noted in the (long) thread regarding the code submission. So what is the problem?? That someone doesn't like the result of the vote and is hoping to have it overturned, somehow?? I also fail to see how this codebase is any different from other modules which we've folded in from outside like mod_proxy_html and Paul's various heartbeat/cluster stuff which came in with hardly any debate and certainly not dragging legal into it all... In December I pointed out, owing to my own ignorance, that the submission needed to follow the incubator IP clearance process. You *agreed* with the comment somewhere along the way. Checking off that box appeared necessary to us both. There were other issues, nothing to do with legal@ which you are bringing up above, but that's all distraction from the purpose of this thread here at legal@ And then... Roy answered, No, Asked and Answered; we do not follow that *incubator* IP clearance process for new submissions authored by existing committers. The PMC simply accepts the code based on its own judgement that its own committers are correctly handling the IP concerns. And then... Of course, Sam said that legal provided no such guidance. I shoved this all back to legal-private and said figure it out, then explain it to us. Sam suggests that revised legal IP clearance requirements, as a matter of policy, across top level projects, is sufficiently described by; http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201204.mbox/%3C4F7C3832.4050509%40intertwingly.net%3E So, simply time for spring cleaning. I've asked Sam to document one specific legal policy and have gained this reference email post, and will ensure that neither the httpd.a.o or apr.a.o dev pages refer to other older, stale ip clearance policies. Certainly won't try to clean it up across the whole foundation, but at least everyone has this same email documentation to refer back to. In the meantime, on the referenced bug, there was no objection in 7 days to Graham's claim, so Graham will proceed and PMC considers this resolved and this thread is ended. As Roy argued in the first place, and Sam now finally concurs, the external IP Clearance process was never applicable to committers with icla's. One would suppose the IP Clearance process remains applicable only for multiparty or code-grant based submissions, just not for single party, author-contributed icla-based submissions. ---BeginMessage--- On 04/03/2012 10:43 PM, William A. Rowe Jr. wrote: On 4/3/2012 9:33 PM, Sam Ruby wrote: The ASF goes through great pains to ensure that (for example) every commit results in an email to a mailing list that PMC is expected to monitor. When mistakes happen (note I said when, not if), it is a failing not only of the committer but of the PMC. Every time somebody runs a RAT report and identifies a problem, that is a problem that was missed previously. Somebody committed that change. Every PMC member wasn't doing their job monitoring commits. Isolated
Re: [RE-VOTE #3] adoption of mod_combine subproject
On 3/28/2012 6:04 PM, Daniel Shahaf wrote: Guys. You were asked a boolean question. I'm pretty sure it was intended to be taken literally. Have you considered just answering it? I believe that you meant to direct this to Graham and cc me, and not visa versa, since I don't have such an answer. I also believe he did so (you might also refer to the bugzilla ticket Sam hasn't replied to yet). https://issues.apache.org/bugzilla/show_bug.cgi?id=52322 I had a question; Roy introduced a claim that he had, back in the day, confirmed with legal that the process is not applicable for contributions authored by committers, and some other contexts. The IP Intake Process (as comfortable as a visit to the Gastroenterologist) needs to be reclaimed by the *legal committee* which has that charge across all PMCs (incubator included), and taken off the hands of the Incubator committee which isn't given jurisdiction over TLPs. That Incubator documentation seems to be inconsistent with the prerequisites as defined by Sam. My question, where is the handling of large code submissions to existing top level projects documented, to satisfy the concerns of legal@? Please reclaim and refine. Are the TLPs accountable to Incubator guidance? I don't see where that was assigned. Thanks for giving some thought to the bigger picture, Daniel and team.
Re: [RE-VOTE #3] adoption of mod_combine subproject
William A. Rowe Jr. wrote on Tue, Apr 03, 2012 at 13:16:22 -0500: On 3/28/2012 6:04 PM, Daniel Shahaf wrote: Guys. You were asked a boolean question. I'm pretty sure it was intended to be taken literally. Have you considered just answering it? I believe that you meant to direct this to Graham and cc me, and not visa versa, since I don't have such an answer. Don't pay too much attention to the To/Cc. Sometimes I just press Reply all and go with the default partitioning. I also believe he did so (you might also refer to the bugzilla ticket Sam hasn't replied to yet). https://issues.apache.org/bugzilla/show_bug.cgi?id=52322 Thanks for the pointer -- I only read the legal-discuss@ thread, not the ticket.
Re: [RE-VOTE #3] adoption of mod_combine subproject
On 4/3/2012 2:01 PM, Daniel Shahaf wrote: William A. Rowe Jr. wrote on Tue, Apr 03, 2012 at 13:16:22 -0500: I also believe he did so (you might also refer to the bugzilla ticket Sam hasn't replied to yet). https://issues.apache.org/bugzilla/show_bug.cgi?id=52322 Thanks for the pointer -- I only read the legal-discuss@ thread, not the ticket. As Sam pointed out, individual ticket assignments to the VP Infra will not be scalable. Sam's prime weakness is an aversion to delegation. So we fall again down the rabbit hole. I brought the matter to legal-internal with a statement Roy asserts... and a request Just fix it in respect to policy, or we will presume Roy is correct. I'm afraid this may have been misinterpreted as a request to cast judgement on a specific case, when there was no such request. No specific case review was requested. Policy review was requested. Sam's response now appears to be, [liberally paraphrasing] If it adheres to the terms and conditions and is offered in good faith under those terms of the Individual Contributor License Agreement and the Apache License 2.0, by a committer, their employer and any other assigns to that copyright and relevant patents, and the committer asserts this is true, then the PMC must be the one to make that judgement call. Which is what Roy argued this entire time and seems awfully sensible to me. So sorry to waste the legal team's time, and please be considerate and don't waste ours either. If it is time to update process docs, do it already.
Re: [RE-VOTE #3] adoption of mod_combine subproject
On 4/3/2012 7:28 PM, Sam Ruby wrote: On 04/03/2012 08:14 PM, William A. Rowe Jr. wrote: Sam's prime weakness is an aversion to delegation. You have that exactly 180 degrees backwards. I am not responding precisely BECAUSE I believe in delegation. As well you should... it is for the PMC to decide... As danielsh pointed out, I asked a simple binary question. Instead of a simple binary reply, I get answers in the form of a question. Why did you ask a question? Nobody asked you to ask a question, but rather... People including myself, Eric, Graham and Roy are asking you a question. Where is the process documented? The PMC will collectively exercise the process and protect the integrity of the foundation, as you yourself have insisted that we do. We don't need you, on behalf of ASF legal, to determine what the heck Graham is doing, but we need to you to document how Eric, PMC VP is to supervise the project which is delegated to his direct oversight, and how we can support him in that supervision. Don't do that. Et tu I have stated that this is up to the PMC to decide. I have pointed to the criteria. If the PMC is note only welcome to execute according to that criteria, it absolutely is expected to do so. Excellent. I think we agree on critera. Our only difference of opinion is that, on my reading of the ICLA, it's impossible for a committer to do what you are asking the committer to confirm they have not done. Should the PMC operate outside of that criteria, the Legal Affairs committee will act. Answer that question with an affirmative, and there will be no reason for the Legal Affairs committee to intercede. I'm certain it will and welcome the committee's proactive activity to resolve this for the benefit of all TLPs. Meanwhile, do NOT continue to attempt pass off your responsibility to others. I will absolutely not shirk my own responsibility, which in this matter, is neither the responsibility of a committer placing code at the ASF, an officer acting under the direction of the BoD, nor a a director of the ASF. Which is to say, my entire responsibility as a member of the project and the foundation consisted of bringing the concern to the chair of the project and VP Legal, and let you all have your fun. I'm done with this dialog. Cheers.
Re: [RE-VOTE #3] adoption of mod_combine subproject
From the Apache HTTP Server project; On the combined topics of mod_firehose, mod_policy and mod_combine; Declaring the vote on #3 failed (both originally, and the revote). RE-VOTE #1 and #2 for firehose and policy modules (respectively) each have passed, for adoption into httpd trunk. (Backport is a separate and additional matter.) Firehose is already in httpd trunk, and policy awaits its import by minfrin. Thank you for presenting these works to the project for consideration, Graham! Now to resolve any last VP Legal concerns to get those first two modules adopted without a theater of the absurd IP Intake Procedural hurdle. Fielding had previously cleared that the entire ridiculous process was unnecessary and the httpd project continues to choose not to observe it, pending any legitimate illustration of its efficacy or benefit. (Would you like your air conditioning unit fixed, there? Would ya? You might have a clog in your IP Intake Hose. Central Services would be most displeased if we muck around with it, ya know. Must keep this hush hush... hand me that wrench...) CC'ing VP Legal by way of legal-discuss, to ask one final time for hizzoner's conclusion to https://issues.apache.org/bugzilla/show_bug.cgi?id=52322 - The httpd project considers the matter resolved, barring any legitimate objection from our legal expertise (per prior communiques) before month's end. Thanks all at httpd who voted on these three new modules, thanks Graham with the cooperation of Simon and the BBC for their submission (oooh... the irony!!!), and thank you in advance VP, Legal of the ASF for your considered recommendation on the matter of procedural handling of the intake on this intellectual property. Yours sincerely, Bill [not Tuttle] Rowe Former VP, Apache HTTP Server Project [Do hope you all enjoy the allegory, God love Terry Gilliam!]
Re: [RE-VOTE #3] adoption of mod_combine subproject
On 28 Mar 2012, at 1:02 PM, Sam Ruby wrote: Cut out the drama. It is not helpful here. The simple question is whether or not Graham has met the conditions specified in section 3 and 4 of the ICLA: http://www.apache.org/licenses/icla.txt Answer that in the affirmative, and you are done. - I have a signed ICLA on file. - I am a PMC member. - The contribution was submitted to the ASF bugzilla by the BBC directly (ie not someone in their personal capacity), which forces account holders to agree to the following condition: Certify that any object code, source code, patch, documentation, etc. that you may supply to an Apache project can be redistributed under the same license terms and conditions as the project itself. - The contribution was made after a BBC-internal process was followed to sign off and clear the code for donation. Can someone provide for me any concrete reason to suspect that the conditions in 3 and 4 might not have been met? Regards, Graham -- smime.p7s Description: S/MIME cryptographic signature
Re: [RE-VOTE #3] adoption of mod_combine subproject
Mobile mail.. sorry for brevity... Doesn't the ICLA Graham has previously filed with the ASF already compel him to make no contribution unless those conditions are met? After a decade is there any reason to believe he would act in contradiction to his sworn ICLA? Sorry if you find this fatigueing or my humor irritating. Laughing at ourselves can be healthy medicine and inspiring to come to more sensible and less silly written policy. I'm quite finished being angry or irritated over such issues :) -Original message- From: Graham Leggett minf...@sharp.fm To: Sam Ruby ru...@intertwingly.net Cc: William A. Rowe Jr. wr...@rowe-clan.net, dev@httpd.apache.org, legal-disc...@apache.org, Eric Covener cove...@gmail.com, Roy T. Fielding field...@gbiv.com, Simon Lucy simon.l...@bbc.co.uk Sent: Wed, Mar 28, 2012 13:21:47 GMT+00:00 Subject: Re: [RE-VOTE #3] adoption of mod_combine subproject On 28 Mar 2012, at 1:02 PM, Sam Ruby wrote: Cut out the drama. It is not helpful here. The simple question is whether or not Graham has met the conditions specified in section 3 and 4 of the ICLA: http://www.apache.org/licenses/icla.txt Answer that in the affirmative, and you are done. - I have a signed ICLA on file. - I am a PMC member. - The contribution was submitted to the ASF bugzilla by the BBC directly (ie not someone in their personal capacity), which forces account holders to agree to the following condition: Certify that any object code, source code, patch, documentation, etc. that you may supply to an Apache project can be redistributed under the same license terms and conditions as the project itself. - The contribution was made after a BBC-internal process was followed to sign off and clear the code for donation. Can someone provide for me any concrete reason to suspect that the conditions in 3 and 4 might not have been met? Regards, Graham --
Re: [RE-VOTE #3] adoption of mod_combine subproject
Guys. You were asked a boolean question. I'm pretty sure it was intended to be taken literally. Have you considered just answering it?
Re: [RE-VOTE #3] adoption of mod_combine subproject
On 3/5/2012 12:29 PM, Jeff Trawick wrote: On Sat, Mar 3, 2012 at 10:08 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: A proposal to adopt mod_combine is attached. [ ] Option 1: adopt as trunk module [ ] Option 2: adopt only as subproject [X] Option 3: do not adopt Before tallying, I just wanted to clarify your thoughts, Jeff. If this module has a place in the public commons, I'm going to guess that the BBC doesn't have an efficient open source development arm who are prepared to deal with licensing and the ongoing concerns of publishing source code for free. So I tend to doubt that there is another vehicle other than the ASF that would support Graham publishing this to the community. If you don't believe it merits a subproject, then the two options remaining would be a sandbox / unpublished module al la mod_arm4 (and I don't think we want to propagate such examples), or a labs project for now. So based on your concerns, how do you recommend Graham proceed with this code?
Re: [RE-VOTE #3] adoption of mod_combine subproject
On Tue, Mar 6, 2012 at 9:54 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 3/5/2012 12:29 PM, Jeff Trawick wrote: On Sat, Mar 3, 2012 at 10:08 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: A proposal to adopt mod_combine is attached. [ ] Option 1: adopt as trunk module [ ] Option 2: adopt only as subproject [X] Option 3: do not adopt Before tallying, I just wanted to clarify your thoughts, Jeff. If this module has a place in the public commons, I'm going to guess that the BBC doesn't have an efficient open source development arm who are prepared to deal with licensing and the ongoing concerns of publishing source code for free. So I tend to doubt that there is another vehicle other than the ASF that would support Graham publishing this to the community. If you don't believe it merits a subproject, then the two options remaining would be a sandbox / unpublished module al la mod_arm4 (and I don't think we want to propagate such examples), or a labs project for now. So based on your concerns, how do you recommend Graham proceed with this code? Doesn't everyone have a half-dozen or [many] more modules which are interesting for some purpose, might be useful for other developers to look at for one reason or another, but do not merit a sub-project or inclusion in the core server? I watch over a few I wrote that are in the same boat -- offered to the project, rejected (or at least not warmly welcomed), still used by a few other people who need to access the current versions. It can be awkward if a current (or, eventually, past) employer agrees to ASL and agrees to make it some part of httpd (if accepted) but it doesn't end up with a permanent home there, and thus isn't really the ASF's but isn't Jeff's or Graham's either in the normal sense. Is that what needs to be solved, or is this an issue of whether it gets downloaded from apache.org?
Re: [RE-VOTE #3] adoption of mod_combine subproject
This vote has another 15 hours to run. I'm personally -0 for adopting this module at all, it seems to run afoul of some design considerations that have excluded other modules in the past, such as mod_macro, from becoming part of httpd. That there are multiple static resources to be presented as single static resources seems computationally intensive and not the core webserver's task to handle, and an excuse for poor site and app design. I would join Jim in supporting mod_combine as a subproject, external to httpd trunk, for now. In the absence of additional support for this module this second time around, I'm stronly -1 to add this to httpd trunk on some lazy consensus. New modules should not hit httpd trunk without clear support from multiple, active project members. So for now my vote is option 2 as a show of support of Graham, to let him demonstrate that this fits in httpd. I guess the same could be said for a sandbox; we are all welcome to create a sandbox at any time without any vote at all. I'd rather that mod_combine be given recognition as a proper subproject [X] Option 2: adopt only as subproject On 3/3/2012 9:08 AM, William A. Rowe Jr. wrote: A proposal to adopt mod_combine is attached. [ ] Option 1: adopt as trunk module [ ] Option 2: adopt only as subproject [ ] Option 3: do not adopt [Prior to this vote, this proposal had not passed; jim alone had joined minfrin in supporting the proposal. Please take another look and vote.] On 12/13/2011 12:27 PM, Graham Leggett wrote: Hi all, As with mod_firehose and mod_policy, I have concluded negotiation with the BBC to open source some httpd modules that I wrote under the AL, and the BBC have very kindly agreed to donate the code to the ASF[1], which I believe would fit well as a subproject of httpd, and would like to know whether httpd would accept these. To be clear, this isn't a code dump, my intention is to continue to develop and support this moving forward, and hopefully expand the community around them. - mod_combine: Response concatenation As a page gets more complex, and eventually parts of the page like the header and footer become maintained by separate teams, the elements that make up a page can become fragmented. In the process, you can end up with a page that takes ages to load, because lots of fragments of javascript or fragments of CSS files are being downloaded separately by the browser. mod_combine is a handler that allows multiple URLs hosted by the server to be concatenated together and delivered as a single response, cutting down on the number of requests, and in turn the page loading time. At the same time, mod_combine attempts to behave sensibly when one or more of the files is missing, so as not to amplify a failure. The handler also properly supports conditional requests, creating a super ETag, and then reversing it to apply conditional requests on each element being concatenated. The code is currently packaged as an RPM, wrapped in autotools, and a snapshot is available here: http://people.apache.org/~minfrin/bbc-donated/mod_combine/ The corresponding README documenting in more detail is here: http://people.apache.org/~minfrin/bbc-donated/mod_combine/README The code itself is here: http://people.apache.org/~minfrin/bbc-donated/mod_combine/mod_combine.c Obviously the expectation is for the documentation to be completed and fleshed out. [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=52322 Regards, Graham --
Re: [RE-VOTE #3] adoption of mod_combine subproject
On Sat, Mar 3, 2012 at 10:08 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: A proposal to adopt mod_combine is attached. [ ] Option 1: adopt as trunk module [ ] Option 2: adopt only as subproject [X] Option 3: do not adopt
Re: [RE-VOTE #3] adoption of mod_combine subproject
On 05 Mar 2012, at 8:14 PM, William A. Rowe Jr. wrote: This vote has another 15 hours to run. I'm personally -0 for adopting this module at all, it seems to run afoul of some design considerations that have excluded other modules in the past, such as mod_macro, from becoming part of httpd. That there are multiple static resources to be presented as single static resources seems computationally intensive and not the core webserver's task to handle, and an excuse for poor site and app design. This module solves a niche problem in complex website configurations, where a particular page might be made of tens of subprojects, with independent release cycles released by independent teams. The module combines multiple small css and javascript files into a single download, but without the penalty of losing support for conditional requests, and without amplifying a denial of service if a specific file is missing for whatever reason. I would join Jim in supporting mod_combine as a subproject, external to httpd trunk, for now. I agree, +1. [X] Option 2: adopt only as subproject Regards, Graham --
