Josh Triplett <[EMAIL PROTECTED]> writes: > Michael Poole wrote: > > Josh Triplett writes: > >>If the ICQ server were packaged in the Debian non-free section, would > >>you make ICQ clients Depends: or Recommends: on the ICQ server? If not, > >>then if the ICQ server were packaged, the ICQ client would still be in > >>main. Therefore, the ICQ client can be in main. > > > > A, ergo B, ergo A. > > Please explain why you think my argument is circular. I have argued that: > (1) If the ICQ server were packaged in non-free, we still wouldn't make > the client Depends:, Recommends:, or Build-Depends: on the server, and > therefore in that situation the ICQ client could be in main. > (2) For the purposes of deciding if software can be in main in the > presence of possible unexpressed dependencies on external "too free for > non-free" software, we should take the same actions we would if the > non-free software were packaged in non-free and the dependencies were > expressed.
"Depends" and "Build-Depends" are not necessarily the entirety of the Social Contract's idea of dependency. > (3) As a concrete instance of (2), for the purposes of deciding if an > ICQ client can be in main in the presence of possible unexpressed > dependencies on an ICQ server, we should take the actions we would if > the server were packaged in non-free. By (1), that action would be to > leave the ICQ client in main. Therefore we should leave the ICQ client > in main. Your argument is that the ICQ client does not depend on the ICQ server; therefore it is free and can go into main; therefore it does not depend on the ICQ server. > >>In general, Debian doesn't make clients for a network protocol depend on > >>servers for that protocol. I think that's a perfectly reasonable > >>policy, given that you could run the server elsewhere, not on the local > >>machine. > > > > How can I run an ICQ server? Until the answer is "install this > > package from Debian," I believe that the only way to interpret the > > DFSG consistent with your argument is to move the ICQ client to > > contrib. > > Right now, we don't require clients to Depends:, Recommends:, or > Build-Depends: on servers. We don't require drivers to Depends:, Recommends: or Build-Depends: on hardware, either. > >>Similarly, consider if the firmware were packaged in non-free. If the > >>device didn't require the driver to load firmware, the driver would at > >>most Suggests: firmware, and could go to main. If the driver must load > >>the firmware, the driver Depends: or Recommends: firmware, so the driver > >>can't be in main. > > > > This establishes at most an indirect dependency on the firmware: The > > driver depends on the device which depends on the firmware. Since > > Debian cannot express the second dependency, you insist that it > > express "driver depends on firmware." You inconvenience the owner of > > the device simply because their device has a certain characteristic. > > Not at all. The driver uses the request_firmware interface to make > hotplug supply the firmware, and the driver won't work unless the > firmware exists. The hardware is designed to require the driver to load > the firmware. It is the task of the driver to load this firmware, and > the driver cannot perform this task with out the firmware. I don't > believe there is any indirection there; the driver should Depends: > firmware, and it only doesn't because the firmware isn't packaged. > > Are you disagreeing with my argument that the driver would Depends: > firmware if the firmware were packaged, or are you disagreeing with the > idea that we should treat the "firmware too non-free for non-free" case > the same as the "firmware packaged in non-free" case for the purposes of > deciding if the driver goes in main? I disagree that the driver would Depends: on the firmware. > > This is identical to the ICQ case: The client depends on the server > > (service) which depends on the server (software). Debian cannot > > express the second dependency, so following your approach, we must > > insist "client software depends on server software." > > Except that Debian doesn't express the first dependency either, even > when it would be possible to do so. We evidently agree on this point: Debian can express neither the dependency of the driver/client on the device/service nor the dependency of the device/service on the non-free software. As "web applications" and other distributed programs become more common, we will run into more and more problematic divisions between the two endpoints. I believe they should be treated consistently regardless of the communication bus between the Debian software and what it talks to. Michael Poole
