Anthony DeRobertis wrote: > The social contract says "...but we will never make the system depend on > an item of non-free software." not "but we will never make the system > depend on an item of non-free software /which we must distribute/." > > In order to allow the vast majority of hardware which actually contains > firmware in e.g., EEPROM, we must: > > a. Decide that somehow, the bits in EEPROM are not software. > Personally, this seems dishonest and silly. Every attempt > I've seen to do this somehow make dd into a magic hardware to > software conversion tool. > > b. Use a definition of 'require' like the "if it's on the fs" one > above. Not quite as silly as (a). Would get interesting if > the firmware loading helper I mentioned in another message never > stored the firmware to disk. > > c. Try and find a definition of require based on where the code > runs; however, this gives us a problem with both the BIOS > (sending lilo, grub, etc. to contrib, thus the kernel to contrib, > thus the whole system) and, even if we ignore that, X to contrib > (due to calls to video card BIOSes) and kernel (text console). > > d. Try and find a definition of require which talks about APIs and > abstraction. This would be hard, especially if we decide we want > to consider firmware on disk drivers contrib. > > e. Decide that having a few pieces of software --- hardware drivers > only --- requiring non-free software does not make "the system" > require non-free software, and thus does not violate the SC. > This would require a change to Debian Policy, too. This would > probably let firmware-on-disk drivers back into main (but their > firmware would of course be in non-free, if distributed at all). > > f. Decide to ignore the social contract, and document that, possibly > with an appology. > > g. Amend the social contract. I would like to suggest an additional option, which I think covers most cases quite well: If Debian were to package (a copy of) the non-free item in the non-free section, would the Free package express a Depends, Recommends, or Build-Depends on the non-free package? If so, the Free package should be in contrib. This is the same criteria we already use to prevent packages in main from depending on non-free, with the additional consideration that when the non-free item is so non-free that we can't package it, we should still consider the dependencies of the Free package, which we would express if we could package that non-free item. This criteria covers ICQ clients: if we were to ship an ICQ server, the ICQ client would at most Suggests: icq-server , because it runs non-locally, and you don't need one on your local machine to run a client. This criteria covers driver-loaded firmware: if we could legally ship the firmware, the driver would probably Depends: firmware, or perhaps Recommends: firmware if there is some obscure reason why we believe the user may want to supply a firmware file other than what we ship. This criteria covers firmware burned into the device (possibly reflashable): if we could legally ship the firmware, the driver would at most Suggests: firmware, because although you could certainly flash the firmware on the device, the driver doesn't need the firmware, and neither does the device. This also applies to X and video BIOSes, as well as bootloaders and BIOSes. Please suggest any case which you don't think this criteria adequately covers. The only change required to implement this criteria would be a minor change to Debian Policy: in section 2.2.1 "The main section", in the passage > In addition, the packages in _main_ > * must not require a package outside of _main_ for compilation or > execution (thus, the package must not declare a "Depends", > "Recommends", or "Build-Depends" relationship on a non-_main_ > package), , the parenthetical would need to be updated to make it clear that it still applies even if the dependencies are not expressed because the package is not in the archive. - Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature