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 -- 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/4c1e4039.6020...@goirand.fr