Peter Van Eynde wrote: > Brian Thomas Sniffen wrote: >> Peter Van Eynde <[EMAIL PROTECTED]> writes: >>>[data == software ?] >> >> Bingo. Debian had this debate last year. There was a giant vote over >> it. Then another debate and another vote. > > Hmm. I remember we had an "editorial change" that then turned into
Considering the fact that Debian has always considered "everything on the Debian CDs" to be subject to the DFSG (see Bruce Perens' messages on this topic around the time of the vote, along with agreement from others around at that time), it certainly seems like making that clearly explicit is nothing more than an editorial change. > something completely different, followed by 6 damage limitation options > and 1 hard line option. A damage limitation option won, but I if I read That's not an accurate summary: we had 4 variations on "postpone for Sarge", one "repeal the changes entirely" option, and one "do nothing, the changes apply for Sarge" option. I think that covers both extremes as well as many points in the middle. > the matrix correctly the hard line option was defeated by _every_ damage > limitation clause, so I would not be so certain that "we had this debate". Certainly we did; the votes were for two entirely different purposes. The first stated our position more clearly and unambiguously, and the second said "just because we are making this explicit doesn't mean we have to fix our lax enforcement of it immediately, before releasing Sarge". > Post-sarge we will have the debate and I hope that this time ftp-master > will state the consequences of the options in advance, so there are no > surprises any more. Also having less then 7 options would also be nice. We have already had the debate; we will not have it again post-sarge unless someone decides to raise another GR. Considering that one of the options in the previous GR was "repeal the changes entirely", and that option was at the bottom of the ranking along with the opposite extreme, I think it is quite clear that developers agree with the new social contract. Indeed, the vote before that showed that developers agree with it by more than a 3:1 ratio. :) >>[clarifications] > > I think I'm starting to understand your point of view. So _any_ use of > the software without using non-DFSG data makes it free, right? Within reason, yes. (Linker errors because a library is missing, or similar situations in which the only functionality is to tell you that a piece is missing, don't count.) > But what if loading the firmware is not required? > That if the device was > "warm-booted" in another OS? (I know there are technical limitations > here) Would the driver-firmware relation still be a "depends"? No, then the driver Depends: firmware | other-os . We don't ship either, so the driver still needs to go to contrib. :) And presumably other-os depends (though not in the Debian package sense) on the firmware as well, so even if that other OS was Free and we shipped it, we'd be back to needing the firmware. > Oh, I have another use for the ipw2100 driver without firmware: it can > recognise the card from the pci-id information. :-) To me, that seems much like arguing that because an emulator (such as one for a console system) provides a GUI, and because it can run and display that GUI without needing a ROM, the emulator should go to main. I don't believe that is "a significant amount of functionality". Do you? Feel free to try to convince people. Think about it this way: is that functionality sufficient that if the firmware was Free Software distributed in main, that you would still say the driver should only declare a Recommends or Suggests on the firmware? >> Please at least read Policy on what "Depends" means first. If you > > I see no mention of this in version 3.6.1.1. There is: > |5.6.9. Package interrelationship fields > -> see chapter 7 > |7.2. Binary Dependencies > -> is for debian packages. And has: > |... > |The `Depends' field should be used if the depended-on package is > required |for the depending package to provide a significant amount of > |functionality. > |... > |7.6. Relationships between source and binary packages > ->N/A > > There is no mention of dependency of packages on external data that fall > outside the packaging system. So what meaning do you mean? Dependencies on anything outside of the Debian archive automatically put a package in contrib; see "2.2 Sections". For example, see the packages placed in contrib because they depend on mplayer, despite the fact that mplayer is Free Software (just legally dangerous to package in any useful manner, rather than stripped of much of its useful functionality). > If you extend the rules for packages to firmware then the question > becomes what "significant amount of functionality" is. In the past it > was used for "can run", optional libraries were "Suggest"ed in. > > [EMAIL PROTECTED]:~ :) $ cd /usr/lib/hotplug/firmware/ > [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ ls > ipw2100-1.0.fw ipw2100-1.1-p.fw ipw2100-1.2-p.fw ipw2100-1.3-p.fw > ipw2100-1.1.fw ipw2100-1.2.fw ipw2100-1.3.fw isl3890 > ipw2100-1.1-i.fw ipw2100-1.2-i.fw ipw2100-1.3-i.fw LICENSE > [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo mkdir t > [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo mv * t/ > mv: cannot move `t' to a subdirectory of itself, `t/t' > [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :( $ l > t/ > [EMAIL PROTECTED]:/usr/lib/hotplug/firmware :) $ sudo modprobe -v ipw2100 > insmod > /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ieee80211_crypt.ko > > insmod > /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ieee80211.ko > insmod /lib/modules/2.6.8-1-686/kernel/drivers/base/firmware_class.ko > insmod > /lib/modules/2.6.8-1-686/kernel/drivers/net/wireless/ipw2100/ipw2100.ko > > The module loaded without firmware, not? It detected my card, but failed > to load the firmware. > > ipw2100: Detected Intel PRO/Wireless 2100 Network Connection > ipw2100: eth1: Firmware 'ipw2100-1.3.fw' not available or load failed. > ipw2100: eth1: ipw2100_get_firmware failed: -2 > ipw2100: eth1: Failed to power on the adapter. > ipw2100: eth1: Failed to start the firmware. > ipw2100Error calling regiser_netdev. > ipw2100: probe of 0000:02:02.0 failed with error -5 > > I would say this is a functional driver. It provides me with useful > information about my system. No more functional than a program with a missing library, at least to me: > [EMAIL PROTECTED]:~$ curl http://www.google.com > /dev/null > % Total % Received % Xferd Average Speed Time Time Time > Current > Dload Upload Total Spent Left Speed > 100 2014 0 2014 0 0 7997 0 --:--:-- --:--:-- --:--:-- 99222 > [EMAIL PROTECTED]:~$ (cd /usr/lib && for x in *curl* ; do sudo mv $x _$x ; > done) > [EMAIL PROTECTED]:~$ curl http://www.google.com > /dev/null > curl: error while loading shared libraries: libcurl.so.3: cannot open shared > object file: No such file or directory > [EMAIL PROTECTED]:~$ (cd /usr/lib && for x in _*curl* ; do sudo mv $x ${x/_/} > ; done) > [EMAIL PROTECTED]:~$ curl http://www.google.com > /dev/null > % Total % Received % Xferd Average Speed Time Time Time > Current > Dload Upload Total Spent Left Speed > 100 2014 0 2014 0 0 9868 0 --:--:-- --:--:-- --:--:-- 99222 That provides me with useful information about my system (namely that it is broken because a component is missing), but I certainly don't think it provides "a significant amount of functionality", or really any useful functionality at all. > The fact that I cannot connect to a wifi > lan is the same situation as with grub not being able to load XP without > the XP bootsector, if there were a free firmware with the same API I > would be able to load and use it. I don't think you can equate those two. In the case of Grub, there are many existing Free OSes it could boot, several of which we provide. In the case of this driver, no Free firmware exists, and hypothesizing that one _could_ exist does not allow the package into main, any more than hypothesizing that a Free replacement for some library a contrib package requires would allow that package into main. - Josh Triplett
signature.asc
Description: OpenPGP digital signature
