Re: LCC and blobs
Josh Triplett <josh.trip@verizon.net> 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
Reply to: