[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Changing how we handle non-free firmware



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.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

Attachment: signature.asc
Description: PGP signature


Reply to: