[php-maint] ITP: php-recaptcha -- PHP interface to recaptcha.net

[Thomas Goirand]

Tollef Fog Heen wrote:
> | 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.
> 
> I don't see how that is fundamentally different from, say, youtube-dl.

Server-to-server connectivity isn't part of the software functionality,
removing it would enhance the software, and that is the fundamental
difference to me.

More in details if anyone didn't get it in a short version: remove any
kind of connectivity to the youtube servers, and youtube-dl has no use,
you can uninstall it from your system. Do the same with something that
does a captcha, then it's great if it continues to work without
connectivity. In fact, for a captcha software, it's *more convenient* if
it doesn't connect to a specific privately owned captcha server at all,
so that way you can run it in a LAN / DMZ. The connection to a server
that holds a part of the code that you will never have access to, is
only removing some freedom, it's not adding any functionality.

> | 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.
> 
> The valid reason is making those text where the captchas come from be
> more accessible.

I'm not 100% sure of what you are saying here, but I'll try to answer
anyway (please be indulgent if I didn't understand you correctly).

So here, you are discussing about the quality of the captchas, right?
Not about my argumentation about recaptcha being a remote procedures /
function / method (take your pick) that should, to me, live on your
local server? If that is the case, then aren't you a bit off-topic, or
am I missing something important?

If your point is about the text that Google is digitizing thanks to
recaptcha, that's off-topic IMHO. If it wasn't off-topic, then I'd say
it's adding some evil, as Google has been quite bad with many book
editors and copyright infringement (which I already wrote btw).

> | If Debian is not the entity to refuse/complain about it, then who will?
> | Do we really care about software freeness? I hope we (as an entity)
> | still do, and I *know* many of us still do.
> 
> Part of software freedom is the no discrimination against fields of
> endeavour bit.

Which is exactly why this was a "P.S" and not in the body of my message.
This is a side note only, and should be considered as such, eg: no
implication on the rest of my freeness reasoning, this was just a
reminder for people not knowing who we are talking about here. This is
also a hidden message saying that rather than spending time packaging
and supporting Google tools they use to own us all (like php-recaptcha),
we'd better focus on 100% free existing tools and enhance them (like
php-text-captcha) so they become even better than the non-free counterpart.

Neil Williams wrote:
> 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).

This is exactly what I believe, and what I wrote as being my 2nd
thought: to me, it should go to contrib, and not to non-free, as it
depends on a remote execution by a library we don't even have a binary for.

Neil Williams wrote:
> 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.

I want to insist here: the captcha generation is a remote procedure /
method / function, absolutely NOT a a service like youtube or instant
messaging, or even (micro-) blogging. Not understanding this point is
not understanding why I am arguing against php-recaptcha to enter Debian
main. Discussing on another point is, IMHO, a bit off-topic (which I
don't mind so much... :) ).

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

No, it's not like a blog client. In fact, I'd be happy if everyone could
understand that there's no client/server thing here. Google is only
giving you access to a function. That function could run on your local
server, totally disconnected from internet, but the recaptcha system
forces you to use a remote code that you don't have access to.

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

I'd rather say: the captcha generation doesn't *need* to be on a remote
server, it's adding useless complexity just because you don't own the
code of recaptcha, and because Google decided to do it this way. More
than what you said, it is unreasonable to use a server-to-server
connectivity when it's not needed.

> This argument, whilst a valid criticism of the package methodology,
> does not impact on whether the package meets DFSG.

Let's say package A needs lib B to work. A is free, while B is not. In
the eyes of Debian, if B is not free, then A goes in contrib. We all
agree on that, this is an established fact and nobody will argue here.

Now, why would it be any different if B is hosted on a server, and you
need to use let's say Corba connectivity (or soap, or XML RPC, or...
php-recaptcha) to use B? While I clearly understand why we need to
connect to services including software that is non-free (youtube, blogs,
IM, etc.), I have serious doubts for using remote libraries.

Nobody has yet convinced me here. If there was no more argumentation,
but the decision was still to accept software with remotely accessed
library dependencies, that would be a serious breach in my trust for
Debian staying 100% free.

Thomas