You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Graham Leggett <mi...@sharp.fm> on 2011/12/13 19:27:04 UTC

Proposal: adoption of mod_combine subproject

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: Proposal: adoption of mod_combine subproject

Posted by Jorge Schrauwen <jo...@gmail.com>.
Looks like a very interesting module!

i'd love to see this adapted.

~Jorge


On Tue, Dec 13, 2011 at 7:27 PM, Graham Leggett <mi...@sharp.fm> 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: Proposal: adoption of mod_combine subproject

Posted by Igor Galić <i....@brainsware.org>.

----- Original Message -----
> I haven't had time to study this idea in detail, but it does sound
> much
> more like a subproject, as opposed to incorporating as a module.
> 
> I'm not very clear how this differs in approach from mod_pagespeed,
> and
> how the two could be leveraged together.
> 

For me it sounded more like ESI (Edge Side Includes)
(I didn't have time to look closer at it either..)

i

-- 
Igor Galić

Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515  2EA5 4B1D 9E08 A097 C9AE


Re: Proposal: adoption of mod_combine subproject

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
I haven't had time to study this idea in detail, but it does sound much
more like a subproject, as opposed to incorporating as a module.

I'm not very clear how this differs in approach from mod_pagespeed, and
how the two could be leveraged together.

Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by Jeff Trawick <tr...@gmail.com>.
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

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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

Posted by Jeff Trawick <tr...@gmail.com>.
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

Posted by Sam Ruby <ru...@intertwingly.net>.
On 03/28/2012 06:22 PM, William A Rowe Jr wrote:
> 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?

Having the Legal Affairs committee evaluate each and every contribution 
does not scale.  It is up to the PMC to police the project.  I've 
pointed you to the conditions the PMC needs to use to evaluate the 
potential contribution.  I will only add that in the case of a codebase 
with a single author the evaluation should not be difficult to make.

Make a call, and come back when you have a difficult question.

- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Fwd: Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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-discuss@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.



Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 4/4/2012 1:15 PM, Sam Ruby wrote:
> On Wed, Apr 4, 2012 at 11:13 AM, William A. Rowe Jr.
> <wr...@rowe-clan.net> wrote:
>>
>> 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".
> 
> That was on March 2nd.  In that discussion, I said (and on the same day):
> 
>>> In the case where the code in question was created by a single author,
>>> I'm in agreement that an ICLA is all that is needed.
> 
> I even put such text directly into the bug in question:
> 
> https://issues.apache.org/bugzilla/show_bug.cgi?id=52322#c9

THANK YOU!  Sometimes a few works (e.g. "an ICLA is all that is needed")
will make everything clear, and all of us may sometimes read over the
critical phrase.  I'm sorry for overlooking that quote.

I'm not familiar at this point with the www.a.o/dev/... site CMS, but am
happy to adjust that verbage while I am at it once I have time to work out
the details of editing the site.  The most offensive example is the boxed
text on http://incubator.apache.org/ip-clearance/index.html which does /not/
distinguish icla single author contributions (and in fact makes no mention
of the icla at all, how odd).

"Any code that was developed outside of the ASF SVN repository and our public
mailing lists must be processed like this, even if the external developer is
already an ASF committer." is entirely incorrect for these icla-based cases
and this and similar text must be cleaned or expunged."

I haven't performed an exhaustive search yet... things are correct but not very
clear at http://www.apache.org/dev/committers.html

"Applying patches"

"In order to grow and maintain healthy communities, committers need to discuss, review and
apply patches submitted by volunteers. The Committers are also responsible for the quality
and IP clearance of the code that goes into ASF repositories."

It doesn't go on to explain what IP clearance actually is and I'm not
in the right position to write that explanation.

Things are much better at http://www.apache.org/dev/release-publishing.html

"All the source code of the project must be covered by the Apache License, version 2.0.
The license must be included in each source file. For the license to be valid, the code
must have been contributed by an individual covered by an appropriate contributor license
agreement, or have otherwise been licensed to the Foundation and passed through IP
clearance." gets it right.

No edit needed, it says exactly what we've all been saying :)


---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by Sam Ruby <ru...@intertwingly.net>.
On Wed, Apr 4, 2012 at 11:13 AM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
>
> 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".

That was on March 2nd.  In that discussion, I said (and on the same day):

>> In the case where the code in question was created by a single author,
>> I'm in agreement that an ICLA is all that is needed.

I even put such text directly into the bug in question:

https://issues.apache.org/bugzilla/show_bug.cgi?id=52322#c9

> Sam now finally concurs

"now finally"?

- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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.


Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by Jim Jagielski <ji...@jaguNET.com>.
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...

Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by Sam Ruby <ru...@intertwingly.net>.
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 mistakes that are promptly addressed are not a problem.  A
>> pattern of mistakes will prompt action, first from the Legal Affairs
>> committee, and ultimately by the board.
>>
>> - Sam Ruby
>
> When I don't quote the top quote, I'm sure we agree.  Let's document that,
> and precisely what it means to provide IP intake oversight at the PMC level,
> without involving other committees for every common sense addition, and put
> that document (with generous doses of common sense) to all of the PMC's to
> enforce?  Is there another legal PMC member who wants to act as recorder
> in the coming week?

The part that we appear to agree on is (a) that the conditions that 
committers are expected to meet are documented in the ICLA, (b) that it 
is not impossible for people to make mistakes, and therefore (c) the PMC 
needs to be vigilant.  Apparently you feel that something in these 
simple statements isn't common sense, and needs to be documented.  But 
you aren't willing to document it, and are looking for somebody else to 
do it for you.

Meanwhile, I am not going to make the judgment call as to whether this 
particular individual is trustworthy and followed all of the necessary 
procedures.  I don't have the necessary context, that approach doesn't 
scale, and that's not what delegation is all about.  The responsibility, 
authority, and accountability for that decision rests with the PMC.

If you feel a compelling need for documentation in order to proceed on 
this specific contribution, how about you simply point people to this 
post as it appears in the email archives?

- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by "William A. Rowe Jr." <wr...@apache.org>.
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 mistakes that are promptly addressed are not a problem.  A
> pattern of mistakes will prompt action, first from the Legal Affairs
> committee, and ultimately by the board.
> 
> - Sam Ruby

When I don't quote the top quote, I'm sure we agree.  Let's document that,
and precisely what it means to provide IP intake oversight at the PMC level,
without involving other committees for every common sense addition, and put
that document (with generous doses of common sense) to all of the PMC's to
enforce?  Is there another legal PMC member who wants to act as recorder
in the coming week?

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by Sam Ruby <ru...@intertwingly.net>.
On Tue, Apr 3, 2012 at 10:14 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> On 4/3/2012 8:53 PM, Sam Ruby wrote:
>> On Tue, Apr 3, 2012 at 9:37 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>>> Where is the process documented?
>>
>> http://www.apache.org/licenses/icla.txt
>>
>>> 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.
>>
>> You are seriously asserting that it is IMPOSSIBLE (emphasis added) for
>> a committer to commit something that is not their original creation,
>> or to not include complete details of any third-party license or other
>> restriction, or to not have received permission to make Contributions
>> on behalf of that employer or (need I go on)?
>
> ... without violating the terms of their ICLA contract with the ASF.
>
> Yes, that's what I'm saying.

*sigh*

... and the organizational unit that is responsible for the oversight
of each and every commit to a given project in order to detect honest
mistakes or misunderstandings or whatever is... drumroll ... the PMC!

Mistakes happen.  Misunderstandings happen.  That's why we have
organizational units set up to deal with such.

>> So, to recap: the documentation is posted on our website (link
>> helpfully provided above), and each and every one of those things
>> listed is clearly possible.  From time to time, they even happen.  It
>> is the PMC's job to monitor for such occurrences and to apply
>> remediation when necessary.
>
> Reminders to all committers at various points of the scope of their
> contract with and responsibilities towards the ASF with respect to their
> commit privileges seems like a good idea to me, too.  Can we find a way
> to do that without treating every commit as suspect?

I encourage you to not use such drama filled terms as 'suspect'.  We
are dealing with humans.  Humans make mistakes.  Not because they are
evil, but because they are human.

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 mistakes that are promptly addressed are not a problem.  A
pattern of mistakes will prompt action, first from the Legal Affairs
committee, and ultimately by the board.

- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 4/3/2012 8:53 PM, Sam Ruby wrote:
> On Tue, Apr 3, 2012 at 9:37 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>> Where is the process documented?
> 
> http://www.apache.org/licenses/icla.txt
> 
>> 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.
> 
> You are seriously asserting that it is IMPOSSIBLE (emphasis added) for
> a committer to commit something that is not their original creation,
> or to not include complete details of any third-party license or other
> restriction, or to not have received permission to make Contributions
> on behalf of that employer or (need I go on)?

... without violating the terms of their ICLA contract with the ASF.

Yes, that's what I'm saying.

> So, to recap: the documentation is posted on our website (link
> helpfully provided above), and each and every one of those things
> listed is clearly possible.  From time to time, they even happen.  It
> is the PMC's job to monitor for such occurrences and to apply
> remediation when necessary.

Reminders to all committers at various points of the scope of their
contract with and responsibilities towards the ASF with respect to their
commit privileges seems like a good idea to me, too.  Can we find a way
to do that without treating every commit as suspect?



---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by Sam Ruby <ru...@intertwingly.net>.
On Tue, Apr 3, 2012 at 9:37 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> Where is the process documented?

http://www.apache.org/licenses/icla.txt

> 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.

You are seriously asserting that it is IMPOSSIBLE (emphasis added) for
a committer to commit something that is not their original creation,
or to not include complete details of any third-party license or other
restriction, or to not have received permission to make Contributions
on behalf of that employer or (need I go on)?

If that is what you are saying, please explain further, as I clearly disagree.

So, to recap: the documentation is posted on our website (link
helpfully provided above), and each and every one of those things
listed is clearly possible.  From time to time, they even happen.  It
is the PMC's job to monitor for such occurrences and to apply
remediation when necessary.

- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by Jim Jagielski <ji...@jaguNET.com>.
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...
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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.

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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

Posted by Sam Ruby <ru...@intertwingly.net>.
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 danielsh pointed out, I asked a simple binary question.  Instead of a 
simple binary reply, I get answers in the form of a question.

Don't do that.

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.

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.

Meanwhile, do NOT continue to attempt pass off your responsibility to 
others.

- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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.

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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.

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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.



---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
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

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Guys.  You were asked a boolean question.  I'm pretty sure it was
intended to be taken literally.  Have you considered just answering it?

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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 <mi...@sharp.fm>
To: Sam Ruby <ru...@intertwingly.net>
Cc: "William A. Rowe Jr." <wr...@rowe-clan.net>, dev@httpd.apache.org, legal-discuss@apache.org, Eric Covener <co...@gmail.com>, "Roy T. Fielding" <fi...@gbiv.com>, Simon Lucy <si...@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

Posted by William A Rowe Jr <wr...@rowe-clan.net>.
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 <mi...@sharp.fm>
To: Sam Ruby <ru...@intertwingly.net>
Cc: "William A. Rowe Jr." <wr...@rowe-clan.net>, dev@httpd.apache.org, legal-discuss@apache.org, Eric Covener <co...@gmail.com>, "Roy T. Fielding" <fi...@gbiv.com>, Simon Lucy <si...@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

Posted by Graham Leggett <mi...@sharp.fm>.
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

Posted by Graham Leggett <mi...@sharp.fm>.
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

Posted by Sam Ruby <ru...@intertwingly.net>.
On 03/28/2012 02:07 AM, William A. Rowe Jr. wrote:
>  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.

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.

> Yours sincerely,
>
> Bill [not Tuttle] Rowe
> Former VP, Apache HTTP Server Project
>
> [Do hope you all enjoy the allegory, God love Terry Gilliam!]

- Sam Ruby



---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
>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

Posted by Graham Leggett <mi...@sharp.fm>.
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
--


Re: [RE-VOTE #3] adoption of mod_combine subproject

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
>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!]

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


[RE-VOTE #3] adoption of mod_combine subproject

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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: Proposal: adoption of mod_combine subproject

Posted by Jim Jagielski <ji...@jaguNET.com>.
+1!
On Dec 13, 2011, at 1: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"
>