Quoting Philip Hands (2022-08-23 10:44:55) > Jonas Smedegaard <jonas@jones.dk> writes: > > > Quoting Tobias Frost (2022-08-22 15:57:01) > >> On Mon, Aug 22, 2022 at 07:39:21AM +0200, Simon Josefsson wrote: > >> > Ansgar <ansgar@43-1.org> writes: > >> > > >> > > On Fri, 2022-08-19 at 16:23 +0200, Simon Richter wrote: > >> > >> Do we need to update the Debian Social Contract for that? > >> > >> Specifically paragraph 1, which currently reads > >> > >> > >> > >> Debian will remain 100% free > >> > > > >> > > No. Just like we don't need to update the Debian Social Contract for > >> > > having https://deb.debian.org/debian/pool/non-free/: we just ship > >> > > additional files that might be useful for people having specific > >> > > hardware. > >> > > >> > I disagree -- what is being proposed here is to replace our current > >> > DSC-compatible free software installer images with non-free. That goes > >> > significantly further than what the spirit of DSC§5 suggests. > >> > >> It not being replaced; there are just additional bits in there which > >> help people to actually be able to install Debian on some modern machines. > >> > >> The guarantee in SC1 that we will never *require* those non-free bits, as writen > >> out in "We will never make the system require the use of a non-free component." > >> This GR does not violate this promise. > > > > I understand how we will not require non-free bits getting *installed*. > > > > The way I see it, with this change we will require non-free bits for > > *distribution* of our system, because our official installer will now > > include non-gree bits. > > Would those arguing for the availability of the 100%-free installer find > it acceptable if there was a way of cleansing the non-free bits from the > includes-nonfree-firmware installer images? > > I'd guess that one could put the non-free bits on the end of the image, > as an additional session, or perhaps just mark them in the image, and > then reasonably trivially trim them off, or blank them out. > > We could then generate the firmware-included images, but make the > cleansed ones available on-line by having a server-side script trim out > the non-free bits on the fly. > > If that still makes you feel dirty, because the free bits were once > next-door to some non-free bits, would it make any difference if the > resulting images could be built reproducibly without access to any of > the non-free components? > > I'm mostly asking this to find out where people's lines are, but also in > the hope that we could come up with a compromise that allows us to get > away from the enthusiasm sapping situation where the debian-cd team is > required to make images that they know are sub-optimal for many of our > users. Thanks, Phil, for "reaching out". I view the official Debian install image as a component of Debian, and consequently if the (only) official Debian install image were to contain non-free bits then we would violate DSC#1. It is my understanding that those viewing this move to include non-free bits in the official Debian install image consider the install image *not* one of "its components" as defined in DSC#1. I would find it problematic if the official way to install Debian *required* a non-DFSG image. To clarify: I would *not* find it problematic if an image containing non-free bits were produced and promoted more prominently by us, as long as it would remain *unofficial* - i.e. a DFSG-compliant image would continue to be provided and supported. As I understand it, your first suggestion above (building image with non-free bits but in a way that supports stripping again afterwards) would not address my concern, but the second one might (if actually done officially, but not if offered only as an unofficial option). I hope that my concern is clear, that you recognize it as real (not me being a lunatic), and that we can address the concern in a way that does not burden the debian-cd team. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature