Re: ulogd2 commit

[Pablo Neira Ayuso <pablo@netfilter.org>]

Eric Leblond wrote:
> Hi,
> 
> Le vendredi 17 avril 2009 à 12:52 +0200, Pablo Neira Ayuso a écrit :
>> Hi Eric, Pierre,
>>
>> Please, could you justify the need for commit
>> 0ff525cb0506b2c043bc9df6d7e7b486c865bc38?
>>
>> http://git.netfilter.org/cgi-bin/gitweb.cgi?p=ulogd2.git;a=commit;h=0ff525cb0506b2c043bc9df6d7e7b486c865bc38
>>
>> I don't think that it's a good idea to support external compilation of
>> ulogd2 modules. We should promote people to push forward things to mainline.
> 
> I clearly agree with the goal of promoting people to push forward things
> to mainline but it has to be done by openness and reactivity of
> mainteners, not by technical means.
> 
> But let looks at the diffstat of this commit:
>  include/Makefile.am       |    1 +
>  include/ulogd/Makefile.am |    3 +--
>  include/ulogd/ulogd.h     |    2 ++
>  3 files changed, 4 insertions(+), 2 deletions(-)
> 
> That's really not a big work for anyone to arrive to the same result. An
> other point is that compiling outside of tree require you to maintain
> your own build system which is quiet boring.
> 
> Thus, using git to maintain you own forked branch is the easiest way to
> keep your work hidden and/or non public.
> 
> IMHO, this patch does not change anything about external contribution.

1) Looking at my ulogd2 installation, this exports a lot of header files
for external use:

$ ls /usr/include/ulogd/
common.h    hash.h            jhash.h      linux_rbtree.h  timer.h
conffile.h  ipfix_protocol.h  linuxlist.h  slist.h         ulogd.h

Sorry, but this is a bit nasty. If this patch aims to allow compiling
external ulogd2 module,  please make public only the basic functions
(register, unregister, ...) in one header public file called ulogd.h or
something like that. But not exporting all those jhash.h, linux_rbtree.h
and so on.

2) Related to the previous point, if we make public some API, we'll have
to get attached to them to ensure backward compatibility. If we support
external modules, we'll have to engage to not changing the exported API,
otherwise people may complain about breakages of their external modules.
All those files that you have exported means quite a lot APIs that we'll
have to get attached to.

3) I particularly don't want people mixing proprietary external modules
with our GPL code. So, if we export some API, it would be nice if we
have some mechanism to make the user of this functions to explicitly
agree that it's external module is GPL, something like the Linux kernel
macros or something.

I have my concerns with regards to this patch from both the technical
approach and the new policy that it introduces.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html