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

[Ondřej Surý]

Dear all,

could you take this out of pkg-php-maint? Debian-legal would ve more  
appropriate list to discuss this.

Ondrej Sury

On 20.6.2010, at 18:22, Thomas Goirand <thomas at goirand.fr> wrote:

> 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
>
> _______________________________________________
> pkg-php-maint mailing list
> pkg-php-maint at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-php-maint