Re: DAV Option Patch
On Tue, 2009-09-15 at 11:25 +0200, ext Graham Leggett wrote: Brian J. France wrote: Jari is the original author of mod_dav_acl, which requires patches to httpd to work. I need the same functionality added to httpd to get a mod_dav_acl type module working, so I have split up his patch into smaller pieces. Can a patch be under a different license than the original code? Yes it can, but only the author of the original code can do that, as only the original author (the copyright holder) can set the terms by which his patch can be used. The way forward is to ask Jari to submit his httpd-2.2.8-ju.patch to us, granting us permission to use the Apache software license on it. I'll assume that you don't need here the content which is included within mod_dav_acl package at sf.net ? Otherwise you are certainly free to use it anyways you like. Patch contains mostly some hooks to mod_dav, but since i'm not that familiar with apr apache code, you can certainly improve things. For dav_acl, caldav and carddav modules (the latter of which i just recently submitted), only similar kind of things are needed, so you can change the api freely as long as the functionality remains. I do have some cycles to update my modules accordingly. What comes to having included these with httpd, I'm in the process of asking permission from my company the change the license to APL Thanks, Jari
Re: DAV Option Patch
On Tue, 2009-09-15 at 18:42 +0200, ext Julian Reschke wrote: Brian J. France wrote: ... There is one draw back to this patch in that there could be duplicated values in the headers. Both mod_dav_acl and mod_caldav want to add the REPORT in the Allow header, so it would show up twice in the list. I am not sure if this is a major problem, but wanted to make a note of it. ... It shouldn't be a problem, but on the other hand: is there any particular reason for the new code not to enforce each value is only reported once? BR, Julian Nothing at all, since it is trivial to fix it so (originally i didn't bother to do that since I knew clients don't mind...) br, Jari
Re: DAV Option Patch
Jari Urpalainen wrote: What comes to having included these with httpd, I'm in the process of asking permission from my company the change the license to APL APL? We presume you mean AL (or ApL) ;-)
Re: DAV Option Patch
On Wed, Sep 16, 2009 at 10:09:23AM +0300, Jari Urpalainen wrote: I'll assume that you don't need here the content which is included within mod_dav_acl package at sf.net ? Otherwise you are certainly free to use it anyways you like. Patch contains mostly some hooks to mod_dav, but since i'm not that familiar with apr apache code, you can certainly improve things. For dav_acl, caldav and carddav modules (the latter of which i just recently submitted), only similar kind of things are needed, so you can change the api freely as long as the functionality remains. I do have some cycles to update my modules accordingly. What comes to having included these with httpd, I'm in the process of asking permission from my company the change the license to APL If you can submit the patches to the ASF under the Apache Software License, it is sufficient for you to send them to this mailing list - that counts as a contribution to the ASF. If you can do that, we can then include the patches in the tree, but if your employer owns the copyright to the patches, then be sure you are authorized to submit the code under that license first. Regards, Joe
Re: DAV Option Patch
On Wed, 2009-09-16 at 11:39 +0200, ext Joe Orton wrote:
On Wed, Sep 16, 2009 at 10:09:23AM +0300, Jari Urpalainen wrote:
I'll assume that you don't need here the content which is included
within mod_dav_acl package at sf.net ? Otherwise you are certainly free
to use it anyways you like. Patch contains mostly some hooks to
mod_dav, but since i'm not that familiar with apr apache code, you can
certainly improve things. For dav_acl, caldav and carddav modules (the
latter of which i just recently submitted), only similar kind of things
are needed, so you can change the api freely as long as the
functionality remains. I do have some cycles to update my modules
accordingly. What comes to having included these with httpd, I'm in the
process of asking permission from my company the change the license to
APL
If you can submit the patches to the ASF under the Apache Software
License, it is sufficient for you to send them to this mailing list -
that counts as a contribution to the ASF.
If you can do that, we can then include the patches in the tree, but if
your employer owns the copyright to the patches, then be sure you are
authorized to submit the code under that license first.
Regards, Joe
Ok, here's the patch (which I'm authorized to submit). And yes you can
apply the Apache License, Version 2.0 or what is the official name.
thanks Jari
diff -Naur httpd-2.2.8/modules/dav/fs/repos.c httpd-2.2.8-ju/modules/dav/fs/repos.c
--- httpd-2.2.8/modules/dav/fs/repos.c 2008-06-04 10:53:04.0 +0300
+++ httpd-2.2.8-ju/modules/dav/fs/repos.c 2008-07-02 10:17:47.0 +0300
@@ -46,6 +46,7 @@
apr_pool_t *pool;/* memory storage pool associated with request */
const char *pathname; /* full pathname to resource */
apr_finfo_t finfo; /* filesystem info */
+request_rec *r;
};
/* private context for doing a filesystem walk */
@@ -200,6 +201,11 @@
**
** PRIVATE REPOSITORY FUNCTIONS
*/
+request_rec *dav_fs_get_request_rec(const dav_resource *resource)
+{
+return resource-info-r;
+}
+
apr_pool_t *dav_fs_pool(const dav_resource *resource)
{
return resource-info-pool;
@@ -638,6 +644,7 @@
/* Create private resource context descriptor */
ctx = apr_pcalloc(r-pool, sizeof(*ctx));
ctx-finfo = r-finfo;
+ctx-r = r;
/* ### this should go away */
ctx-pool = r-pool;
@@ -1775,17 +1782,13 @@
if (!resource-exists)
return apr_pstrdup(ctx-pool, );
+{
+ request_rec *r = ctx-r;
-if (ctx-finfo.filetype != 0) {
-return apr_psprintf(ctx-pool, \% APR_UINT64_T_HEX_FMT -%
-APR_UINT64_T_HEX_FMT -% APR_UINT64_T_HEX_FMT \,
-(apr_uint64_t) ctx-finfo.inode,
-(apr_uint64_t) ctx-finfo.size,
-(apr_uint64_t) ctx-finfo.mtime);
-}
-
-return apr_psprintf(ctx-pool, \% APR_UINT64_T_HEX_FMT \,
- (apr_uint64_t) ctx-finfo.mtime);
+ r-mtime = ctx-finfo.mtime;
+r-finfo = ctx-finfo;
+ return ap_make_etag(r, 0);
+}
}
static const dav_hooks_repository dav_hooks_repository_fs =
@@ -1812,6 +1815,9 @@
dav_fs_remove_resource,
dav_fs_walk,
dav_fs_getetag,
+dav_fs_get_request_rec,
+dav_fs_pathname,
+NULL
};
static dav_prop_insert dav_fs_insert_prop(const dav_resource *resource,
diff -Naur httpd-2.2.8/modules/dav/main/mod_dav.c httpd-2.2.8-ju/modules/dav/main/mod_dav.c
--- httpd-2.2.8/modules/dav/main/mod_dav.c 2008-06-04 10:53:04.0 +0300
+++ httpd-2.2.8-ju/modules/dav/main/mod_dav.c 2008-07-02 10:24:09.0 +0300
@@ -57,6 +57,8 @@
#include http_request.h
#include util_script.h
+#include ap_provider.h
+
#include mod_dav.h
@@ -79,6 +81,8 @@
const char *dir;
int locktimeout;
int allow_depthinfinity;
+int acl_checking;
+int etag_response;
} dav_dir_conf;
@@ -195,10 +199,18 @@
newconf-dir = DAV_INHERIT_VALUE(parent, child, dir);
newconf-allow_depthinfinity = DAV_INHERIT_VALUE(parent, child,
allow_depthinfinity);
+newconf-acl_checking = DAV_INHERIT_VALUE(parent, child, acl_checking);
+newconf-etag_response = DAV_INHERIT_VALUE(parent, child, etag_response);
return newconf;
}
+DAV_DECLARE(const char *) dav_get_provider_name(request_rec *r)
+{
+dav_dir_conf *conf = ap_get_module_config(r-per_dir_config, dav_module);
+return conf ? conf-provider_name : NULL;
+}
+
static const dav_provider *dav_get_provider(request_rec *r)
{
dav_dir_conf *conf;
@@ -287,6 +299,30 @@
}
/*
+ * Command handler for the DAVACL directive, which is FLAG.
+ */
+static const char *dav_cmd_acl_checking(cmd_parms *cmd, void *config,
+ int arg)
+{
+dav_dir_conf *conf = (dav_dir_conf *)config;
+
+conf-acl_checking = arg;
+return NULL;
+}
+
+/*
+ * Command
Re: DAV Option Patch
Jari Urpalainen wrote: Ok, here's the patch (which I'm authorized to submit). And yes you can apply the Apache License, Version 2.0 or what is the official name. Excellent, thank you for the running round - this clears Brian to keep submitting patches based on this one. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: DAV Option Patch
Brian J. France wrote: While Jari's mod_dav_acl is licensed under LGPL, can the patches to httpd be licensed that way? What would we need to do to get them added if Jari's patches (or even mod_dav_acl) would fall under LGPL? All Jari would need to do is email the list to confirm that he is happy that these patches can be licensed under the ASF license and included within httpd, and that's it. Jari's confirmation would not affect mod_dav_acl in any way, he can license mod_dav_acl any way he feels comfortable with. It's only the patches that are imported into httpd - ie these patches you are submitting - that are affected. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: DAV Option Patch
Brian J. France wrote: Jari is the original author of mod_dav_acl, which requires patches to httpd to work. I need the same functionality added to httpd to get a mod_dav_acl type module working, so I have split up his patch into smaller pieces. Can a patch be under a different license than the original code? Yes it can, but only the author of the original code can do that, as only the original author (the copyright holder) can set the terms by which his patch can be used. The way forward is to ask Jari to submit his httpd-2.2.8-ju.patch to us, granting us permission to use the Apache software license on it. At that point you are free to chop up the patch and submit it to us. Long answer: A person who creates some code owns the copyright on that code, and can set any terms they like on it's use. The copyright holder can also change their mind as to the terms at some future date, and they can also give one group of people the code under terms A (like bundled with mod_dav_acl under the LGPL) and simultaneously give another group of people the same code under terms B (like giving httpd-2.2.8-ju.patch to the ASF under the ASL). The reason all this matters is the terms of the LGPL - any derivative work of LGPL code (ie your patches, derived from Jari's patches), has to also be licensed under the LGPL. And LGPL code cannot be imported into other code that isn't itself LGPL. Because httpd isn't LGPL, the LGPL license doesn't allow it, so we (the httpd project) are legally obliged in terms of the LGPL not to accept it. The solution is for Jari to release httpd-2.2.8-ju.patch to us under the ASL, and that clears the way legally for all the code to be officially incorporated into the httpd codebase, removing the need for the special patch on your side, and that can be done by Jari submitting the httpd-2.2.8-ju.patch on this mailing list, and confirming his permission to release it under the ASL. Jari is still free to include the httpd-2.2.8-ju.patch within mod_dav_acl under the LGPL, because he is free to license his code in as many ways as he likes. The existing mod_dav_acl is not affected in any way. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: DAV Option Patch
Brian J. France wrote: ... There is one draw back to this patch in that there could be duplicated values in the headers. Both mod_dav_acl and mod_caldav want to add the REPORT in the Allow header, so it would show up twice in the list. I am not sure if this is a major problem, but wanted to make a note of it. ... It shouldn't be a problem, but on the other hand: is there any particular reason for the new code not to enforce each value is only reported once? BR, Julian
Re: DAV Option Patch
Brian J. France wrote: These patches are based off of 2.2.13, but if you would rather have patch against a branch or head, please let me know. Creating patches off head is the place to start, and once the patches have been committed to head, the next step is for people to vote on backporting the patches to v2.2, which as you already have patches for v2.2 should be straightfoward. Breaking up the patches as you have mentioned above makes reviewing the patches easier, and in turn that makes it easier to gets votes for backport. If you break up the patches, I'll take a look and get them into trunk. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: DAV Option Patch
Brian J. France br...@brianfrance.com writes: I have updated the dav-options patch against head: http://www.brianfrance.com/software/apache/dav/dav-options.diff One suggestion - using hook in the names could be confusing since this isn't using the built-in hook mechanism. Since it is using the provider mechanism, maybe names like dav_options_provider would be clearer. -- Dan Poirier poir...@pobox.com
Re: DAV Option Patch
On Sep 14, 2009, at 10:23 AM, Graham Leggett wrote: Brian J. France wrote: These patches are based off of 2.2.13, but if you would rather have patch against a branch or head, please let me know. Creating patches off head is the place to start, and once the patches have been committed to head, the next step is for people to vote on backporting the patches to v2.2, which as you already have patches for v2.2 should be straightfoward. I have updated the dav-options patch against head: http://www.brianfrance.com/software/apache/dav/dav-options.diff The dav-options-acl.diff patch will apply to head because it just creates new files, but remember it shouldn't be committed as it is just an example. Breaking up the patches as you have mentioned above makes reviewing the patches easier, and in turn that makes it easier to gets votes for backport. If you break up the patches, I'll take a look and get them into trunk. Great! Thanks, Brian
Re: DAV Option Patch
On Sep 14, 2009, at 12:04 PM, Dan Poirier wrote: One suggestion - using hook in the names could be confusing since this isn't using the built-in hook mechanism. Since it is using the provider mechanism, maybe names like dav_options_provider would be clearer. I have updated the patches: http://www.brianfrance.com/software/apache/dav/dav-option-provider.diff and the example module (which shouldn't be commited): http://www.brianfrance.com/software/apache/dav/dav-option-provider-acl.diff Let me know what you think. Thanks! Brian
Re: DAV Option Patch
Brian J. France wrote: I have updated the patches: http://www.brianfrance.com/software/apache/dav/dav-option-provider.diff Committed in r814832, can you verify that I have attributed the patch correctly in CHANGES? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: DAV Option Patch
On Mon, Sep 14, 2009 at 10:11:24AM -0400, Brian J. France wrote: I would like to get some form of mod_dav_acl[1] added to httpd. My end goal with all of this is to get a mod_caldav and mod_cardav accepted down the line or at least be able to build the module with out hacking the core httpd source. I am going to start by splitting up the Jari's mod_dav_acl patches to httpd into small patches with detailed explanation on why they are needed and first up is the DAV options patch. Currently there is no way for other dav modules to add things do the DAV or Allow headers of a OPTIONS request, only the mod_dav module can output those items. This patch: It's not clear to me - is Jari the original author of this code, or yourself? mod_dav_acl seems to be licensed under the LGPL still. Regards, Joe
Re: DAV Option Patch
On Sep 14, 2009, at 04:32 PM, Graham Leggett wrote: Brian J. France wrote: I have updated the patches: http://www.brianfrance.com/software/apache/dav/dav-option-provider.diff Committed in r814832, can you verify that I have attributed the patch correctly in CHANGES? Thanks! Can you credit Jari Urpalainen (jari.urpalainen nokia.com) as well as these are all based on his patches for his mod_dav_acl. More patches tomorrow. Cheers, Brian
Re: DAV Option Patch
Brian J. France wrote: Can you credit Jari Urpalainen (jari.urpalainen nokia.com) as well as these are all based on his patches for his mod_dav_acl. Done in 814860. More patches tomorrow. I see the example module that you asked not to commit is ASF licensed, is this true also of the patches you've have submitted so far? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: DAV Option Patch
On Sep 14, 2009, at 05:23 PM, Graham Leggett wrote: Brian J. France wrote: Can you credit Jari Urpalainen (jari.urpalainen nokia.com) as well as these are all based on his patches for his mod_dav_acl. Done in 814860. More patches tomorrow. I see the example module that you asked not to commit is ASF licensed, is this true That example module is my testing module and is under the ASF licensed. also of the patches you've have submitted so far? While Jari's mod_dav_acl is licensed under LGPL, can the patches to httpd be licensed that way? What would we need to do to get them added if Jari's patches (or even mod_dav_acl) would fall under LGPL? I know he is would like to see them added to httpd. Brian
Re: DAV Option Patch
Brian J. France wrote: While Jari's mod_dav_acl is licensed under LGPL, can the patches to httpd be licensed that way? They are licensed however he licenses them. What would we need to do to get them added if Jari's patches (or even mod_dav_acl) would fall under LGPL? I know he is would like to see them added to httpd. That will only happen if he offers them to httpd dev list under the Apache License. The best way for that to happen is an email to the list from him. If they are substantial, we also need an ICLA from him; http://www.apache.org/licenses/#clas
Re: DAV Option Patch
On Sep 14, 2009, at 05:02 PM, Joe Orton wrote: On Mon, Sep 14, 2009 at 10:11:24AM -0400, Brian J. France wrote: I would like to get some form of mod_dav_acl[1] added to httpd. My end goal with all of this is to get a mod_caldav and mod_cardav accepted down the line or at least be able to build the module with out hacking the core httpd source. I am going to start by splitting up the Jari's mod_dav_acl patches to httpd into small patches with detailed explanation on why they are needed and first up is the DAV options patch. Currently there is no way for other dav modules to add things do the DAV or Allow headers of a OPTIONS request, only the mod_dav module can output those items. This patch: It's not clear to me - is Jari the original author of this code, or yourself? mod_dav_acl seems to be licensed under the LGPL still. Jari is the original author of mod_dav_acl, which requires patches to httpd to work. I need the same functionality added to httpd to get a mod_dav_acl type module working, so I have split up his patch into smaller pieces. Can a patch be under a different license than the original code? My plan is to create a mod_dav_acl module that would require providers to plugin (mod_dav_acl_fs, mod_dav_acl_dbd, etc). Brian
Re: DAV Option Patch
On Mon, Sep 14, 2009 at 5:42 PM, Brian J. France br...@brianfrance.comwrote: Jari is the original author of mod_dav_acl, which requires patches to httpd to work. I need the same functionality added to httpd to get a mod_dav_acl type module working, so I have split up his patch into smaller pieces. Can a patch be under a different license than the original code? Do you mean, can somebody create a patch to httpd and give the patch a different license than ASL? Or more directly, can we decide what license Jari intended, or be compelled to agree to, for his patch? We don't want to debate that here, as it is missing the point. See wrowe's post from 1-2 hours ago. The author should contribute it to us, etc. If not, we need to remove what was already committed.
