You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Chris Darroch <ch...@pearsoncmg.com> on 2008/12/09 19:30:54 UTC
mod_fcgid incubation?
Hi --
As Paul Querna noted recently, some folks are using mod_fcgid
these days instead of mod_fastcgi, in part because it was (I believe)
the first of the two to work with httpd 2.2. Unfortunately, the
original developer of mod_fcgid, Pan Qingfeng, has largely moved on
to other things.
He and I have been in touch lately about long-term maintenance
of mod_fcgid. (We've helped by a colleague of mine who can translate
fluently between Chinese and English, although Pan Qingfeng's English
is quite good as well.) In a pinch, I've offered to help get releases
out and review some of the queued-up patches contributed by various folks.
I also asked, though, whether he'd be interested in contributing
mod_fcgid to the ASF as, perhaps, a sub-project of httpd, and received
a very positive reply:
> 很高兴认识你们。我开发这个模块的目的也是想尽可能多的人可以用上它，所以
> 把它交给ASF完全没有问题（实际上我也很希望可以交给ASF)，过程中有任何问题我都
> 可以帮忙的。
which my colleague translates as follows:
> I am very glad to know you guys. I did this module and hoped more
> people could use it. There is no problem at all for me to donating
> the module to ASF (actually, I am glad to do so). If there is anything
> I can do to help, please feel free to let me know.
So, I said I'd raise the question on the httpd dev list. Since
I'm a neophyte to such things, and also not a lawyer, I assume this
would need to be voted on somehow, and then (if accepted) moved into
the incubation stage until legal issues were resolved.
One key question I have (jumping ahead a little) is whether
everyone who has contributed a patch to the project needs to contacted
and a signed contributor agreement recovered from them. If not, then I
would think that we'd just need a CLA from Pan Qingfeng to proceed
(and perhaps, in that case, we could skip the incubator stage, as
Apache ZooKeeper recently did).
If we do need CLAs from all patch contributors, that might take
more time. Fortunately, there's a good change log for the project
with names and email addresses; it includes some of the usual suspects
(like Paul Querna and myself) but also a number of other folks we'd need
to track down.
I know there's mod_proxy_fcgi in httpd already, but among other
things, it only handles the FCGI_RESPONDER role. It might be very nice
to be able to provide the FCGI_AUTHORIZER functionality as well either
via a separate module based on mod_fcgid, or through code merged into
mod_proxy_fcgi from that project. (The FCGI_FITLER role seems to be
unsupported in both mod_fcgid and mod_fastcgi; looks like that's a job
for the future, one way or another.)
At any rate, if people wouldn't mind chewing this over for a bit,
I'd really appreciate it. The project is available from SourceForge
under the GPL version 2.0. (Unfortunately, the actual code files are
largely missing the legal headers, but the intent is clear; I'm sure
this is an oversight due to [human] language barriers.)
See the following for info, code, and my own pending patches:
http://fastcgi.coremail.cn/
http://sourceforge.net/projects/mod-fcgid
http://people.apache.org/~chrisd/patches/mod_fcgid/
Thanks very much in advance for any advice people can offer,
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: mod_fcgid incubation?
Posted by Paul Querna <ch...@force-elite.com>.
William A. Rowe, Jr. wrote:
> Jim Jagielski wrote:
>> On Dec 9, 2008, at 1:30 PM, Chris Darroch wrote:
>>> One key question I have (jumping ahead a little) is whether
>>> everyone who has contributed a patch to the project needs to contacted
>>> and a signed contributor agreement recovered from them. If not, then I
>>> would think that we'd just need a CLA from Pan Qingfeng to proceed
>>> (and perhaps, in that case, we could skip the incubator stage, as
>>> Apache ZooKeeper recently did).
>>>
>>> If we do need CLAs from all patch contributors, that might take
>>> more time. Fortunately, there's a good change log for the project
>>> with names and email addresses; it includes some of the usual suspects
>>> (like Paul Querna and myself) but also a number of other folks we'd need
>>> to track down.
>>>
>> Since the orig code is GPL, then when people submitted the patches,
>> the expectation is that they would also be GPL. As such, for us
>> to be able to fold in the code, we would need iCLAs from everyone
>> who submitted a patch allowing us to relicense their bits as AL instead
>> of GPL... similar to what we needed to do when SpamAssassin come on board.
>
> Is it?
>
It is. AFAIK, mod_fcgid is a clean room implementation of the FastCGI
protocol, just like our mod_proxy_fcgi.
If you have looked at both mod_fastcgi and mod_fcgid, you will quickly
see there is no resemblance.
mod_fcgid uses lots of 2.x concepts, like custom buckets types and
brigades all over, while mod_fastcgi is a horrible horrible piece of
code written for 1.x, and later ported to 2.x.
-Paul
Re: mod_fcgid incubation?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Chris Darroch wrote:
> William A. Rowe, Jr. wrote:
>
>> The mod_fastcgi implementation has the following terms;
>>
>> Open Market permits you to use, copy, modify, distribute, and license
>> this Software and the Documentation solely for the purpose of
>> implementing the FastCGI specification defined by Open Market or
>> derivative specifications publicly endorsed by Open Market and
>> promulgated by an open standards organization and for no other
>> purpose, provided that existing copyright notices are retained in all
>> copies and that this notice is included verbatim in any distributions.
>>
>> No written agreement, license, or royalty fee is required for any of
>> the authorized uses. Modifications to this Software and Documentation
>> may be copyrighted by their authors and need not follow the licensing
>> terms described here, but the modified Software and Documentation must
>> be used for the sole purpose of implementing the FastCGI specification
>> defined by Open Market or derivative specifications publicly endorsed
>> by Open Market and promulgated by an open standards organization and
>> for no other purpose. If modifications to this Software and
>> Documentation have new licensing terms, the new terms must protect Open
>> Market's proprietary rights in the Software and Documentation to the
>> same extent as these licensing terms and must be clearly indicated on
>> the first page of each file where they apply.
>>
>> I'd call that a category X license, submission denied.
>
> So far as I know -- I'll check with the author -- mod_fcgid
> is a completely separate implementation from mod_fastcgi. I don't
> know of any generally shared or derived code, but I will check.
>
> The exception, I think, might be the FCGI protocol itself, which
> specifies the byte-level structure of the headers that are passed
> back and forth during communication with FCGI application processes.
>
> This definition lives in fcgi_protocol.h in both mod_fastcgi,
> and appears in very similar forms in both mod_fcgid's fcgi_protocol.h
> and also httpd's modules/proxy/fcgi_protocol.h. Look for the fcgi_header
> or FCGI_Header structure, and the various FCGI_* #defines for type
> values, roles, etc.
>
> It's a little hard for me to see how alternate implementations of
> the FastCGI spec could get away without doing something like this at
> a minimum, though.
Whatever can be found in fcgi-2.4.0 can be appropriately licensed by the
ASF and sublicensed to end users, complying with their license terms as
a NOTICE.
Whatever is only found in mod_fastcgi-2.4.6 is verboten.
Bill
Re: mod_fcgid incubation?
Posted by Chris Darroch <ch...@pearsoncmg.com>.
William A. Rowe, Jr. wrote:
> The mod_fastcgi implementation has the following terms;
>
> Open Market permits you to use, copy, modify, distribute, and license
> this Software and the Documentation solely for the purpose of
> implementing the FastCGI specification defined by Open Market or
> derivative specifications publicly endorsed by Open Market and
> promulgated by an open standards organization and for no other
> purpose, provided that existing copyright notices are retained in all
> copies and that this notice is included verbatim in any distributions.
>
> No written agreement, license, or royalty fee is required for any of
> the authorized uses. Modifications to this Software and Documentation
> may be copyrighted by their authors and need not follow the licensing
> terms described here, but the modified Software and Documentation must
> be used for the sole purpose of implementing the FastCGI specification
> defined by Open Market or derivative specifications publicly endorsed
> by Open Market and promulgated by an open standards organization and
> for no other purpose. If modifications to this Software and
> Documentation have new licensing terms, the new terms must protect Open
> Market's proprietary rights in the Software and Documentation to the
> same extent as these licensing terms and must be clearly indicated on
> the first page of each file where they apply.
>
> I'd call that a category X license, submission denied.
So far as I know -- I'll check with the author -- mod_fcgid
is a completely separate implementation from mod_fastcgi. I don't
know of any generally shared or derived code, but I will check.
The exception, I think, might be the FCGI protocol itself, which
specifies the byte-level structure of the headers that are passed
back and forth during communication with FCGI application processes.
This definition lives in fcgi_protocol.h in both mod_fastcgi,
and appears in very similar forms in both mod_fcgid's fcgi_protocol.h
and also httpd's modules/proxy/fcgi_protocol.h. Look for the fcgi_header
or FCGI_Header structure, and the various FCGI_* #defines for type
values, roles, etc.
It's a little hard for me to see how alternate implementations of
the FastCGI spec could get away without doing something like this at
a minimum, though.
Chris.
--
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
Re: mod_fcgid incubation?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
William A. Rowe, Jr. wrote:
>
> If the *original* code dates to Open Market's implementation, we need to
> use some caution. The original license was very restrictive. The current
> mod_fastcgi license is much less restrictive;
>
> "Open Market permits you to use, copy, modify, distribute, and license this
> Software and the Documentation for any purpose, provided that existing
> copyright notices are retained in all copies and that this notice is
> included verbatim in any distributions. No written agreement, license, or
> royalty fee is required for any of the authorized uses. Modifications to
> this Software and Documentation may be copyrighted by their authors and need
> not follow the licensing terms described here. If modifications to this
> Software and Documentation have new licensing terms, the new terms must be
> clearly indicated on the first page of each file where they apply."
>
> http://www.fastcgi.com/drupal/node/6?q=node/14
>
> At one point, authorized uses was much narrower, meaning that if the code
> was in svn, and re-purposed elsewhere, it was not licensed.
>
> If this is based on the original mod_fastcgi license, perhaps incorporating
> the modern, appropriately licensed flavor and then layering the mod_fcgid
> improvements on top of that would make the most sense?
Ok, this does get worse; the license cited above applies to to the fcgi
package itself.
The mod_fastcgi implementation has the following terms;
Open Market permits you to use, copy, modify, distribute, and license
this Software and the Documentation solely for the purpose of
implementing the FastCGI specification defined by Open Market or
derivative specifications publicly endorsed by Open Market and
promulgated by an open standards organization and for no other
purpose, provided that existing copyright notices are retained in all
copies and that this notice is included verbatim in any distributions.
No written agreement, license, or royalty fee is required for any of
the authorized uses. Modifications to this Software and Documentation
may be copyrighted by their authors and need not follow the licensing
terms described here, but the modified Software and Documentation must
be used for the sole purpose of implementing the FastCGI specification
defined by Open Market or derivative specifications publicly endorsed
by Open Market and promulgated by an open standards organization and
for no other purpose. If modifications to this Software and
Documentation have new licensing terms, the new terms must protect Open
Market's proprietary rights in the Software and Documentation to the
same extent as these licensing terms and must be clearly indicated on
the first page of each file where they apply.
I'd call that a category X license, submission denied.
Re: mod_fcgid incubation?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jim Jagielski wrote:
>
> On Dec 9, 2008, at 1:30 PM, Chris Darroch wrote:
>>
>> One key question I have (jumping ahead a little) is whether
>> everyone who has contributed a patch to the project needs to contacted
>> and a signed contributor agreement recovered from them. If not, then I
>> would think that we'd just need a CLA from Pan Qingfeng to proceed
>> (and perhaps, in that case, we could skip the incubator stage, as
>> Apache ZooKeeper recently did).
>>
>> If we do need CLAs from all patch contributors, that might take
>> more time. Fortunately, there's a good change log for the project
>> with names and email addresses; it includes some of the usual suspects
>> (like Paul Querna and myself) but also a number of other folks we'd need
>> to track down.
>>
>
> Since the orig code is GPL, then when people submitted the patches,
> the expectation is that they would also be GPL. As such, for us
> to be able to fold in the code, we would need iCLAs from everyone
> who submitted a patch allowing us to relicense their bits as AL instead
> of GPL... similar to what we needed to do when SpamAssassin come on board.
Is it?
If the *original* code dates to Open Market's implementation, we need to
use some caution. The original license was very restrictive. The current
mod_fastcgi license is much less restrictive;
"Open Market permits you to use, copy, modify, distribute, and license this
Software and the Documentation for any purpose, provided that existing
copyright notices are retained in all copies and that this notice is
included verbatim in any distributions. No written agreement, license, or
royalty fee is required for any of the authorized uses. Modifications to
this Software and Documentation may be copyrighted by their authors and need
not follow the licensing terms described here. If modifications to this
Software and Documentation have new licensing terms, the new terms must be
clearly indicated on the first page of each file where they apply."
http://www.fastcgi.com/drupal/node/6?q=node/14
At one point, authorized uses was much narrower, meaning that if the code
was in svn, and re-purposed elsewhere, it was not licensed.
If this is based on the original mod_fastcgi license, perhaps incorporating
the modern, appropriately licensed flavor and then layering the mod_fcgid
improvements on top of that would make the most sense?
Re: mod_fcgid incubation?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 9, 2008, at 1:30 PM, Chris Darroch wrote:
>
> One key question I have (jumping ahead a little) is whether
> everyone who has contributed a patch to the project needs to contacted
> and a signed contributor agreement recovered from them. If not,
> then I
> would think that we'd just need a CLA from Pan Qingfeng to proceed
> (and perhaps, in that case, we could skip the incubator stage, as
> Apache ZooKeeper recently did).
>
> If we do need CLAs from all patch contributors, that might take
> more time. Fortunately, there's a good change log for the project
> with names and email addresses; it includes some of the usual suspects
> (like Paul Querna and myself) but also a number of other folks we'd
> need
> to track down.
>
Since the orig code is GPL, then when people submitted the patches,
the expectation is that they would also be GPL. As such, for us
to be able to fold in the code, we would need iCLAs from everyone
who submitted a patch allowing us to relicense their bits as AL instead
of GPL... similar to what we needed to do when SpamAssassin come on
board.
Re: mod_fcgid incubation?
Posted by Max Dittrich <ma...@t-online.de>.
Hi,
Chris Darroch wrote:
> Hi --
>
> As Paul Querna noted recently, some folks are using mod_fcgid
> these days instead of mod_fastcgi, in part because it was (I believe)
> the first of the two to work with httpd 2.2. Unfortunately, the
> original developer of mod_fcgid, Pan Qingfeng, has largely moved on
> to other things.
>
> He and I have been in touch lately about long-term maintenance
> of mod_fcgid. (We've helped by a colleague of mine who can translate
> fluently between Chinese and English, although Pan Qingfeng's English
> is quite good as well.) In a pinch, I've offered to help get releases
> out and review some of the queued-up patches contributed by various folks.
I don't know much about the legal issues, but I think it's a good time
to decide about that.
FastCGI is very popular and should be available by the
apache-distribution. mod_fcgid did a nice start with their
process-control (in shared hosting environments), but it's lacking good
documentation and active maintenance.
When I read the question about the current development state of
mod_fcgid, I thought about to spent some time on it to (try to) improve
things, but I wouldn't be worth if Apache httpd would come up with
native FastCGI support in 2.4.x.
0.02$,
.max
Re: mod_fcgid incubation?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 10, 2008, at 8:05 PM, Roy T. Fielding wrote:
> On Dec 10, 2008, at 4:51 AM, Jim Jagielski wrote:
>> On Dec 9, 2008, at 4:56 PM, Nick Kew wrote:
>>> It's unfortunate there's no clear copyright statement, but would it
>>> not be reasonable to assume Copyright Pan Qingfeng and deal with
>>> him?
>>> Contact other contributors as a courtesy, but not let it worry us if
>>> some of them prove uncontactable, only if someone actually objects?
>>>
>> Submitting a patch or code does not imply copyright assignment.
>> So we cannot assume copyright Pan for the whole thing.
>
> Right, but not all code has a separate copyright. Repairs, for
> example,
> do not. So it is actually feasible that Pan can determine who needs
> to be contacted based on the change log and only contact those whose
> contributions were more than repairs to Pan's work.
>
+1
Re: mod_fcgid incubation?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Dec 10, 2008, at 4:51 AM, Jim Jagielski wrote:
> On Dec 9, 2008, at 4:56 PM, Nick Kew wrote:
>> It's unfortunate there's no clear copyright statement, but would it
>> not be reasonable to assume Copyright Pan Qingfeng and deal with him?
>> Contact other contributors as a courtesy, but not let it worry us if
>> some of them prove uncontactable, only if someone actually objects?
>>
> Submitting a patch or code does not imply copyright assignment.
> So we cannot assume copyright Pan for the whole thing.
Right, but not all code has a separate copyright. Repairs, for example,
do not. So it is actually feasible that Pan can determine who needs
to be contacted based on the change log and only contact those whose
contributions were more than repairs to Pan's work.
....Roy
Re: mod_fcgid incubation?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Dec 9, 2008, at 4:56 PM, Nick Kew wrote:
>
> It's unfortunate there's no clear copyright statement, but would it
> not be reasonable to assume Copyright Pan Qingfeng and deal with him?
> Contact other contributors as a courtesy, but not let it worry us if
> some of them prove uncontactable, only if someone actually objects?
>
Submitting a patch or code does not imply copyright assignment.
So we cannot assume copyright Pan for the whole thing.
Re: mod_fcgid incubation?
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 9 Dec 2008 21:56:43 +0000
Nick Kew <ni...@webthing.com> wrote:
> Does anyone have a complete list of people who have made nontrivial
> contributions, such that their IP might be affected?
Ignore that - I meant to chop those lines when I read (as opposed
to skimmed) the following paragraphs. Bah.
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: mod_fcgid incubation?
Posted by Nick Kew <ni...@webthing.com>.
On Tue, 09 Dec 2008 10:30:54 -0800
Chris Darroch <ch...@pearsoncmg.com> wrote:
> He and I have been in touch lately about long-term maintenance
> of mod_fcgid. (We've helped by a colleague of mine who can translate
> fluently between Chinese and English, although Pan Qingfeng's English
> is quite good as well.) In a pinch, I've offered to help get releases
> out and review some of the queued-up patches contributed by various
> folks.
If IP issues can be dealt with, then I'd say a definite +1.
FastCGI is one of our most popular third-party extensions,
and mod_fcgid appears to be the best available implementation.
Does anyone have a complete list of people who have made nontrivial
contributions, such that their IP might be affected?
> One key question I have (jumping ahead a little) is whether
> everyone who has contributed a patch to the project needs to contacted
> and a signed contributor agreement recovered from them. If not, then
> I would think that we'd just need a CLA from Pan Qingfeng to proceed
> (and perhaps, in that case, we could skip the incubator stage, as
> Apache ZooKeeper recently did).
Possibly a software grant rather than a CLA, if he's basically handing
it to us. But yes, we'd need to act together.
> If we do need CLAs from all patch contributors, that might take
> more time. Fortunately, there's a good change log for the project
> with names and email addresses; it includes some of the usual suspects
> (like Paul Querna and myself) but also a number of other folks we'd
> need to track down.
It's unfortunate there's no clear copyright statement, but would it
not be reasonable to assume Copyright Pan Qingfeng and deal with him?
Contact other contributors as a courtesy, but not let it worry us if
some of them prove uncontactable, only if someone actually objects?
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/