On Sun, 20 Jun 2010 21:47:55 +0800 Thomas Goirand <thomas@goirand.fr> wrote: > I have tried to be as open minded as possible, and asking opinions of > others, and I don't think I am re-interpreting the DFSG here. IMHO, > the debate is all about how to consider the recaptcha service (eg: a > service you connect to, or a remote procedure). Remote procedures alone are not sufficient reason to consider a package using the procedure as non-free - e.g. blog clients use a variety of blog engines, some of which are non-free. > Some made the comparison (like you just did) with IM clients, specific > browsers (like youtube clients and others), but I don't believe this > applies here. To my opinion, I believe this is a remotely executed > procedure, stored on a non-free server that we wont ever control, > which makes php-recaptcha a good candidate for contrib. This is a lot > more complex debate than what you pretend. Blog clients rely on remotely executed procedures. All blog engines are *stored* on a non-free server because servers themselves (as machines) are always non-free if they hope to be secure. ;-) I think what you meant is connecting to a non-free *service* and there are a lot of those which do not preclude packages using them being in main. The difference here is that this procedure is server-to-server not client-to-server. i.e. it is reasonable to expect the service could be available within the one server, albeit with some configuration and the recaptcha service precludes this because the code behind the service is non-free. Relying on one server should be avoided, where possible for obvious SPOF reasons. There's also the potential security implication of executing PHP code which is not within the control of the calling code. If recaptcha.net suffers a cross-site-scripting attack, the reliance on this one server will be a problem for all servers using this package. That has no impact on DFSG but it should be clearly indicated by the package itself (e.g. in the package description) and that the non-free nature of the code on that one server is the reason why the package prevents a fix for such an issue. > writing that I don't think this matches the case of php-recaptcha. We > are talking about a remote procedure on a software, that has no valid > reason to be used as a service, and not embedded on the server that > you use. If you believe that there's a valid reason, I welcome you to > express yourself about it. This argument, whilst a valid criticism of the package methodology, does not impact on whether the package meets DFSG. That is to do with design decisions rather than the status of the final code. Far better would be if this package provided an alternative method which could operate as a fallback. IMHO if this package is to enter Debian at all, it should be in contrib as it relies on a non-free component to operate (so non-free that the component cannot even be packaged for Debian). What happens to this package if recaptcha.net is unavailable or blocked by a firewall? -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpKGnjiHEdRZ.pgp
Description: PGP signature