Note: this post is not about certspotter at all, so I'm not Cc'ing the bug and changed the Subject line. On Wed, Aug 09, 2017 at 05:30:19PM -0400, Jonas Smedegaard wrote: > Stuff like s3cmd are tools connecting to cloud services. Arguably > usable to have tools to free data from the clouds. Which would be a great example of software that is free interacting with software that is non-free. Thus the package with this as its main purpose should live in contrib. There's nothing wrong with that. (Note: I'm not saying s3cmd must be in contrib. It can work with free servers, so it can be in main.) On Thu, Aug 10, 2017 at 12:45:39PM +0200, Philipp Kern wrote: > On 09.08.2017 23:30, Jonas Smedegaard wrote: > > ...but bug#856139 is, I believe, about a tool advertising a cloud > > service which is *not* used by the tool. Instead that cloud service is > > advertised as an option *instead* of installing and using the Free tool. > > > > Anyone having opinions more narrowly on that kind of advertisements? > > And then you go to the bug and you see that it degenerated into a "if it > uses a non-free service, it should go into contrib" subdiscussion. Since > when do we believe that? Neither the DFSG nor the Social Contract would > imply that you need to have a free server for an API client > implementation. Now, I understand that this would be desirable and we > should encourage it but we shouldn't just move goal posts willy-nilly. What seems to be the dispute is whether software that runs on a remote system is still "software" for the purpose of our rules. I think it is, especially considering the trend that almost everything is being moved into the cloud. If this continues, the only thing people will still run locally is their web browser. I believe Debian's philosophy should be that software running remotely on behalf of the user should be considered part of the system and thus free programs interacting with such software should be in contrib if the remote software is non-free (and there is no free alternative). > The only crucial sentence might be this one from §2.2.2 in the policy: > > "The contrib archive area contains supplemental packages intended to > work with the Debian distribution, but which require software outside of > the distribution to either build or function." It seems clear to me that a program which is intended to interact with server software does indeed require that server software to function. So if there is no free implementation of the server, then the client cannot be in main. > The policy isn't something we voted upon. We codify existing practice in our policy. If you think it was a mistake to put this in there, and it needs to be changed, please explain what you believe it should say instead. I don't think this part of policy is controversial at all. > Do people really understand that this means tools calling an API on the > Internet would need to be in contrib? Let's frame that differently: From the point of view of a user who does not want to deal with non-free software, what is the best solution? That user will not have contrib in their sources.list. So should they see an ICQ client? I don't think they should. You can say that it limits them to not be able to use ICQ, and surely they care more about that than about not dealing with non-free software? No, they don't. They specifically asked not to see software that will take them to non-free software, so we should respect their decision and not sneak clients to non-free servers (without free alternatives) into main. Of course there are users who care more about not losing functionality, but those are not the users this is about. Those users have contrib and non-free enabled in their sources.list, and thus they will find this software in contrib. > I don't think I agree with this non-free'ization of Debian. > Stuff like licq never belonged into contrib either, despite its main > purpose back then being to connect to the ICQ (and MSN?) services. If you agree that the main purpose of the program is to interact with non-free software, do you not agree that it requires software outside of main to function? If you do, please propose new wording for policy. Do you want to make an exception for services on the network? I don't think such an exception would serve our users. Those who ask not to see non-free related software should not see clients to non-free services. Does that not make sense to you? > Someone wrote a Free client implementation, hence we should offer it to > our users. Yes, we should. You imply that software in contrib isn't really free. It is! The only difference with software from main is that it cannot properly function in a world where only Debian main is available. If a maintainer or upstream cares about that, they should fix the dependency (by convincing the server upstream to release their code, or by writing a free alternative). And if they don't care about it, they should not be offended when their software is in contrib. This is exactly what contrib is meant for. > I could pull other strawmans like "what about tools that connect to the > telephone network, which is non-free?". Where would we even draw that line? There certainly are debatable situations. There always will be. And the line moves with time: we have different ideas about it than we used to. The main reason for that is that the world has changed as well. More and more software that used to run locally is now offered as online services. When users could use Microsoft Office, we said: that's not-free, please use LibreOffice instead. Now that Microsoft and others are offering the same kind of product on a remote server through a web interface, shouldn't we still make the same argument? This is software that runs on behalf of the user. I don't think Debian should have different rules based on where the hardware that it runs on is located (the local machine or some remote machine). Thanks, Bas
Attachment:
signature.asc
Description: PGP signature