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

[Thomas Goirand]

Hi Ansgar, and thanks for letting us know what you believe.

Ansgar Burchardt wrote:
> Thomas Goirand <thomas at goirand.fr> writes:
> 
>> Please read point 9 of this document:
>>
>> http://people.debian.org/~bap/dfsg-faq.html
>>
>> Because we don't have the source code of the captcha system itself (you
>> only have access to the source code of something that accesses the
>> online service), php-recaptcha fails all of the 3 tests when we want to
>> use it, which is a good indication that it shouldn't be considered
>> free.
> 
> Those tests are intended to be check the license of a software for
> DFSG-freeness. php-recaptcha's license (MIT license) passes all these.

Let's read again the DFSG faq:

"The process involves human judgement. The DFSG is an attempt to
articulate our criteria. But the DFSG is not a contract. This means that
if you think you've found a loophole in the DFSG then you don't quite
understand how this works. The DFSG is a potentially imperfect attempt
to express what free software means to Debian. It is not something whose
letter we argue about. It is not a law. Rather, it is a set of guidelines."

My (human) judgement is that to use php-recaptcha, you need to use a web
service that executes a remote procedure, that you normally wouldn't
need. You are in fact using a bit of software that you don't even have a
binary for. To me, it's worse than even the license of the said
software. If you want to strictly focus on the license of the software
using the service, fine, but I don't think it should be the case, as any
software is only as free as its most non-free dependency. This is
exactly why we have the contrib archive, which is said to not be a part
of the official Debian distribution.

>> As I see it, php-recaptcha should be sent to non-free (which means
>> anything depending on it would go in contrib). I'd be happy to see
>> others expressing themselves here, in order to make sure I don't hold an
>> extreme view on this.
> 
> The DFSG does *not* require that network services that are accessed are
> available under a free license (or that the server software must even be
> included in Debian as well).  There are only requirements on the
> software that Debian distributes itself.

As I just quoted, "the DFSG is a potentially imperfect attempt to
express what free software means to Debian". I believe we are in front
of one of the loop-holes described in the DFSG faq here, and that our
human judgment should have precedence over the word-by-word reading.

> If you do think otherwise, please explain how software licensed under
> one one the licenses explicitly listed as "free" in the DFSG can
> suddenly become non-free.  Which point of the DFSG is no longer
> fulfilled?

Ok, I revise what I said, and now that I have thought about it for a
longer time, I'll express myself with stronger words:

php-recaptcha MUST go to contrib, as it is using a remote procedure that
is not free (even if php-recaptcha itself is free).

I think it makes a lot more sense written this way, right? :)

If you don't agree with this judgment, please explain with a strong
argumentation, why you think having a remotely executed procedure (here,
the captcha image generation) is different from any other non-free
software bit (like for example an non-free library). To me it's even
worse, as things in contrib are depending on non-free softwares that we
store in the non-free archive. Here it wont even be the case as we don't
have the source code for creating the pictures.

> Compare with the various clients for proprietary instant messengers,
> YouTube, other Google services, ...: The server software is not
> available for any of these either.

IMHO, this is irrelevant: let me explain my thoughts.

You are comparing things that should not be compared. But even if you
really want to, it's still not valid. An instant messenger's goal is to
communicate with others. A youtube client's goal is to grab things on
the internet (just like a web browser would). NEVER any of these 2 types
of clients have a part of their code located on a server. Even though
they connect to a server and exchange information, there's no remotely
executed procedures here.

The above software USE a service, yes, but this is because these
services are obviously useless if they aren't online. The purpose of
these clients are to get connected, and interact with the network.
Removing the internet connection makes these kind of software quite useless.

Now, with php-recaptcha, the problem is totally different. A part of the
php-recaptcha software is hosted by a private entity, when there is no
real valid reason why it should. Remove the internet connection, and you
still might need a software that generates captchas. And again, there
are valid alternatives that are doing the exact same thing without using
a proprietary, remotely hosted program.

If you still believe that php-recaptcha is 100% free (and not even a
valid candidate for the contrib repository), please let everyone know,

Thomas