Peter Van Eynde wrote:
> Brian Thomas Sniffen wrote:
>> Peter Van Eynde <pvaneynd@mailworks.org> 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.
>
> pvaneynd@sharrow:~ :) $ cd /usr/lib/hotplug/firmware/
> pvaneynd@sharrow:/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
> pvaneynd@sharrow:/usr/lib/hotplug/firmware :) $ sudo mkdir t
> pvaneynd@sharrow:/usr/lib/hotplug/firmware :) $ sudo mv * t/
> mv: cannot move `t' to a subdirectory of itself, `t/t'
> pvaneynd@sharrow:/usr/lib/hotplug/firmware :( $ l
> t/
> pvaneynd@sharrow:/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:
> josh@josh-mobile:~$ 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
> josh@josh-mobile:~$ (cd /usr/lib && for x in *curl* ; do sudo mv $x _$x ; done)
> josh@josh-mobile:~$ 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
> josh@josh-mobile:~$ (cd /usr/lib && for x in _*curl* ; do sudo mv $x ${x/_/} ; done)
> josh@josh-mobile:~$ 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
Attachment:
signature.asc
Description: OpenPGP digital signature