]] 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.
There's nothing in youtube-dl's design that precludes it being used as part of a PHP or CGI script, at which point you'd have the exact similar case as with 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. | > | > 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? No. | 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. This is my point, and I don't see why it should not be considered a valid reason. You consider google evil, many others do not and consider the recaptcha project something that's worth donating some resources to. Just like they consider helping in collaborative spam filtering by using pyzor or razor which also depends on third-party services. | 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. By this reasoning, we should move IM any IM clients that only talk to proprietary servers (MSN, ICQ, etc) to contrib as well. Is that your intention? | 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. Even if we accept the premise that it's a RPC call, you have not explained why an RPC call done by php-recaptcha is fundamentally different from an IM client talking to a proprietary server. | 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. XMPP shows that you don't _need_ a central server to do IM, it's just adding useless complexity because you don't own the code of the MSN server and because MS decided to do it this way. | > 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. Sure. | 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. Why are (or should) remote, non-free data repositories (youtube) fundamentally different from remote, non-free data generation services (recaptcha)? | 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. I'm not aware of us ever having made a statement that no software in Debian depends on third-party services, be they non-free or not. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fx0hmraq....@qurzaw.linpro.no
