Re: Requesting Extension (was: Re: Changing how we handle non-free firmware)

[Jonathan Carter (highvoltage)]

Hi Everyone

On 2022/09/07 18:26, Jonathan Carter (highvoltage) wrote:
As per the Debian Constitution[1] (4.2¶3), I'm requesting an extension 
for the discussion period of 7 days.



Thank you all for taking the time to polish or add voting options over 
the last week. I believe that the options we have available now broadly 
covers the views within the project, which should allow us to make a 
representative vote.


Thanks again!

-Jonathan

Re: Changing how we handle non-free firmware

[Russ Allbery]

Paul Wise  writes:

> Thanks. So it seems B/C/D/NOTA are approximately duplicates,
> except that B/C specify slightly more about non-free presentation.

I think that may be true from the perspective of what Debian is *allowed*
to do, but not in the sense of the guidance that the project is providing
to the team maintaining the installer and the install media.  They're
asking for the project to tell them what to do here, and I think those
options tell them to do different things with respect to how prominant the
non-free installer is on our communication channels.

B says to make the non-free installer the most prominant and recommended
option, C says to make them roughly equivalent, and D says to maintain
something more like the status quo (although possibly with a bit less
"buried in the basement" difficulty in finding the non-free installer).

-- 
Russ Allbery (r...@debian.org)  

Re: Changing how we handle non-free firmware

[Paul Wise]

On Sun, 2022-09-11 at 10:28 +0200, Simon Josefsson wrote:

>  * Would it prevent the current presentation of the non-free installer?
> tl;dr: No
>  * Would it prevent the alternative presentation suggested in
> https://lists.debian.org/msgid-search/683a7c0e69b081aae8c46bd4027bf7537475624a.ca...@debian.org
> tl;dr: No
...
> Linking to the non-free installer from the Debian front page seems
> acceptable (or at least not in direct conflict with the social
> contract), but depending on how it is executed may be poor judgement and
> would give a strange impression of what Debian is about.
...
> So with all these words, my belief is that publications of non-free
> installers are already acceptable under the social contract as long as
> they don't claim to be part of the Debian system, and that it isn't the
> case that the non-free installer is the only installer available.

Thanks. So it seems B/C/D/NOTA are approximately duplicates,
except that B/C specify slightly more about non-free presentation.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Changing how we handle non-free firmware

[Simon Josefsson]

I was asked offlist to answer how Proposal D would affect the display of
the non-free installer on Debian websites, and in particular:

 * Would it prevent the current presentation of the non-free installer?

tl;dr: No

 * Would it prevent the alternative presentation suggested in
   
https://lists.debian.org/msgid-search/683a7c0e69b081aae8c46bd4027bf7537475624a.ca...@debian.org
   ?

tl;dr: No

tl:

Proposal D by itself offers no explicit guidance on these questions.  D
is a NOTA choice to stand by our current foundation documents, allowing
developers to do what they want within those constraints and our usual
conflict resolution processes.

Thus my answer will be my interpretation of what our current policies
already says.  I'm sure others will have (hopefully only slightly)
different interpretations, and I also realize I'm junior when it comes
to these documents and their history and intended interpration.  I'll
try to provide my answer below.  If there is strong disagreement of my
interpretation, more discussion to clarify the situation may help.

The social contract says Debian [system] will always be 100% free.  I
include the installers in the system -- it could be argued that an
installer isn't part of the installed Debian system, but I don't think
that is a useful way of reasoning.  An operating system without any way
to install it is not a operating system, in my opinion, but rather an
academic work or piece of art.

The social contract says some people need non-free works and have
committed to supporting that.  It says that these works is not part of
the Debian system but that Debian still sponsor their existance for
hosting and bug trackers etc.  I don't think the intention was that
there would ever be a non-free installer originally, but there is
explicit acceptance towards non-free works in the Debian project
generally, and a non-free installer would be one example of that.

Now back to the questions.  First, I think the terms "hidden" and
"official" are not that helpful, so I will not use them, and given the
uncertainty about what they mean I suggest we use them less than we do
today.

I don't see any conflict with our social contract for the Debian project
to publish a non-free installer.  However the installer would not be
part of the Debian system, by implication, since that would violate
DSC§1.

The social contract allows the Debian project to publish non-free works
through non-free/contrib areas, so while probably not initially intended
to happen, interested folks could always upload a non-free Debian
installer to non-free and have that be published by Debian.  I don't see
how anyone could object to that, under our current policies.

Linking to the non-free installer from the Debian front page seems
acceptable (or at least not in direct conflict with the social
contract), but depending on how it is executed may be poor judgement and
would give a strange impression of what Debian is about.

To make sense for a user coming to Debian and wondering what we are
about and what we provide, I believe we need to provide a free installer
and that the distinction between the installers are described and
preferably that it is clear that while the non-free installer is not
part of the Debian system, it can be used to install the Debian system.

So with all these words, my belief is that publications of non-free
installers are already acceptable under the social contract as long as
they don't claim to be part of the Debian system, and that it isn't the
case that the non-free installer is the only installer available.

/Simon

Paul Wise  writes:

> On Mon, 2022-08-29 at 21:49 +0100, Steve McIntyre wrote:
>
>> This last bit of wording is slightly unclear to me. Should *Debian* be
>> allowed to distribute an installer or image with non-free software on it?
>
> and if so, how/where should we be allowed to mention/document/promote
> the images containing non-free firmware?
>
> Currently the existing images containing non-free firmware are
> mentioned on the download page linked from the website front page,
> but are labelled "unofficial" and in the "Other Installers" section.
>
> https://www.debian.org/download
>
> The longer older download pages similarly labels the non-free firmware
> images as "unofficial" and mention them at the very end of the page.
>
> https://www.debian.org/distrib/
>
> The even older Debian CD page doesn't mention non-free firmware at all.
>
> https://www.debian.org/CD/
>
> The Debian installation guide has sections on non-free firmware, the
> first one seems to be outdated as it seems to imply the firmware images
> are not possible.
>
> https://www.debian.org/releases/stable/amd64/ch02s02.en.html
> https://www.debian.org/releases/stable/amd64/ch06s04.en.html


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Simon Josefsson]

Bart Martens  writes:

> Yes, let's do that, thanks. So here is the adapted proposal C:
>
> =
>
> The Debian project is permitted to make distribution media (installer images
> and live images) containing non-free software from the Debian archive 
> available
> for download alongside with the free media in a way that the user is informed
> before downloading which media are the free ones.
>
> =

Seconded.

> The modification:
> Old: containing packages from the non-free section of the Debian archive
> New: containing non-free software from the Debian archive
>
> The old phrase was misunderstood as if this proposal would be opposing the
> addition of a new section named non-free-firmware. The new phrase better
> reflects that software in section non-free-firmware is also covered.
>
> Then why not simply mention section non-free-firmware? Well, this proposal is
> meant to be more future proof. This proposal is applicable to an installer
> using the non-free-firmware section, and also to the existing non-free
> installer. And to any future designs of non-free installers.
>
> My subjective comparison of the available proposals so far:
>
> - Proposal A replaces the free installer by one containing non-free firmware.
> - Proposal B gives the free installer less visibility than the non-free one.
> - Proposal C keeps the free installer and no longer hides the non-free ones.
> - Proposal D would be equivalent to NOTA in my understanding.

I see C, D and NOTA as equivalent.  I think the term "hidden" is as
helpful to the discussion as talking about "official" images.  The terms
confuse things rather than clarify.  I believe that anything the Debian
project publishes is official and also not hidden.  Perhaps the only
useful use of "hidden" is when talking about security advisories or
patches under embargo.  I also believe that what the Debian project
publish is a superset of what makes up the Debian system.  What we mean
is probably that the non-free images are hard to find today, but that's
just cosmetics as far as I am concerned.  I find ANY non-x86 installer
image hard to find and "hidden" on the current www.debian.org web page.

/Simon


signature.asc
Description: PGP signature

Re: "official" image terminology Re: Changing how we handle non-free firmware

[Steve McIntyre]

Hey Ross!

On Thu, Sep 08, 2022 at 08:04:24AM -0700, Ross Vandegrift wrote:
>On Thu, Sep 08, 2022 at 11:38:09AM +0200, Simon Josefsson wrote:
>> I don't think the word "official" is defined or used in any foundational
>> document, nor that its meaning is well agreed on or actually helps the
>> discussion.
>
>I had assumed "official" was in more common usage.  It seems like that's
>false.  Since the cloud team uses that term, here's a bit of detail I
>can offer.
>
>The best doc that I know of is here:
>  https://wiki.debian.org/Teams/DPL/OfficialImages
>This tracks Steve's usage from earlier in the thread.  The cloud team
>uses it like this too --- we probably got it from him, back when he was
>on the team.  We also used to have DSA members on the team who seemed
>keen on the term.
>
>So while it doesn't appear in any foundational document, it does have
>traction amongst folks that are affected by these issues.  

Nod. It's been in common use amongst a number of teams over the
years. It's been useful particularly when denoting stuff that is *not*
official but still distributed by various Debian teams - e.g. test
builds or builds including non-free bits. It's been a subject of
discussion with the trademark team in the past, too.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
“Changing random stuff until your program works is bad coding
 practice, but if you do it fast enough it’s Machine Learning.”
   -- https://twitter.com/manisha72617183

"official" image terminology Re: Changing how we handle non-free firmware

[Ross Vandegrift]

On Thu, Sep 08, 2022 at 11:38:09AM +0200, Simon Josefsson wrote:
> I don't think the word "official" is defined or used in any foundational
> document, nor that its meaning is well agreed on or actually helps the
> discussion.

I had assumed "official" was in more common usage.  It seems like that's
false.  Since the cloud team uses that term, here's a bit of detail I
can offer.

The best doc that I know of is here:
  https://wiki.debian.org/Teams/DPL/OfficialImages
This tracks Steve's usage from earlier in the thread.  The cloud team
uses it like this too --- we probably got it from him, back when he was
on the team.  We also used to have DSA members on the team who seemed
keen on the term.

So while it doesn't appear in any foundational document, it does have
traction amongst folks that are affected by these issues.  

That page describes itself as not final - but it's changed little since
2013.  It doesn't offer an opinion on some of the issues being raised
since it just says "the image includes only software available in
Debian".

Hope that's useful,
Ross


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Holger Levsen]

On Wed, Sep 07, 2022 at 08:31:34PM +0200, Bart Martens wrote:
> Yes, let's do that, thanks. So here is the adapted proposal C:
> 
> =
> 
> The Debian project is permitted to make distribution media (installer images
> and live images) containing non-free software from the Debian archive 
> available
> for download alongside with the free media in a way that the user is informed
> before downloading which media are the free ones.
> 
> =
 
seconded, thank you!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

If you liked Corona, you will also enjoy the upcoming global climate disaster.


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Phil Morrell]

On Thu, Sep 08, 2022 at 11:38:09AM +0200, Simon Josefsson wrote:
> Kurt Roeckx  writes:
> > On Tue, Aug 23, 2022 at 10:39:57AM +0200, Simon Josefsson wrote:
> >> Thereby re-inforcing the interpretation that any installer or image with
> >> non-free software on it is not part of the Debian system
> >
> > As you indicate yourself, this is an interpretation of the SC. I would
> > really prefer that such a question was not open to interpretation and
> > that the SC was changed to make it more clear what we mean.
> >
> > I don't actually understand what this part of your text is saying. Are
> > you saying that an image with non-free software on it is non-official
> > because it's not part of the Debian system? That is not something I read
> > in that text.
> 
> I don't think the word "official" is defined or used in any foundational
> document, nor that its meaning is well agreed on or actually helps the
> discussion.  It seems easier to talk about what is considered part of
> the Debian system or not: the foundation documents imply (to me) that
> anything not following DFSG is not part of Debian.  Therefor, an
> installer that includes non-free content would not be part of Debian.
> That does not prevent the project from distributing it, we do that today
> and we distribute non-free/contrib today too without trouble.
> 
> For me it helps to think that what the Debian project ships is a
> superset of what is considered to be the Debian system.

Policy on the other hand is very explicit (perhaps unintentionally):

> The Debian system is maintained and distributed as a collection of packages. 
> The main archive area forms the Debian distribution.

By that definition, no installation media are part of the Debian system
and so are already permitted to use non-free components? Obviously
Policy is "lower" in interpretation value that Constitution or Social
Contract. It also has a note about "component", and I'd point out the
term "section" is often used too (see rewording of Proposal C).

> The Debian archive software uses the term “component” internally and
> in the Release file format to refer to the division of an archive. The
> Debian Social Contract simply refers to “areas.” This document uses
> terminology similar to the Social Contract.


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Simon Josefsson]

Kurt Roeckx  writes:

> On Tue, Aug 23, 2022 at 10:39:57AM +0200, Simon Josefsson wrote:
>> As far as I can tell, both Steve's and Gunnar's proposal would make
>> Debian less of a free software operating system than it is today.  That
>> makes me sad.  My preference for an outcome would be along the following
>> lines.
>> 
>> ==
>> 
>> We continue to stand by the spirit of the Debian Social Contract §1
>> which says:
>> 
>>Debian will remain 100% free
>> 
>>We provide the guidelines that we use to determine if a work is
>>"free" in the document entitled "The Debian Free Software
>>Guidelines". We promise that the Debian system and all its components
>>will be free according to these guidelines. We will support people
>>who create or use both free and non-free works on Debian. We will
>>never make the system require the use of a non-free component.
>> 
>> Therefor we will not include any non-free software in Debian, nor in the
>> main archive or installer/live/cloud or other official images, and will
>> not enable anything from non-free or contrib by default.
>
> I can interprete that as having non-free available and installed by default
> is acceptable, as long as there is a way not to use the non-free part.

Sounds right, if I understand what you mean correctly.

>> We also continue to stand by the spirit of the Debian Social Contract §5
>> which says:
>> 
>>Works that do not meet our free software standards
>> 
>>We acknowledge that some of our users require the use of works that
>>do not conform to the Debian Free Software Guidelines. We have
>>created "contrib" and "non-free" areas in our archive for these
>>works. The packages in these areas are not part of the Debian system,
>>although they have been configured for use with Debian. We encourage
>>CD manufacturers to read the licenses of the packages in these areas
>>and determine if they can distribute the packages on their CDs. Thus,
>>although non-free works are not a part of Debian, we support their
>>use and provide infrastructure for non-free packages (such as our bug
>>tracking system and mailing lists).
>> 
>> Thereby re-inforcing the interpretation that any installer or image with
>> non-free software on it is not part of the Debian system, but that we
>> support their use and welcome others to distribute such work.
>
> As you indicate yourself, this is an interpretation of the SC. I would
> really prefer that such a question was not open to interpretation and
> that the SC was changed to make it more clear what we mean.

Agreed.  I believe both Steve's and Gunnar's proposals both assume a
particular interpretation of the DSC (and one that I disagree with), but
it is not explicit in the proposal.

> I don't actually understand what this part of your text is saying. Are
> you saying that an image with non-free software on it is non-official
> because it's not part of the Debian system? That is not something I read
> in that text.

I don't think the word "official" is defined or used in any foundational
document, nor that its meaning is well agreed on or actually helps the
discussion.  It seems easier to talk about what is considered part of
the Debian system or not: the foundation documents imply (to me) that
anything not following DFSG is not part of Debian.  Therefor, an
installer that includes non-free content would not be part of Debian.
That does not prevent the project from distributing it, we do that today
and we distribute non-free/contrib today too without trouble.

For me it helps to think that what the Debian project ships is a
superset of what is considered to be the Debian system.

> I would also like to point out that the Secretary has the power to
> adjudicates any disputes about interpretation of the constitution, but
> not about the foundation documents.

How are disagreements over foundation documents handled in Debian?

/Simon


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Stefano Zacchiroli]

On Wed, Sep 07, 2022 at 08:31:34PM +0200, Bart Martens wrote:
> Yes, let's do that, thanks. So here is the adapted proposal C:
> 
> =
> 
> The Debian project is permitted to make distribution media (installer images
> and live images) containing non-free software from the Debian archive 
> available
> for download alongside with the free media in a way that the user is informed
> before downloading which media are the free ones.
> 
> =

Not sure if at this stage you need re-seconds from people who seconded
the original version, but just in case:

Seconded.

-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack  _. ^ ._
Full professor of Computer Science  o o   o \/|V|\/
Télécom Paris, Polytechnic Institute of Paris o o o   <\>
Co-founder & CTO Software Heritageo o o o   /\|^|/\
Former Debian Project Leader & OSI Board Director   '" V "'


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Paul Wise]

On Wed, 2022-09-07 at 20:31 +0200, Bart Martens wrote:

> The Debian project is permitted to make distribution media (installer images
> and live images) containing non-free software from the Debian archive 
> available
> for download alongside with the free media in a way that the user is informed
> before downloading which media are the free ones.

Seconded.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Changing how we handle non-free firmware

[Steve McIntyre]

On Wed, Sep 07, 2022 at 08:31:34PM +0200, Bart Martens wrote:
>On Tue, Sep 06, 2022 at 11:00:25PM +0200, Kurt Roeckx wrote:
>> I think the problem is with "non-free section". I think Steve looks at
>> that like the non-free-firmware section is now allowed. I suggest you
>s/now/not/
>> just rewrite it as: "containing non-free software from the Debian
>> archive".
>
>Hi Kurt,
>
>Yes, let's do that, thanks. So here is the adapted proposal C:
>
>=
>
>The Debian project is permitted to make distribution media (installer images
>and live images) containing non-free software from the Debian archive available
>for download alongside with the free media in a way that the user is informed
>before downloading which media are the free ones.
>
>=

Thanks Bart, I'm much happier with this.

Seconded.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I used to be the first kid on the block wanting a cranial implant,
 now I want to be the first with a cranial firewall. " -- Charlie Stross


signature.asc
Description: PGP signature

Re: Requesting Extension (was: Re: Changing how we handle non-free firmware)

[Steve McIntyre]

On Wed, Sep 07, 2022 at 06:26:29PM +0200, Jonathan Carter (highvoltage) wrote:
>Dear Debian Secretary and Debian Developers
>
>As per the Debian Constitution[1] (4.2¶3), I'm requesting an extension for
>the discussion period of 7 days.
>
>Apologies for jumping this on the last minute, I've been off-sick and have
>been fiercely triaging and catching up with issues the last day or so.
>
>My rationale is that we have some unresolved issues that I think would be
>prudent to consider before the vote.

Thanks Jonathan!

Let's make good use of the extra time to fine-tine the ballot.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< Aardvark> I dislike C++ to start with. C++11 just seems to be
handing rope-creating factories for users to hang multiple
instances of themselves.


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Steve McIntyre]

On Wed, Sep 07, 2022 at 08:24:33AM +0200, Bart Martens wrote:
>On Tue, Sep 06, 2022 at 11:00:25PM +0200, Kurt Roeckx wrote:
>> 
>> I think the problem is with "non-free section". I think Steve looks at
>> that like the non-free-firmware section is now allowed. I suggest you
>> just rewrite it as: "containing non-free software from the Debian
>> archive".
>
>Steve, would this idea from Kurt bring you back?

Yes, that's much better.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Managing a volunteer open source project is a lot like herding
 kittens, except the kittens randomly appear and disappear because they
 have day jobs." -- Matt Mackall


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Laura Arjona Reina]

Hello

El 7/9/22 a las 20:31, Bart Martens escribió:

On Tue, Sep 06, 2022 at 11:00:25PM +0200, Kurt Roeckx wrote:

I think the problem is with "non-free section". I think Steve looks at
that like the non-free-firmware section is now allowed. I suggest you

s/now/not/

just rewrite it as: "containing non-free software from the Debian
archive".

Hi Kurt,

Yes, let's do that, thanks. So here is the adapted proposal C:

=

The Debian project is permitted to make distribution media (installer images
and live images) containing non-free software from the Debian archive available
for download alongside with the free media in a way that the user is informed
before downloading which media are the free ones.

=


Seconded.

Thanks for making the update.

Kind regards,

--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona



OpenPGP_signature
Description: OpenPGP digital signature

Re: Changing how we handle non-free firmware

[Jonas Smedegaard]

Quoting Bart Martens (2022-09-07 20:31:34)
> On Tue, Sep 06, 2022 at 11:00:25PM +0200, Kurt Roeckx wrote:
> > I think the problem is with "non-free section". I think Steve looks at
> > that like the non-free-firmware section is now allowed. I suggest you
> s/now/not/
> > just rewrite it as: "containing non-free software from the Debian
> > archive".
> 
> Hi Kurt,
> 
> Yes, let's do that, thanks. So here is the adapted proposal C:
> 
> =
> 
> The Debian project is permitted to make distribution media (installer images
> and live images) containing non-free software from the Debian archive 
> available
> for download alongside with the free media in a way that the user is informed
> before downloading which media are the free ones.
> 
> =
> 
> The modification:
> Old: containing packages from the non-free section of the Debian archive
> New: containing non-free software from the Debian archive
> 
> The old phrase was misunderstood as if this proposal would be opposing the
> addition of a new section named non-free-firmware. The new phrase better
> reflects that software in section non-free-firmware is also covered.
> 
> Then why not simply mention section non-free-firmware? Well, this proposal is
> meant to be more future proof. This proposal is applicable to an installer
> using the non-free-firmware section, and also to the existing non-free
> installer. And to any future designs of non-free installers.
> 
> My subjective comparison of the available proposals so far:
> 
> - Proposal A replaces the free installer by one containing non-free firmware.
> - Proposal B gives the free installer less visibility than the non-free one.
> - Proposal C keeps the free installer and no longer hides the non-free ones.
> - Proposal D would be equivalent to NOTA in my understanding.
> 
> Proposal C could use some more seconding. If you find that proposal C is a
> valid option on the ballot (regardless of what you'll later vote for), then
> you're most welcome to add your seconding.

Seconded.

Thanks!

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Changing how we handle non-free firmware

[Bart Martens]

On Tue, Sep 06, 2022 at 11:00:25PM +0200, Kurt Roeckx wrote:
> I think the problem is with "non-free section". I think Steve looks at
> that like the non-free-firmware section is now allowed. I suggest you
s/now/not/
> just rewrite it as: "containing non-free software from the Debian
> archive".

Hi Kurt,

Yes, let's do that, thanks. So here is the adapted proposal C:

=

The Debian project is permitted to make distribution media (installer images
and live images) containing non-free software from the Debian archive available
for download alongside with the free media in a way that the user is informed
before downloading which media are the free ones.

=

The modification:
Old: containing packages from the non-free section of the Debian archive
New: containing non-free software from the Debian archive

The old phrase was misunderstood as if this proposal would be opposing the
addition of a new section named non-free-firmware. The new phrase better
reflects that software in section non-free-firmware is also covered.

Then why not simply mention section non-free-firmware? Well, this proposal is
meant to be more future proof. This proposal is applicable to an installer
using the non-free-firmware section, and also to the existing non-free
installer. And to any future designs of non-free installers.

My subjective comparison of the available proposals so far:

- Proposal A replaces the free installer by one containing non-free firmware.
- Proposal B gives the free installer less visibility than the non-free one.
- Proposal C keeps the free installer and no longer hides the non-free ones.
- Proposal D would be equivalent to NOTA in my understanding.

Proposal C could use some more seconding. If you find that proposal C is a
valid option on the ballot (regardless of what you'll later vote for), then
you're most welcome to add your seconding.

Cheers,

Bart



signature.asc
Description: PGP signature

Requesting Extension (was: Re: Changing how we handle non-free firmware)

[Jonathan Carter (highvoltage)]

Dear Debian Secretary and Debian Developers

As per the Debian Constitution[1] (4.2¶3), I'm requesting an extension 
for the discussion period of 7 days.


Apologies for jumping this on the last minute, I've been off-sick and 
have been fiercely triaging and catching up with issues the last day or so.


My rationale is that we have some unresolved issues that I think would 
be prudent to consider before the vote.


For one, some of the options may put some pressure on individuals or 
teams to implement some features at the wish of the project. We've 
already had (and even recently) situations like this that caused a lot 
of friction. So, I believe it would be worth while to discuss how we 
want to treat this specifically for the next releases. What happens if 
we decide on an option for Bookworm, and the implementation is nowhere 
ready by, say, August next year, do we delay the release? Or aim for 
Bookworm but make it RC for Trixie? Even if we have some consensus about 
how to address that and the details don't make it in the actual vote, it 
would still be an improvement.


Other than that, we may have to accept the fact that this GR won't be 
(and possibly can't be) perfect and that we'll have to apply some 
touch-ups based on our experiences and further conclusions based on 
that, and improve upon it again by another GR some time in the future. 
In the meantime, I think another week of polish will be worth it over 
the bookworm release cycle, and I'm glad that this topic is at least 
moving forward and that we get to make some choices together as a 
project regarding firmware.


Thanks for understanding,

-Jonathan

[1] https://www.debian.org/devel/constitution

On 2022/08/18 21:58, Steve McIntyre wrote:

Hi a11!

I'm proposing to change how we handle non-free firmware in
Debian. I've written about this a few times already this year [1, 2]
and I ran a session on the subject at DebConf [3].
 
TL;DR: The way we deal with (non-free) firmware in Debian isn't

great. For a long time we've got away without supporting and including
(non-free) firmware on Debian systems. We don't *want* to have to
provide (non-free) firmware to our users, and in an ideal world we
wouldn't need to. However, it's no longer a sensible path when trying
to support lots of common current hardware. Increasingly, modern
computers don't function fully without these firmware blobs.

Since I started talking abbout this, Ansgar has already added dak
support for a new, separate non-free-firmware component - see
[4]. This makes part of my original proposal moot! More work is needed
yet to make use of this support, but it's started! :-)

I believe that there is reasonably wide support for changing what we
do with non-free firmware. I see several possible paths forward, but
as I've stated previously I don't want to be making the decision
alone. I believe that the Debian project as a whole needs to make the
decision on which path is the correct one.

I'm *not* going to propose full text for all the possible choices
here; as eloquently suggested by Russ [5], it's probably better to
leave it for other people to come up with the text of options that
they feel should also be on the ballot.

So, I propose the following:

=

We will include non-free firmware packages from the
"non-free-firmware" section of the Debian archive on our official
media (installer images and live images). The included firmware
binaries will *normally* be enabled by default where the system
determines that they are required, but where possible we will include
ways for users to disable this at boot (boot menu option, kernel
command line etc.).

When the installer/live system is running we will provide information
to the user about what firmware has been loaded (both free and
non-free), and we will also store that information on the target
system such that users will be able to find it later. The target
system will *also* be configured to use the non-free-firmware
component by default in the apt sources.list file. Our users should
receive security updates and important fixes to firmware binaries just
like any other installed software.

We will publish these images as official Debian media, replacing the
current media sets that do not include non-free firmware packages.

=

A reason for defaulting to installing non-free firmware *by default*
is accessibility. A blind user running the installer in text-to-speech
mode may need audio firmware loaded to be able to drive the installer
at all. It's going to be very difficult for them to change this. Other
people should be able to drive the system (boot menus, etc.) to *not*
install the non-free firmware packages if desired.

We will *only* include the non-free-firmware component on our media
and on installed systems by default. As a general policy, we still do
not want to see other non-free software in use. Users may still enable
the existing non-free component 

Re: Changing how we handle non-free firmware

[Bart Martens]

On Tue, Sep 06, 2022 at 11:00:25PM +0200, Kurt Roeckx wrote:
> On Tue, Sep 06, 2022 at 08:33:51PM +0200, Bart Martens wrote:
> > On Tue, Sep 06, 2022 at 05:26:10PM +0100, Steve McIntyre wrote:
> > > On Tue, Sep 06, 2022 at 06:15:21PM +0200, Bart Martens wrote:
> > > >On Sun, Sep 04, 2022 at 03:43:36AM +0700, Judit Foglszinger wrote:
> > > >> > I hereby propose the following alternative text to Steve's original 
> > > >> > proposal.
> > > >> > 
> > > >> > =
> > > >> > 
> > > >> > The Debian project is permitted to make distribution media 
> > > >> > (installer images
> > > >> > and live images) containing packages from the non-free section of 
> > > >> > the Debian
> > > >> > archive available for download alongside with the free media in a 
> > > >> > way that the
> > > >> > user is informed before downloading which media are the free ones.
> > > >> > 
> > > >> > =
> > > >> 
> > > >> Wondering if this should be s/non-free section/non-free-firmware 
> > > >> section/
> > > >
> > > >Thanks for asking. The short answer is no. I kept my proposal very short,
> > > >keeping the focus on the smallest possible action we can do for helping 
> > > >those
> > > >users that need non-free firmware: allowing ourselves to advertise 
> > > >non-free
> > > >installers just as visible as our free installer. Moving non-free 
> > > >firmware to a
> > > >separate section might be useful, but it is in my view not part of that
> > > >smallest possible action. So what's my position on such new section? 
> > > >Well, what
> > > >is not mentioned is not proposed and not opposed. That's all. - B.
> > > 
> > > Argh. So this does *not* work with the plan that we have *already
> > > started*, where we're going to move firmware things to
> > > non-free-firmware instead. Please switch to "non-free and/or
> > > non-free-firmware sections" in your text.
> > 
> > I'm surprised. Please read what is written. Proposal C leaves open whether 
> > such
> > new section would be added in the future. So if proposal C would win, then 
> > the
> > started work you describe can continue. Proposal C uses the term "non-free"
> > because that is where all non-free packages are still residing today.
> 
> I think the problem is with "non-free section". I think Steve looks at
> that like the non-free-firmware section is now allowed. I suggest you
> just rewrite it as: "containing non-free software from the Debian
> archive".

Steve, would this idea from Kurt bring you back?

> 
> 
> Kurt
> 

-- 

Re: Changing how we handle non-free firmware

[Jonas Smedegaard]

Quoting Bart Martens (2022-09-07 00:27:40)
> On Tue, Sep 06, 2022 at 11:00:25PM +0200, Kurt Roeckx wrote:
> > On Tue, Sep 06, 2022 at 08:33:51PM +0200, Bart Martens wrote:
> > > On Tue, Sep 06, 2022 at 05:26:10PM +0100, Steve McIntyre wrote:
> > > > On Tue, Sep 06, 2022 at 06:15:21PM +0200, Bart Martens wrote:
> > > > >On Sun, Sep 04, 2022 at 03:43:36AM +0700, Judit Foglszinger wrote:
> > > > >> > I hereby propose the following alternative text to Steve's 
> > > > >> > original proposal.
> > > > >> > 
> > > > >> > =
> > > > >> > 
> > > > >> > The Debian project is permitted to make distribution media 
> > > > >> > (installer images
> > > > >> > and live images) containing packages from the non-free section of 
> > > > >> > the Debian
> > > > >> > archive available for download alongside with the free media in a 
> > > > >> > way that the
> > > > >> > user is informed before downloading which media are the free ones.
> > > > >> > 
> > > > >> > =
> > > > >> 
> > > > >> Wondering if this should be s/non-free section/non-free-firmware 
> > > > >> section/
> > > > >
> > > > >Thanks for asking. The short answer is no. I kept my proposal very 
> > > > >short,
> > > > >keeping the focus on the smallest possible action we can do for 
> > > > >helping those
> > > > >users that need non-free firmware: allowing ourselves to advertise 
> > > > >non-free
> > > > >installers just as visible as our free installer. Moving non-free 
> > > > >firmware to a
> > > > >separate section might be useful, but it is in my view not part of that
> > > > >smallest possible action. So what's my position on such new section? 
> > > > >Well, what
> > > > >is not mentioned is not proposed and not opposed. That's all. - B.
> > > > 
> > > > Argh. So this does *not* work with the plan that we have *already
> > > > started*, where we're going to move firmware things to
> > > > non-free-firmware instead. Please switch to "non-free and/or
> > > > non-free-firmware sections" in your text.
> > > 
> > > I'm surprised. Please read what is written. Proposal C leaves open 
> > > whether such
> > > new section would be added in the future. So if proposal C would win, 
> > > then the
> > > started work you describe can continue. Proposal C uses the term 
> > > "non-free"
> > > because that is where all non-free packages are still residing today.
> > 
> > I think the problem is with "non-free section". I think Steve looks at
> > that like the non-free-firmware section is now allowed.
>  not
> 
> He wants "non-free-firmware section" mentioned in proposal C, see above.
> 
> > I suggest you
> > just rewrite it as: "containing non-free software from the Debian
> > archive".
> 
> That would indeed leave out the existing section name. I'll consider it.

If the purpose of this option is to not shift where the line is drawn
regading Debian understanding of what is Free and what is not, then I
suggest a "slightly" different wording of "containing software that is
free according to The Debian Free Software Guidelines".

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Changing how we handle non-free firmware

[Bart Martens]

On Tue, Sep 06, 2022 at 11:00:25PM +0200, Kurt Roeckx wrote:
> On Tue, Sep 06, 2022 at 08:33:51PM +0200, Bart Martens wrote:
> > On Tue, Sep 06, 2022 at 05:26:10PM +0100, Steve McIntyre wrote:
> > > On Tue, Sep 06, 2022 at 06:15:21PM +0200, Bart Martens wrote:
> > > >On Sun, Sep 04, 2022 at 03:43:36AM +0700, Judit Foglszinger wrote:
> > > >> > I hereby propose the following alternative text to Steve's original 
> > > >> > proposal.
> > > >> > 
> > > >> > =
> > > >> > 
> > > >> > The Debian project is permitted to make distribution media 
> > > >> > (installer images
> > > >> > and live images) containing packages from the non-free section of 
> > > >> > the Debian
> > > >> > archive available for download alongside with the free media in a 
> > > >> > way that the
> > > >> > user is informed before downloading which media are the free ones.
> > > >> > 
> > > >> > =
> > > >> 
> > > >> Wondering if this should be s/non-free section/non-free-firmware 
> > > >> section/
> > > >
> > > >Thanks for asking. The short answer is no. I kept my proposal very short,
> > > >keeping the focus on the smallest possible action we can do for helping 
> > > >those
> > > >users that need non-free firmware: allowing ourselves to advertise 
> > > >non-free
> > > >installers just as visible as our free installer. Moving non-free 
> > > >firmware to a
> > > >separate section might be useful, but it is in my view not part of that
> > > >smallest possible action. So what's my position on such new section? 
> > > >Well, what
> > > >is not mentioned is not proposed and not opposed. That's all. - B.
> > > 
> > > Argh. So this does *not* work with the plan that we have *already
> > > started*, where we're going to move firmware things to
> > > non-free-firmware instead. Please switch to "non-free and/or
> > > non-free-firmware sections" in your text.
> > 
> > I'm surprised. Please read what is written. Proposal C leaves open whether 
> > such
> > new section would be added in the future. So if proposal C would win, then 
> > the
> > started work you describe can continue. Proposal C uses the term "non-free"
> > because that is where all non-free packages are still residing today.
> 
> I think the problem is with "non-free section". I think Steve looks at
> that like the non-free-firmware section is now allowed.
 not

He wants "non-free-firmware section" mentioned in proposal C, see above.

> I suggest you
> just rewrite it as: "containing non-free software from the Debian
> archive".

That would indeed leave out the existing section name. I'll consider it.

> 
> 
> Kurt
> 

Re: Changing how we handle non-free firmware

[Steve McIntyre]

On Tue, Sep 06, 2022 at 11:56:23PM +0200, Bart Martens wrote:
>On Tue, Sep 06, 2022 at 08:25:44PM +0100, Steve McIntyre wrote:
>> 
>> No, it doesn't.
>
>> Your words may cover where those packages are *today*,
>
>Exactly.
>
>> but they most likely will *not* be in "non-free" when we come to make
>> the changes. "non-free-firmware" != "non-free".
>
>I understood that part.
>
>> Please tweak your
>> wording to be more flexible and cover what we're aiming to do.
>
>I think we have a different view on which proposal is the most flexible. And I
>understand that you want my proposal to cover what you are aiming at.

Bart, I genuinely don't understand why you're so wedded to this
specific wording even after multiple people have tried to explain the
problems they see here. Do you have a particular beef with the
non-free-firmware section?

As written, I believe your ballot option will cause more confusion and
problems down the line. Therefore, regretfully I have to withdraw my
seconding of your ballot option.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Getting a SCSI chain working is perfectly simple if you remember that there
  must be exactly three terminations: one on one end of the cable, one on the
  far end, and the goat, terminated over the SCSI chain with a silver-handled
  knife whilst burning *black* candles. --- Anthony DeBoer


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Bart Martens]

On Tue, Sep 06, 2022 at 08:25:44PM +0100, Steve McIntyre wrote:
> On Tue, Sep 06, 2022 at 08:33:51PM +0200, Bart Martens wrote:
> >On Tue, Sep 06, 2022 at 05:26:10PM +0100, Steve McIntyre wrote:
> >> On Tue, Sep 06, 2022 at 06:15:21PM +0200, Bart Martens wrote:
> >> >On Sun, Sep 04, 2022 at 03:43:36AM +0700, Judit Foglszinger wrote:
> >> >> > I hereby propose the following alternative text to Steve's original 
> >> >> > proposal.
> >> >> > 
> >> >> > =
> >> >> > 
> >> >> > The Debian project is permitted to make distribution media (installer 
> >> >> > images
> >> >> > and live images) containing packages from the non-free section of the 
> >> >> > Debian
> >> >> > archive available for download alongside with the free media in a way 
> >> >> > that the
> >> >> > user is informed before downloading which media are the free ones.
> >> >> > 
> >> >> > =
> >> >> 
> >> >> Wondering if this should be s/non-free section/non-free-firmware 
> >> >> section/
> >> >
> >> >Thanks for asking. The short answer is no. I kept my proposal very short,
> >> >keeping the focus on the smallest possible action we can do for helping 
> >> >those
> >> >users that need non-free firmware: allowing ourselves to advertise 
> >> >non-free
> >> >installers just as visible as our free installer. Moving non-free 
> >> >firmware to a
> >> >separate section might be useful, but it is in my view not part of that
> >> >smallest possible action. So what's my position on such new section? 
> >> >Well, what
> >> >is not mentioned is not proposed and not opposed. That's all. - B.
> >> 
> >> Argh. So this does *not* work with the plan that we have *already
> >> started*, where we're going to move firmware things to
> >> non-free-firmware instead. Please switch to "non-free and/or
> >> non-free-firmware sections" in your text.
> >
> >I'm surprised. Please read what is written. Proposal C leaves open whether 
> >such
> >new section would be added in the future. So if proposal C would win, then 
> >the
> >started work you describe can continue. Proposal C uses the term "non-free"
> >because that is where all non-free packages are still residing today.
> >
> >Does this cover your concern?
> 
> No, it doesn't.

> Your words may cover where those packages are *today*,

Exactly.

> but they most likely will *not* be in "non-free" when we come to make
> the changes. "non-free-firmware" != "non-free".

I understood that part.

> Please tweak your
> wording to be more flexible and cover what we're aiming to do.

I think we have a different view on which proposal is the most flexible. And I
understand that you want my proposal to cover what you are aiming at.

> 
> -- 
> Steve McIntyre, Cambridge, UK.st...@einval.com
> "This dress doesn't reverse." -- Alden Spiess

Re: supermajority requirements and their inheritance (was: Re: Changing how we handle non-free firmware)

[Richard Laager]

On 9/6/22 01:09, Ansgar wrote:

You can argue that the developers making the installer and live images,
and those maintaining the website can make those decisions. You can even
say that they have made decisions. So those options could be seen as
overriding a Developer, using the power of the Technical Committee.

Assuming we actually went that way, 6.1.4 requires a 3:1 majority, but
4.1.4 only a 2:1 majority. I think we take the highest majority
requirement in that case, so 3:1.


I also disagree with the idea that a GR would require 3:1 to exercise a 
TC power. I'll try to illustrate that two different ways...


Imagine that 6.1.4 said the TC was required to be unanimous to overrule 
a Developer. It would not make sense to say that the Developers 
collectively had to be unanimous to exercise that power. 4.1.4 is the 
one relevant for a GR.



I think it is bad to transfer supermajority requirements among one
group of voters (tech-ctte) to a very different group of voters (all
DD).


Agreed.


Though I agree the constitution is not clear on this.

I personally think it's clear. Here's how I would look at it:

Overriding a Developer is a power of the TC. (6.1.4)

The TC exercises that power by committee vote 3:1. (6.1.4)

The Developers exercise that power by GR vote 2:1. (4.1.4)


It might be better to just get rid of both supermajority requirements:
if 50% of all DDs agree on some implementation detail, it's probably
fine to do it that way.


I happen to agree (at least in the case of removing the 2:1 from 4.1.4, 
less sure about the other), but that'd be a separate GR to change.


--
Richard


OpenPGP_signature
Description: OpenPGP digital signature

Re: Changing how we handle non-free firmware

[Kurt Roeckx]

On Tue, Sep 06, 2022 at 08:33:51PM +0200, Bart Martens wrote:
> On Tue, Sep 06, 2022 at 05:26:10PM +0100, Steve McIntyre wrote:
> > On Tue, Sep 06, 2022 at 06:15:21PM +0200, Bart Martens wrote:
> > >On Sun, Sep 04, 2022 at 03:43:36AM +0700, Judit Foglszinger wrote:
> > >> > I hereby propose the following alternative text to Steve's original 
> > >> > proposal.
> > >> > 
> > >> > =
> > >> > 
> > >> > The Debian project is permitted to make distribution media (installer 
> > >> > images
> > >> > and live images) containing packages from the non-free section of the 
> > >> > Debian
> > >> > archive available for download alongside with the free media in a way 
> > >> > that the
> > >> > user is informed before downloading which media are the free ones.
> > >> > 
> > >> > =
> > >> 
> > >> Wondering if this should be s/non-free section/non-free-firmware section/
> > >
> > >Thanks for asking. The short answer is no. I kept my proposal very short,
> > >keeping the focus on the smallest possible action we can do for helping 
> > >those
> > >users that need non-free firmware: allowing ourselves to advertise non-free
> > >installers just as visible as our free installer. Moving non-free firmware 
> > >to a
> > >separate section might be useful, but it is in my view not part of that
> > >smallest possible action. So what's my position on such new section? Well, 
> > >what
> > >is not mentioned is not proposed and not opposed. That's all. - B.
> > 
> > Argh. So this does *not* work with the plan that we have *already
> > started*, where we're going to move firmware things to
> > non-free-firmware instead. Please switch to "non-free and/or
> > non-free-firmware sections" in your text.
> 
> I'm surprised. Please read what is written. Proposal C leaves open whether 
> such
> new section would be added in the future. So if proposal C would win, then the
> started work you describe can continue. Proposal C uses the term "non-free"
> because that is where all non-free packages are still residing today.

I think the problem is with "non-free section". I think Steve looks at
that like the non-free-firmware section is now allowed. I suggest you
just rewrite it as: "containing non-free software from the Debian
archive".


Kurt

Re: Changing how we handle non-free firmware

[Judit Foglszinger]

> > > =
> > > 
> > > The Debian project is permitted to make distribution media (installer 
> > > images
> > > and live images) containing packages from the non-free section of the 
> > > Debian
> > > archive available for download alongside with the free media in a way 
> > > that the
> > > user is informed before downloading which media are the free ones.
> > > 
> > > =
> > 
> > Wondering if this should be s/non-free section/non-free-firmware section/
> 
> Thanks for asking. The short answer is no. I kept my proposal very short,
> keeping the focus on the smallest possible action we can do for helping those
> users that need non-free firmware

Thanks for your answer.

What about not mentioning archive area and explicitly referring to firmware 
instead?

"The Debian project is permitted to make distribution media (installer images
and live images) containing packages with non DFSG compatible firmware ..."


signature.asc
Description: This is a digitally signed message part.

Re: Changing how we handle non-free firmware

[Steve McIntyre]

On Tue, Sep 06, 2022 at 08:33:51PM +0200, Bart Martens wrote:
>On Tue, Sep 06, 2022 at 05:26:10PM +0100, Steve McIntyre wrote:
>> On Tue, Sep 06, 2022 at 06:15:21PM +0200, Bart Martens wrote:
>> >On Sun, Sep 04, 2022 at 03:43:36AM +0700, Judit Foglszinger wrote:
>> >> > I hereby propose the following alternative text to Steve's original 
>> >> > proposal.
>> >> > 
>> >> > =
>> >> > 
>> >> > The Debian project is permitted to make distribution media (installer 
>> >> > images
>> >> > and live images) containing packages from the non-free section of the 
>> >> > Debian
>> >> > archive available for download alongside with the free media in a way 
>> >> > that the
>> >> > user is informed before downloading which media are the free ones.
>> >> > 
>> >> > =
>> >> 
>> >> Wondering if this should be s/non-free section/non-free-firmware section/
>> >
>> >Thanks for asking. The short answer is no. I kept my proposal very short,
>> >keeping the focus on the smallest possible action we can do for helping 
>> >those
>> >users that need non-free firmware: allowing ourselves to advertise non-free
>> >installers just as visible as our free installer. Moving non-free firmware 
>> >to a
>> >separate section might be useful, but it is in my view not part of that
>> >smallest possible action. So what's my position on such new section? Well, 
>> >what
>> >is not mentioned is not proposed and not opposed. That's all. - B.
>> 
>> Argh. So this does *not* work with the plan that we have *already
>> started*, where we're going to move firmware things to
>> non-free-firmware instead. Please switch to "non-free and/or
>> non-free-firmware sections" in your text.
>
>I'm surprised. Please read what is written. Proposal C leaves open whether such
>new section would be added in the future. So if proposal C would win, then the
>started work you describe can continue. Proposal C uses the term "non-free"
>because that is where all non-free packages are still residing today.
>
>Does this cover your concern?

No, it doesn't. Your words may cover where those packages are *today*,
but they most likely will *not* be in "non-free" when we come to make
the changes. "non-free-firmware" != "non-free". Please tweak your
wording to be more flexible and cover what we're aiming to do.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Bart Martens]

On Tue, Sep 06, 2022 at 05:26:10PM +0100, Steve McIntyre wrote:
> On Tue, Sep 06, 2022 at 06:15:21PM +0200, Bart Martens wrote:
> >On Sun, Sep 04, 2022 at 03:43:36AM +0700, Judit Foglszinger wrote:
> >> > I hereby propose the following alternative text to Steve's original 
> >> > proposal.
> >> > 
> >> > =
> >> > 
> >> > The Debian project is permitted to make distribution media (installer 
> >> > images
> >> > and live images) containing packages from the non-free section of the 
> >> > Debian
> >> > archive available for download alongside with the free media in a way 
> >> > that the
> >> > user is informed before downloading which media are the free ones.
> >> > 
> >> > =
> >> 
> >> Wondering if this should be s/non-free section/non-free-firmware section/
> >
> >Thanks for asking. The short answer is no. I kept my proposal very short,
> >keeping the focus on the smallest possible action we can do for helping those
> >users that need non-free firmware: allowing ourselves to advertise non-free
> >installers just as visible as our free installer. Moving non-free firmware 
> >to a
> >separate section might be useful, but it is in my view not part of that
> >smallest possible action. So what's my position on such new section? Well, 
> >what
> >is not mentioned is not proposed and not opposed. That's all. - B.
> 
> Argh. So this does *not* work with the plan that we have *already
> started*, where we're going to move firmware things to
> non-free-firmware instead. Please switch to "non-free and/or
> non-free-firmware sections" in your text.

I'm surprised. Please read what is written. Proposal C leaves open whether such
new section would be added in the future. So if proposal C would win, then the
started work you describe can continue. Proposal C uses the term "non-free"
because that is where all non-free packages are still residing today.

Does this cover your concern?

> 
> -- 
> Steve McIntyre, Cambridge, UK.st...@einval.com
>   Armed with "Valor": "Centurion" represents quality of Discipline,
>   Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
>   concord the digital world while feeling safe and proud.

Re: Changing how we handle non-free firmware

[Steve McIntyre]

On Tue, Sep 06, 2022 at 06:15:21PM +0200, Bart Martens wrote:
>On Sun, Sep 04, 2022 at 03:43:36AM +0700, Judit Foglszinger wrote:
>> > I hereby propose the following alternative text to Steve's original 
>> > proposal.
>> > 
>> > =
>> > 
>> > The Debian project is permitted to make distribution media (installer 
>> > images
>> > and live images) containing packages from the non-free section of the 
>> > Debian
>> > archive available for download alongside with the free media in a way that 
>> > the
>> > user is informed before downloading which media are the free ones.
>> > 
>> > =
>> 
>> Wondering if this should be s/non-free section/non-free-firmware section/
>
>Thanks for asking. The short answer is no. I kept my proposal very short,
>keeping the focus on the smallest possible action we can do for helping those
>users that need non-free firmware: allowing ourselves to advertise non-free
>installers just as visible as our free installer. Moving non-free firmware to a
>separate section might be useful, but it is in my view not part of that
>smallest possible action. So what's my position on such new section? Well, what
>is not mentioned is not proposed and not opposed. That's all. - B.

Argh. So this does *not* work with the plan that we have *already
started*, where we're going to move firmware things to
non-free-firmware instead. Please switch to "non-free and/or
non-free-firmware sections" in your text.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Bart Martens]

On Sun, Sep 04, 2022 at 03:43:36AM +0700, Judit Foglszinger wrote:
> > I hereby propose the following alternative text to Steve's original 
> > proposal.
> > 
> > =
> > 
> > The Debian project is permitted to make distribution media (installer images
> > and live images) containing packages from the non-free section of the Debian
> > archive available for download alongside with the free media in a way that 
> > the
> > user is informed before downloading which media are the free ones.
> > 
> > =
> 
> Wondering if this should be s/non-free section/non-free-firmware section/

Thanks for asking. The short answer is no. I kept my proposal very short,
keeping the focus on the smallest possible action we can do for helping those
users that need non-free firmware: allowing ourselves to advertise non-free
installers just as visible as our free installer. Moving non-free firmware to a
separate section might be useful, but it is in my view not part of that
smallest possible action. So what's my position on such new section? Well, what
is not mentioned is not proposed and not opposed. That's all. - B.

Re: supermajority requirements and their inheritance (was: Re: Changing how we handle non-free firmware)

[Kurt Roeckx]

On Tue, Sep 06, 2022 at 08:09:15AM +0200, Ansgar wrote:
> On Mon, 2022-09-05 at 21:51 +0200, Kurt Roeckx wrote:
> > You can argue that the developers making the installer and live images,
> > and those maintaining the website can make those decisions. You can even
> > say that they have made decisions. So those options could be seen as
> > overriding a Developer, using the power of the Technical Committee.
> > 
> > Assuming we actually went that way, 6.1.4 requires a 3:1 majority, but
> > 4.1.4 only a 2:1 majority. I think we take the highest majority
> > requirement in that case, so 3:1.
> 
> I think it is bad to transfer supermajority requirements among one
> group of voters (tech-ctte) to a very different group of voters (all
> DD). Though I agree the constitution is not clear on this.
> 
> It might be better to just get rid of both supermajority requirements:
> if 50% of all DDs agree on some implementation detail, it's probably
> fine to do it that way. I don't see a good reason to require 67% to
> agree: that would be the supermajority requirement for constitutional
> changes in several countries (e.g., Germany).

Note that 3:1 is more like 75%, 2:1 is like 67%.


Kurt

supermajority requirements and their inheritance (was: Re: Changing how we handle non-free firmware)

[Ansgar]

On Mon, 2022-09-05 at 21:51 +0200, Kurt Roeckx wrote:
> You can argue that the developers making the installer and live images,
> and those maintaining the website can make those decisions. You can even
> say that they have made decisions. So those options could be seen as
> overriding a Developer, using the power of the Technical Committee.
> 
> Assuming we actually went that way, 6.1.4 requires a 3:1 majority, but
> 4.1.4 only a 2:1 majority. I think we take the highest majority
> requirement in that case, so 3:1.

I think it is bad to transfer supermajority requirements among one
group of voters (tech-ctte) to a very different group of voters (all
DD). Though I agree the constitution is not clear on this.

It might be better to just get rid of both supermajority requirements:
if 50% of all DDs agree on some implementation detail, it's probably
fine to do it that way. I don't see a good reason to require 67% to
agree: that would be the supermajority requirement for constitutional
changes in several countries (e.g., Germany).

The last part makes me think that the 3:1 supermajority requirement is
probably also too high... Because of the low number of voters in tech-
ctte it is practically often even higher than 3:1. So one should
probably also drop or at least lower it for tech-ctte decisions and
maybe lower it to 2:1 for changes to the constitution or foundation
documents, matching real-life constitutional changes.

Ansgar

Re: Re: Changing how we handle non-free firmware

[Yao Wei]

Kurt Roeckx wrote:
> As you indicate yourself, this is an interpretation of the SC. I would
> really prefer that such a question was not open to interpretation and
> that the SC was changed to make it more clear what we mean.

Is it possible that we can risk 3:1 supermajority and change SC so that
we allow distributions of non-free software as an official image?

Like changing §1 so that "Debian will remain free by default" and
explicitly claiming that in order to support basic function of the user
hardware we provide distributable firmware in our (firmware-non-free)
repository and installation media.

We could also explicitly claiming that such repository is part of
Debian to have a proper ground.

If we are heading towards the direction, could we ask for an extension
of the discussion period in order to come up with a reasonable changes?

Yao Wei


signature.asc
Description: PGP signature

Re: Re: Changing how we handle non-free firmware

[Yao Wei]

Re: Re: Changing how we handle non-free firmware

[Yao Wei]

Re: Changing how we handle non-free firmware

[Steve McIntyre]

On Fri, Sep 02, 2022 at 09:14:53PM +0200, Kurt Roeckx wrote:
>On Tue, Aug 30, 2022 at 03:11:25PM -0500, Richard Laager wrote:
>> 
>> > I like to discussion about anything related to this, so that I can at
>> > least get an idea what the consensus is.
>> 
>> DSC 1 and DSC 5 have some implications about "the Debian system" vis-a-vis
>> non-free, but the plan here is to keep the firmware in a separate
>> non-free-firmware analogous to non-free. That seems fine to me.
>> 
>> DSC 1 says we will never "require the use of a non-free component". To me,
>> this is the major relevant issue.
>> 
>> Proposals B and C offer users the explicit choice of media. That feels
>> clearly compatible with the DSC, as users are not required to use non-free
>> bits.
>> 
>> Proposal A will use non-free-firmware by default, but "where possible...will
>> include ways for users to disable this". Without the "where possible", I
>> think this opt-out is compatible with the DSC. However, if it is not
>> possible to disable the non-free-firmware, then it feels like the system is,
>> in fact, requiring it. Thus this option, as worded, feels potentially
>> incompatible with the DSC.
>
>It that it says "at boot". That seems to imply that it will get
>installed, but it might not get used, which might at least surprise
>some people. But maybe that's only for the live images.

I don't think we're on the same page here. The point of "at boot" and
"where possible" here is just to describe possibilities for how users
would interact with the firmware-included media. For example: if a
user selected a boot option saying "use no non-free firmware, then it
would be neither used *nor* installed. I added "where possible" as I
can't state with *100%* certainty that we'd be able to expose that
choice in every possible boot method - we haven't worked through all
the possibilities yet!

If those bits of extra text are causing you problems, then let's
remove them?

>Note that the SC only says: "require the use of a non-free component".
>This can be interpreted as having it installed is not a problem as
>long as it's not used.
>
>I think there are people that want to use the official image but don't
>want anything non-free installed, nor want it in the sources.list file.
>So they might want to have an installer that supports that.
>
>So I think I have to agree that the "where possible" is probably not
>compatible with the SC. I think it should be more explicit that it will
>be possible to disable the use of non-free firmware.

Right. See above...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Steve McIntyre]

Hey guys,

Apologies for not responding more promptly on this sub-thread :-/

On Mon, Sep 05, 2022 at 09:51:24PM +0200, Kurt Roeckx wrote:
>On Sun, Sep 04, 2022 at 08:00:48PM -0500, Richard Laager wrote:

...

>> [1] I understand that your (the Secretary's) current position is that you do
>> not have the power to interpret Foundation Documents. I contend that you
>> implicitly do, at least insofar as such an interpretation is required to
>> fulfill one of your explicit duties. If you do not, then it seems the
>> Project Leader would, through a combination of 5.1.3 (requires urgent
>> action) and/or 5.1.4 (noone else has responsibility).
>
>As part of this GR, I'm just trying to make sure you can interpret the
>SC in a consistent way that matches the ballot option. 
>
>Thank you for discussion this, I wish more people would participate in
>this.

Would you be more comfortable if we added an extra option like Russ
suggested [1], explicitly adding extra text to the SC?

[1] https://lists.debian.org/debian-vote/2022/08/msg00182.html

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Kurt Roeckx]

On Sun, Sep 04, 2022 at 08:00:48PM -0500, Richard Laager wrote:
> 
> Thus, a possible precursor to an interpretive GR is that some person/group
> (e.g. ftpmaster, Project Leader, TC, Secretary[1]) makes the interpretive
> decision.
> 
> If someone can make the decision, then they can be overruled[2][3] by the
> Developers through a GR. I don't think a blanket prohibition on Foundation
> Document-interpreting GRs makes sense in that context. It doesn't seem
> correct that Developers somehow lose their power to overrule if the issue
> involves interpretation of a Foundation Document.

You can argue that the developers making the installer and live images,
and those maintaining the website can make those decisions. You can even
say that they have made decisions. So those options could be seen as
overriding a Developer, using the power of the Technical Committee.

Assuming we actually went that way, 6.1.4 requires a 3:1 majority, but
4.1.4 only a 2:1 majority. I think we take the highest majority
requirement in that case, so 3:1.

> [1] I understand that your (the Secretary's) current position is that you do
> not have the power to interpret Foundation Documents. I contend that you
> implicitly do, at least insofar as such an interpretation is required to
> fulfill one of your explicit duties. If you do not, then it seems the
> Project Leader would, through a combination of 5.1.3 (requires urgent
> action) and/or 5.1.4 (noone else has responsibility).

As part of this GR, I'm just trying to make sure you can interpret the
SC in a consistent way that matches the ballot option. 

Thank you for discussion this, I wish more people would participate in
this.


Kurt

Re: Changing how we handle non-free firmware

[Richard Laager]

On 9/4/22 14:38, Kurt Roeckx wrote:

I'm not sure that a GR should say what the interpretation of a document
should be. I really prefer that the document is changed instead so that
it's more clear on what it says.


I agree with "prefer", but I can't bring myself to say "require 
[amendment]" or "prohibit interpretative GRs".


I think it's reasonable, at least in some cases, for a GR to make an 
interpretation. While amending the Foundation Document to make it more 
clear is ideal in many situations, I'm not willing to say that _all_ 
situations require that.


Let's say that we have an non-hypothetical question, "Is X allowed by 
Foundation Document Y?". By non-hypothetical, I mean this is a live 
issue for some people; the question needs an answer one way or another 
_and_ there is disagreement on the answer.


I think we can safely assume these sort of interpretive questions do 
come up in real life. For example, ftpmaster interpreting the DFSG seems 
like a common case. (Of course, most of the time those would not lead to 
GRs.)


Thus, a possible precursor to an interpretive GR is that some 
person/group (e.g. ftpmaster, Project Leader, TC, Secretary[1]) makes 
the interpretive decision.


If someone can make the decision, then they can be overruled[2][3] by 
the Developers through a GR. I don't think a blanket prohibition on 
Foundation Document-interpreting GRs makes sense in that context. It 
doesn't seem correct that Developers somehow lose their power to 
overrule if the issue involves interpretation of a Foundation Document.


One might argue that the Developers retain that power through an 
amending GR. But I argue that those are separate powers (from the 
explicit text of the constitution), with separate majority requirements, 
and for good reason. Amending a Foundation Document requires 3:1. It is 
thus possible for an amending GR to fail, even if it has ballot options 
to resolve the question each way. That is, if the issue is split and 
neither side is >= 3:1, "None of the Above" wins. This leaves the 
question undecided. The ambiguity still exists and the live issue still 
needs an answer. However, if we have an interpreting GR, then it can 
produce an answer (assuming it's a yes/no question and people on each 
side rank their answer above NOTA).


The Developers' powers to overrule also come with the power to make the 
decision in the first instance. So while overruling is one scenario, it 
is not the only scenario.


[1] I understand that your (the Secretary's) current position is that 
you do not have the power to interpret Foundation Documents. I contend 
that you implicitly do, at least insofar as such an interpretation is 
required to fulfill one of your explicit duties. If you do not, then it 
seems the Project Leader would, through a combination of 5.1.3 (requires 
urgent action) and/or 5.1.4 (noone else has responsibility).


But, at least in the U.S., there is a general rule of constitution 
interpretation: if there is a (I'd say _reasonable_) way to interpret 
something that does not make it unconstitutional, then those 
interpretations should be preferred over interpretations that make it 
unconstitutional.

https://www.britannica.com/topic/constitutional-doubt
https://www.law.cornell.edu/wex/constitutional_avoidance
https://constitution.congress.gov/browse/essay/artIII-S2-C1-9-7/ALDE_00013159/

This is why, while I would prefer that "where possible" be explicitly 
amended out by its Proposer, if that does not happen, I think it is 
better to interpret to implicitly strike that phrase rather than 
declaring the whole ballot option void.


Though, to be clear, if there is _no_ reasonable interpretation that 
makes a ballot option constitutional, then I still contend that the 
Secretary has the power _and duty_ to declare it unconstitutionally void.


[2] Overruling TC requires 2:1.

[3] Things get more complicated if the Secretary is doing the 
interpreting. We can game out how that plays out if the Developers 
collectively disagree with the Secretary, but fundamentally, if the 
Developers collectively disagree enough, they have the power to enforce 
their will (and technically only need 1:1, though politically it is more 
complicated).


--
Richard


OpenPGP_signature
Description: OpenPGP digital signature

Re: Changing how we handle non-free firmware

[Paul Wise]

On Wed, 2022-08-24 at 09:21 +0800, Paul Wise wrote:
> On Tue, 2022-08-23 at 19:57 +0200, Simon Josefsson wrote:
> 
> > My reading of that is that the FSF RYF program does not meet the needs
> > of people who do not care about having a fully free software system.
> 
> My reading of it was the opposite, that the FSF RYF program doesn't
> take into account the potential for reverse engineering of firmware

PS: if there is anyone interested in reforming the FSF RYF program,
I note the FSF are hiring someone to lead the program and other things:

https://www.fsf.org/resources/jobs/fsf-job-opportunity-licensing-and-compliance-manager

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Changing how we handle non-free firmware

[Richard Laager]

On 9/4/22 14:38, Kurt Roeckx wrote:

Please note that the current discussion period ends the 7th, the maximum
discussion period is the 8th, which probably means I'll start the vote
the 9th or the 10th, and I think we're not actually going to be ready to
have all options like we want them by then.


Under §A.1.1, the Project Leader can increase the maximum discussion 
period by 1 week. That would extend the 8th to the 15th. It sounds like 
that might be a good idea here.


If an option is amended or a new option added, that would extend the 7th 
to one week past the amendment (or the 15th, whichever was earlier).


--
Richard


OpenPGP_signature
Description: OpenPGP digital signature

Re: Changing how we handle non-free firmware

[Kurt Roeckx]

On Sun, Sep 04, 2022 at 09:57:45AM +0200, Tobias Frost wrote:
> Hi Steve,
> 
> On Fri, Sep 02, 2022 at 09:14:53PM +0200, Kurt Roeckx wrote:
> > On Tue, Aug 30, 2022 at 03:11:25PM -0500, Richard Laager wrote:
> > > 
> > > > I like to discussion about anything related to this, so that I can at
> > > > least get an idea what the consensus is.
> > > 
> > > DSC 1 and DSC 5 have some implications about "the Debian system" vis-a-vis
> > > non-free, but the plan here is to keep the firmware in a separate
> > > non-free-firmware analogous to non-free. That seems fine to me.
> > > 
> > > DSC 1 says we will never "require the use of a non-free component". To me,
> > > this is the major relevant issue.
> > > 
> > > Proposals B and C offer users the explicit choice of media. That feels
> > > clearly compatible with the DSC, as users are not required to use non-free
> > > bits.
> > > 
> > > Proposal A will use non-free-firmware by default, but "where 
> > > possible...will
> > > include ways for users to disable this". Without the "where possible", I
> > > think this opt-out is compatible with the DSC. However, if it is not
> > > possible to disable the non-free-firmware, then it feels like the system 
> > > is,
> > > in fact, requiring it. Thus this option, as worded, feels potentially
> > > incompatible with the DSC.
> > 
> > It that it says "at boot". That seems to imply that it will get
> > installed, but it might not get used, which might at least surprise
> > some people. But maybe that's only for the live images.
> > 
> > Note that the SC only says: "require the use of a non-free component".
> > This can be interpreted as having it installed is not a problem as
> > long as it's not used.
> > 
> > I think there are people that want to use the official image but don't
> > want anything non-free installed, nor want it in the sources.list file.
> > So they might want to have an installer that supports that.
> > 
> > So I think I have to agree that the "where possible" is probably not
> > compatible with the SC. I think it should be more explicit that it will
> > be possible to disable the use of non-free firmware.
> > 
> > SC #5 says that contrib and non-free is not part of the Debian system.
> > But talks about CDs that can include such packages. It seems that we
> > find it acceptable that installation and live media contains non-free
> > software. But clearly there are people who don't agree with this.
> > 
> > Other questions I still have:
> > - Can a GR overrule the SC without explicitly saysing so, and does it
> >   then need a 3:1 super majority? Currently I think it should explicitly
> >   change the SC.
> > - Is opt-out good enough, or does it need to be opt-in?
> > - Does SC #5 need to be changes since we're adding a non-free-firmware
> >   section?
> > 
> > I will likely say that option A is not compatible with the SC and
> > invalid. Please either change the text, or try to convince me otherwise.
> > I did not see any arguments of why it would not conflict.
> > 
> 
> I think that "where possible" is aimed towards that there might be systems 
> that
> won't boot (properly) anymore, or possibly the system would not be usable for
> some people (e.g people requiring TTS), so it could be hard for them to
> actually disable them.
> 
> Disabling _might_ be even impossible during boot, if those bits are required 
> so
> early in the boot process that there is no way to intervene. (e.g Raspberry 
> Pi)
> 
> Steve, to fix the concerns by Kurt, would you accept some changes
> 
> - to remove the words "where possible"
> - and change the next sentence to:
>   "When the installer/live system is running we will provide
>informationa to the user about what firmware has been loaded (both
>free and non-free) and offer to abort the installation if non-free
>firmare has been loaded. And we will also …"
> 
> (please rephrase as you see appropiate; English is not my native
> language and I might have missed subtlities in my wording…)
> 
> My rationale for the second sentence is:
> 
> (I first had this version in mind, to be added to the sentence that has
> the "where possible: I quote that now because I believe that makes it
> clearer what I have in mind, but I believe the proposoal above is more
> practical:
>  "Where disabling the firmware is not possible or feasible, (e.g it is
>  required to boot the system/installer, required by active accessiblity
>  features, etc), we will inform the user about this, and offer to abort
>  the installation.")
> 
> - if there is a system that won't work without firemware, there won't be
>   a usable free installer for them, so for people who care, the only
>   option will be not using that system, so we should give them this
>   option as well at all. At that point, everything happended in RAM, so
>   aborting the installation will return to the previous state of the
>   device, without any permanent modifications.
> - people might not be able to make this decission before 

Re: Changing how we handle non-free firmware

[Tobias Frost]

Hi Steve,

On Fri, Sep 02, 2022 at 09:14:53PM +0200, Kurt Roeckx wrote:
> On Tue, Aug 30, 2022 at 03:11:25PM -0500, Richard Laager wrote:
> > 
> > > I like to discussion about anything related to this, so that I can at
> > > least get an idea what the consensus is.
> > 
> > DSC 1 and DSC 5 have some implications about "the Debian system" vis-a-vis
> > non-free, but the plan here is to keep the firmware in a separate
> > non-free-firmware analogous to non-free. That seems fine to me.
> > 
> > DSC 1 says we will never "require the use of a non-free component". To me,
> > this is the major relevant issue.
> > 
> > Proposals B and C offer users the explicit choice of media. That feels
> > clearly compatible with the DSC, as users are not required to use non-free
> > bits.
> > 
> > Proposal A will use non-free-firmware by default, but "where possible...will
> > include ways for users to disable this". Without the "where possible", I
> > think this opt-out is compatible with the DSC. However, if it is not
> > possible to disable the non-free-firmware, then it feels like the system is,
> > in fact, requiring it. Thus this option, as worded, feels potentially
> > incompatible with the DSC.
> 
> It that it says "at boot". That seems to imply that it will get
> installed, but it might not get used, which might at least surprise
> some people. But maybe that's only for the live images.
> 
> Note that the SC only says: "require the use of a non-free component".
> This can be interpreted as having it installed is not a problem as
> long as it's not used.
> 
> I think there are people that want to use the official image but don't
> want anything non-free installed, nor want it in the sources.list file.
> So they might want to have an installer that supports that.
> 
> So I think I have to agree that the "where possible" is probably not
> compatible with the SC. I think it should be more explicit that it will
> be possible to disable the use of non-free firmware.
> 
> SC #5 says that contrib and non-free is not part of the Debian system.
> But talks about CDs that can include such packages. It seems that we
> find it acceptable that installation and live media contains non-free
> software. But clearly there are people who don't agree with this.
> 
> Other questions I still have:
> - Can a GR overrule the SC without explicitly saysing so, and does it
>   then need a 3:1 super majority? Currently I think it should explicitly
>   change the SC.
> - Is opt-out good enough, or does it need to be opt-in?
> - Does SC #5 need to be changes since we're adding a non-free-firmware
>   section?
> 
> I will likely say that option A is not compatible with the SC and
> invalid. Please either change the text, or try to convince me otherwise.
> I did not see any arguments of why it would not conflict.
> 

I think that "where possible" is aimed towards that there might be systems that
won't boot (properly) anymore, or possibly the system would not be usable for
some people (e.g people requiring TTS), so it could be hard for them to
actually disable them.

Disabling _might_ be even impossible during boot, if those bits are required so
early in the boot process that there is no way to intervene. (e.g Raspberry Pi)

Steve, to fix the concerns by Kurt, would you accept some changes

- to remove the words "where possible"
- and change the next sentence to:
  "When the installer/live system is running we will provide
   informationa to the user about what firmware has been loaded (both
   free and non-free) and offer to abort the installation if non-free
   firmare has been loaded. And we will also …"

(please rephrase as you see appropiate; English is not my native
language and I might have missed subtlities in my wording…)

My rationale for the second sentence is:

(I first had this version in mind, to be added to the sentence that has
the "where possible: I quote that now because I believe that makes it
clearer what I have in mind, but I believe the proposoal above is more
practical:
 "Where disabling the firmware is not possible or feasible, (e.g it is
 required to boot the system/installer, required by active accessiblity
 features, etc), we will inform the user about this, and offer to abort
 the installation.")

- if there is a system that won't work without firemware, there won't be
  a usable free installer for them, so for people who care, the only
  option will be not using that system, so we should give them this
  option as well at all. At that point, everything happended in RAM, so
  aborting the installation will return to the previous state of the
  device, without any permanent modifications.
- people might not be able to make this decission before they have
  actually loaded firmware. IIUIC for TTS systems, some AMD APU won't
  display *anything* without firmware… So a chicken-egg problem; with the
  second sentence they'll explicitly get a "you do not have to…" option.

I changed my original sentence, because I'm not sure if 

Re: Changing how we handle non-free firmware

[Judit Foglszinger]

> I hereby propose the following alternative text to Steve's original proposal.
> 
> =
> 
> The Debian project is permitted to make distribution media (installer images
> and live images) containing packages from the non-free section of the Debian
> archive available for download alongside with the free media in a way that the
> user is informed before downloading which media are the free ones.
> 
> =

Wondering if this should be s/non-free section/non-free-firmware section/


signature.asc
Description: This is a digitally signed message part.

Re: Changing how we handle non-free firmware

[Jonas Smedegaard]

Quoting Kurt Roeckx (2022-09-03 20:28:35)
> On Tue, Aug 23, 2022 at 10:39:57AM +0200, Simon Josefsson wrote:
> > As far as I can tell, both Steve's and Gunnar's proposal would make
> > Debian less of a free software operating system than it is today.  That
> > makes me sad.  My preference for an outcome would be along the following
> > lines.
> > 
> > ==
> > 
> > We continue to stand by the spirit of the Debian Social Contract §1
> > which says:
> > 
> >Debian will remain 100% free
> > 
> >We provide the guidelines that we use to determine if a work is
> >"free" in the document entitled "The Debian Free Software
> >Guidelines". We promise that the Debian system and all its components
> >will be free according to these guidelines. We will support people
> >who create or use both free and non-free works on Debian. We will
> >never make the system require the use of a non-free component.
> > 
> > Therefor we will not include any non-free software in Debian, nor in the
> > main archive or installer/live/cloud or other official images, and will
> > not enable anything from non-free or contrib by default.
> 
> I can interprete that as having non-free available and installed by default
> is acceptable, as long as there is a way not to use the non-free part.
> 
> > We also continue to stand by the spirit of the Debian Social Contract §5
> > which says:
> > 
> >Works that do not meet our free software standards
> > 
> >We acknowledge that some of our users require the use of works that
> >do not conform to the Debian Free Software Guidelines. We have
> >created "contrib" and "non-free" areas in our archive for these
> >works. The packages in these areas are not part of the Debian system,
> >although they have been configured for use with Debian. We encourage
> >CD manufacturers to read the licenses of the packages in these areas
> >and determine if they can distribute the packages on their CDs. Thus,
> >although non-free works are not a part of Debian, we support their
> >use and provide infrastructure for non-free packages (such as our bug
> >tracking system and mailing lists).
> > 
> > Thereby re-inforcing the interpretation that any installer or image with
> > non-free software on it is not part of the Debian system, but that we
> > support their use and welcome others to distribute such work.
> 
> As you indicate yourself, this is an interpretation of the SC. I would
> really prefer that such a question was not open to interpretation and
> that the SC was changed to make it more clear what we mean.
> 
> I don't actually understand what this part of your text is saying. Are
> you saying that an image with non-free software on it is non-official
> because it's not part of the Debian system? That is not something I read
> in that text.

I think the key to understanding that paragraph is an implied assumption
that some installer *is* considered part of the Debian system - i.e. "a
system of installer and installable packages" (which is different from
"an operating system resulting from executing an installer").

I worry that the multiple meanings of "system" in ballot texts will lead
to confusion/frustration over how to vote and how to interpret the
result of the vote.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Changing how we handle non-free firmware

[Kurt Roeckx]

On Tue, Aug 23, 2022 at 10:39:57AM +0200, Simon Josefsson wrote:
> As far as I can tell, both Steve's and Gunnar's proposal would make
> Debian less of a free software operating system than it is today.  That
> makes me sad.  My preference for an outcome would be along the following
> lines.
> 
> ==
> 
> We continue to stand by the spirit of the Debian Social Contract §1
> which says:
> 
>Debian will remain 100% free
> 
>We provide the guidelines that we use to determine if a work is
>"free" in the document entitled "The Debian Free Software
>Guidelines". We promise that the Debian system and all its components
>will be free according to these guidelines. We will support people
>who create or use both free and non-free works on Debian. We will
>never make the system require the use of a non-free component.
> 
> Therefor we will not include any non-free software in Debian, nor in the
> main archive or installer/live/cloud or other official images, and will
> not enable anything from non-free or contrib by default.

I can interprete that as having non-free available and installed by default
is acceptable, as long as there is a way not to use the non-free part.

> We also continue to stand by the spirit of the Debian Social Contract §5
> which says:
> 
>Works that do not meet our free software standards
> 
>We acknowledge that some of our users require the use of works that
>do not conform to the Debian Free Software Guidelines. We have
>created "contrib" and "non-free" areas in our archive for these
>works. The packages in these areas are not part of the Debian system,
>although they have been configured for use with Debian. We encourage
>CD manufacturers to read the licenses of the packages in these areas
>and determine if they can distribute the packages on their CDs. Thus,
>although non-free works are not a part of Debian, we support their
>use and provide infrastructure for non-free packages (such as our bug
>tracking system and mailing lists).
> 
> Thereby re-inforcing the interpretation that any installer or image with
> non-free software on it is not part of the Debian system, but that we
> support their use and welcome others to distribute such work.

As you indicate yourself, this is an interpretation of the SC. I would
really prefer that such a question was not open to interpretation and
that the SC was changed to make it more clear what we mean.

I don't actually understand what this part of your text is saying. Are
you saying that an image with non-free software on it is non-official
because it's not part of the Debian system? That is not something I read
in that text.

I would also like to point out that the Secretary has the power to
adjudicates any disputes about interpretation of the constitution, but
not about the foundation documents.


Kurt

Re: Changing how we handle non-free firmware

[Kurt Roeckx]

On Tue, Aug 30, 2022 at 03:11:25PM -0500, Richard Laager wrote:
> 
> > I like to discussion about anything related to this, so that I can at
> > least get an idea what the consensus is.
> 
> DSC 1 and DSC 5 have some implications about "the Debian system" vis-a-vis
> non-free, but the plan here is to keep the firmware in a separate
> non-free-firmware analogous to non-free. That seems fine to me.
> 
> DSC 1 says we will never "require the use of a non-free component". To me,
> this is the major relevant issue.
> 
> Proposals B and C offer users the explicit choice of media. That feels
> clearly compatible with the DSC, as users are not required to use non-free
> bits.
> 
> Proposal A will use non-free-firmware by default, but "where possible...will
> include ways for users to disable this". Without the "where possible", I
> think this opt-out is compatible with the DSC. However, if it is not
> possible to disable the non-free-firmware, then it feels like the system is,
> in fact, requiring it. Thus this option, as worded, feels potentially
> incompatible with the DSC.

It that it says "at boot". That seems to imply that it will get
installed, but it might not get used, which might at least surprise
some people. But maybe that's only for the live images.

Note that the SC only says: "require the use of a non-free component".
This can be interpreted as having it installed is not a problem as
long as it's not used.

I think there are people that want to use the official image but don't
want anything non-free installed, nor want it in the sources.list file.
So they might want to have an installer that supports that.

So I think I have to agree that the "where possible" is probably not
compatible with the SC. I think it should be more explicit that it will
be possible to disable the use of non-free firmware.

SC #5 says that contrib and non-free is not part of the Debian system.
But talks about CDs that can include such packages. It seems that we
find it acceptable that installation and live media contains non-free
software. But clearly there are people who don't agree with this.

Other questions I still have:
- Can a GR overrule the SC without explicitly saysing so, and does it
  then need a 3:1 super majority? Currently I think it should explicitly
  change the SC.
- Is opt-out good enough, or does it need to be opt-in?
- Does SC #5 need to be changes since we're adding a non-free-firmware
  section?

I will likely say that option A is not compatible with the SC and
invalid. Please either change the text, or try to convince me otherwise.
I did not see any arguments of why it would not conflict.


Kurt

Re: Changing how we handle non-free firmware

[Luna Jernberg]

https://linuxactionnews.com/256

On 9/1/22, Luna Jernberg  wrote:
> https://youtu.be/csdtAcf5ZMs
>
> On 8/31/22, Russ Allbery  wrote:
>> Jonas Smedegaard  writes:
>>
>>> Can you elaborate on how you support including non-free firmware in the
>>> installer *and* find the quoted paragraphs in conflict?
>>
>> I believe our Social Contract ideally should change.  I would not want to
>> indiscriminately add more non-free software (even drivers are iffy to
>> me),
>> but I think it is currently unrealistically restrictive about including
>> firmware that is required to use most modern hardware without bugs and
>> other problems.  I'm happy to have firmware in a separate archive area so
>> that people who want to avoid it can, but I personally would rather treat
>> it differently than non-free, including considering it part of the Debian
>> system.
>>
>> One of the things that I like about Debian is that it is not gNewSense
>> and
>> we take a more practical and less ideologically purist approach to free
>> software.  I would prefer that we move in a direction of even more
>> pragmatism than we currently have.
>>
>> To be clear, I do understand that I joined a project with the Social
>> Contract that it has, and unless we change it, those are the rules I
>> follow when working on Debian.  But I still have my own preferences about
>> the direction in which I'd like to see the project evolve.
>>
>> --
>> Russ Allbery (r...@debian.org)
>> 
>>
>>
>

Re: Changing how we handle non-free firmware

[Jonas Smedegaard]

Quoting Holger Levsen (2022-09-01 18:40:30)
> On Thu, Sep 01, 2022 at 06:02:38PM +0200, Simon Richter wrote:
> > A large part of installations now run inside virtual machines and have no
> > use for device firmware. 
> 
> yes.
> 
> > Having a free-software-only installer is an easy
> > way for image builders to ensure that anything they build will be
> > redistributable.
> 
> no. if you build images, you don't use d-i but fai, debuerreotype, mmedebstrap
> debootstrap or your-custom-script-being-used-since-1997 or something else, but
> hardly anyone uses d-i for this use-case.

I suspect that the above response provides a clue to why some find it
important to label an install image as "official" and others find that
irrelevant: I am the developer of one such bootstrapping tool - boxer -
but I consider my tool stable only when it can mimick the installation
as done by debian-installer.  My tool is far from that goal, but that
goal nevertheless exists for my view on what is a canonical Debian
system: A system spawned using official Debian install process.

When you use debootstrap (which for *most* parts is the canonical tool)
then you are left with a few files missing (at some point that included
/etc/resolv.conf and /etc/apt/sources.list) and filing a bugreport that
packages behave weirdly for a system with those core files missing will
most likely lead to that bugreport being quickly closed as not-a-bug.
Which is the reason that I consider debian-installer an important part
of our main deliverable.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Changing how we handle non-free firmware

[Holger Levsen]

On Thu, Sep 01, 2022 at 06:02:38PM +0200, Simon Richter wrote:
> A large part of installations now run inside virtual machines and have no
> use for device firmware. 

yes.

> Having a free-software-only installer is an easy
> way for image builders to ensure that anything they build will be
> redistributable.

no. if you build images, you don't use d-i but fai, debuerreotype, mmedebstrap
debootstrap or your-custom-script-being-used-since-1997 or something else, but
hardly anyone uses d-i for this use-case.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

https://showyourstripes.info


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Simon Richter]

Hi Jonas,

On 8/31/22 18:43, Jonas Smedegaard wrote:


The only way I could see to solve that conflict (other than interpreting
the official installer as not part of Debian) was to keep the free-only
installer around for purity reason even though generally we would
promote another unofficial installer (and here the word "official"
refers to what is treated as formally our main project deliverable).


I think that, besides the project goal :), there are other very good 
reasons to keep the free-only installer around, specifically that its 
licensing status is simple.


A large part of installations now run inside virtual machines and have 
no use for device firmware. Having a free-software-only installer is an 
easy way for image builders to ensure that anything they build will be 
redistributable.


The way I read the Social Contract, we can indeed not call an installer 
that contains and installs non-free bits "official", but there is no 
restriction on putting it on the same download page.


My expectation is that users will be pragmatic about it, and it might 
even raise a bit of awareness that the status quo is suboptimal because 
there are parts of the computer that are not under the full control of 
the user.


   Simon


OpenPGP_0xEBF67A846AABE354.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: Changing how we handle non-free firmware

[Luna Jernberg]

i vote for Proposal B

On 9/1/22, Luna Jernberg  wrote:
> https://youtu.be/csdtAcf5ZMs
>
> On 8/31/22, Russ Allbery  wrote:
>> Jonas Smedegaard  writes:
>>
>>> Can you elaborate on how you support including non-free firmware in the
>>> installer *and* find the quoted paragraphs in conflict?
>>
>> I believe our Social Contract ideally should change.  I would not want to
>> indiscriminately add more non-free software (even drivers are iffy to
>> me),
>> but I think it is currently unrealistically restrictive about including
>> firmware that is required to use most modern hardware without bugs and
>> other problems.  I'm happy to have firmware in a separate archive area so
>> that people who want to avoid it can, but I personally would rather treat
>> it differently than non-free, including considering it part of the Debian
>> system.
>>
>> One of the things that I like about Debian is that it is not gNewSense
>> and
>> we take a more practical and less ideologically purist approach to free
>> software.  I would prefer that we move in a direction of even more
>> pragmatism than we currently have.
>>
>> To be clear, I do understand that I joined a project with the Social
>> Contract that it has, and unless we change it, those are the rules I
>> follow when working on Debian.  But I still have my own preferences about
>> the direction in which I'd like to see the project evolve.
>>
>> --
>> Russ Allbery (r...@debian.org)
>> 
>>
>>
>

Re: Changing how we handle non-free firmware

[Luna Jernberg]

https://youtu.be/csdtAcf5ZMs

On 8/31/22, Russ Allbery  wrote:
> Jonas Smedegaard  writes:
>
>> Can you elaborate on how you support including non-free firmware in the
>> installer *and* find the quoted paragraphs in conflict?
>
> I believe our Social Contract ideally should change.  I would not want to
> indiscriminately add more non-free software (even drivers are iffy to me),
> but I think it is currently unrealistically restrictive about including
> firmware that is required to use most modern hardware without bugs and
> other problems.  I'm happy to have firmware in a separate archive area so
> that people who want to avoid it can, but I personally would rather treat
> it differently than non-free, including considering it part of the Debian
> system.
>
> One of the things that I like about Debian is that it is not gNewSense and
> we take a more practical and less ideologically purist approach to free
> software.  I would prefer that we move in a direction of even more
> pragmatism than we currently have.
>
> To be clear, I do understand that I joined a project with the Social
> Contract that it has, and unless we change it, those are the rules I
> follow when working on Debian.  But I still have my own preferences about
> the direction in which I'd like to see the project evolve.
>
> --
> Russ Allbery (r...@debian.org)  
>
>

Re: Changing how we handle non-free firmware

[Paul Wise]

On Wed, 2022-08-31 at 11:19 -0500, Gunnar Wolf wrote:

> However, just pushing a not-well-thought-idea: Would dak, apt, or any
> other bit of our infrastructure be very angry if non-free-firmware
> were to be not an additional component, but a strict subset of
> non-free?
> 
> That is, all packages accepted to non-free-firmware would still appear
> as part of non-free (and thus, users having non-free listed would
> still continue to receive updates).

I suggested this in the earlier discussion:

https://lists.debian.org/msgid-search/56b88c450a464743f84a2f451d20d554d81c3546.ca...@debian.org

It sounds like that this isn't going to happen:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012533#25

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Changing how we handle non-free firmware

[Shengjing Zhu]

On Mon, Aug 29, 2022 at 09:06:38AM +0200, Simon Josefsson wrote:
> ==
> 
> We continue to stand by the spirit of the Debian Social Contract §1
> which says:
> 
>Debian will remain 100% free
> 
>We provide the guidelines that we use to determine if a work is
>"free" in the document entitled "The Debian Free Software
>Guidelines". We promise that the Debian system and all its components
>will be free according to these guidelines. We will support people
>who create or use both free and non-free works on Debian. We will
>never make the system require the use of a non-free component.
> 
> Therefore we will not include any non-free software in Debian, nor in the
> main archive or installer/live/cloud or other official images, and will
> not enable anything from non-free or contrib by default.
> 
> We also continue to stand by the spirit of the Debian Social Contract §5
> which says:
> 
>Works that do not meet our free software standards
> 
>We acknowledge that some of our users require the use of works that
>do not conform to the Debian Free Software Guidelines. We have
>created "contrib" and "non-free" areas in our archive for these
>works. The packages in these areas are not part of the Debian system,
>although they have been configured for use with Debian. We encourage
>CD manufacturers to read the licenses of the packages in these areas
>and determine if they can distribute the packages on their CDs. Thus,
>although non-free works are not a part of Debian, we support their
>use and provide infrastructure for non-free packages (such as our bug
>tracking system and mailing lists).
> 
> Thereby re-inforcing the interpretation that any installer or image with
> non-free software on it is not part of the Debian system, but that we
> support their use and welcome others to distribute such work.
> 
> ==

Second.


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Russ Allbery]

Jonas Smedegaard  writes:

> Can you elaborate on how you support including non-free firmware in the
> installer *and* find the quoted paragraphs in conflict?

I believe our Social Contract ideally should change.  I would not want to
indiscriminately add more non-free software (even drivers are iffy to me),
but I think it is currently unrealistically restrictive about including
firmware that is required to use most modern hardware without bugs and
other problems.  I'm happy to have firmware in a separate archive area so
that people who want to avoid it can, but I personally would rather treat
it differently than non-free, including considering it part of the Debian
system.

One of the things that I like about Debian is that it is not gNewSense and
we take a more practical and less ideologically purist approach to free
software.  I would prefer that we move in a direction of even more
pragmatism than we currently have.

To be clear, I do understand that I joined a project with the Social
Contract that it has, and unless we change it, those are the rules I
follow when working on Debian.  But I still have my own preferences about
the direction in which I'd like to see the project evolve.

-- 
Russ Allbery (r...@debian.org)  

Re: Changing how we handle non-free firmware

[Jonas Smedegaard]

Quoting Russ Allbery (2022-08-31 18:27:07)
> Stefano Rivera  writes:
> 
> > Reading this in LWN reminds me that I would don't agree with this
> > interpretation.
> 
> > I'd probably vote both the 3:1 option and the 1:1 above NOTA.  This is
> > because I believe that if enough of us agree, we should update the
> > Social Contract to explain how our non-free-firmware section works, and
> > what the images provide.
> 
> My concern is that this in proposal A:
> 
> We will publish these images as official Debian media, replacing the
> current media sets that do not include non-free firmware packages.
> 
> and this in the Social Contract:
> 
> The packages in these areas are not part of the Debian system,
> although they have been configured for use with Debian.
> 
> fit together oddly.  I think I can see the reasoning behind why folks
> don't believe they conflict, but I must admit that my first reaction is
> that they conflict.  I think the implication of them not conflicting is
> that our official installers are not part of the Debian system?  Which
> seems like an odd conclusion to me.
> 
> I don't really want to be the proponent of an option here, but I'm a bit
> worried about not addressing this head-on.  So far, no one else who
> supports including non-free firmware in the installer (as I do) has also
> indicated that this bothers them, though, which to me argues against
> adding yet another option for something that maybe only I care about.
> 
> (Proposal B and proposal C both avoid this problem.  I personally prefer
> proposal A, though.)

Can you elaborate on how you support including non-free firmware in the
installer *and* find the quoted paragraphs in conflict?

Because I _want_ to support an installer as proposed in option A
*except* that very conflict.

The only way I could see to solve that conflict (other than interpreting
the official installer as not part of Debian) was to keep the free-only
installer around for purity reason even though generally we would
promote another unofficial installer (and here the word "official"
refers to what is treated as formally our main project deliverable).

I expect your elaborating would help me see more possibilities.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Changing how we handle non-free firmware

[Gunnar Wolf]

Kurt Roeckx dijo [Tue, Aug 30, 2022 at 07:00:40PM +0200]:
> > > It's my current interpretation that all voting options, even if they
> > > might conflict with the DSC, will be on the ballot, and might not
> > > require a 3:1 majority. That is, I don't think the Secretary can decide
> > > not to include an option that might conflict, or put a 3:1 majority
> > > requirement on it because they think it conflicts.
> > > 
> > > However, if an option that might conflict wins, the Secretary might
> > > have to decide if it conflicts or not, and if it conflicts void the
> > > GR.
> > I'm having trouble reconciling the two positions of "[not] put a 3:1
> > majority requirement on it because...it conflicts" and "it conflicts void
> > the GR".
> 
> I think that the Secretary when running a vote should just follow the
> procedures for the vote. There is no text saying that the Secretary
> should make sure that the option is valid. If there are enough people
> to put an option on the ballot, the Secretary should put that option
> on the ballot, even when it's clearly invalid. The Secretary can of
> course say that they think it's not a valid option, and what might need
> to change for it to be, but I think it should be on the ballot even
> when not valid. We can still deal with it being not valid if it ends
> up winning.

Yes. But the Secretary is far from a robot. I absolutely expect the
Secretary to inform the project if an option is likely to be
"problematic" in a way that puts us in a position similar to what we
lived after vote 2004/vote_003 (Editorial amendments to the social
contract).

So if you doubt on the compatibility between our Foundation
Documents and any of the options... Please do communicate it to us,
sooner rather than later.

> > The only way I can see to reconcile your positions is if a GR is not allowed
> > to supersede a Foundation Document by implication, but must do so
> > explicitly. Is that your rationale?
> 
> I have not made any decision about this yet, but if asked, will most
> likely say so.
> 
> It's at least a reason why an option might not be valid.

I hope you can come to (and communicate) this decision, at least,
before you call for votes.

> > Regardless of that, and probably more importantly, I object to the idea that
> > a GR option winning could result in the whole GR being voided. Our voting
> > system is explicitly designed to take into account supermajority
> > requirements. A GR option failing a supermajority requirement should fail by
> > itself, not take down the whole GR with it.
> 
> I'm not sure it's a good idea to reinterpret the results with that
> option removed. I think if an option wins and is later determine not
> to be valid, the GR should just be done again.

This is a valid interpretation, and I'm happy you have explicitly
interpreted your reading of your role in the open stating it. Even
though the Condorcet voting system should be OK with having one of the
options removed (the preferences of all other options do not change),
it is a valid reading -- and completely within your powers.

- Gunnar.


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Gunnar Wolf]

Russ Allbery dijo [Tue, Aug 30, 2022 at 08:41:59AM -0700]:
> The phrasing of the constitution here is that the 2:1 majority is required
> for decisions that are authorized by the powers of the Technical
> Committee, and I think this sort of policy decision about how to handle
> non-free software is clearly outside the scope of the Technical Committee.
> I can't imagine the TC being comfortable making a decision like this, or
> the project being comfortable having them do it.

I agree with what you say. Wearing my TC hat, I'd say this kind of
issue should be debated and voted by the project, not by the TC. Even
though the role of firmware, or the layout of archive components, are
brought in and somewhat discussed, this is not a vote on technical
issues.


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Russ Allbery]

Stefano Rivera  writes:

> Reading this in LWN reminds me that I would don't agree with this
> interpretation.

> I'd probably vote both the 3:1 option and the 1:1 above NOTA.  This is
> because I believe that if enough of us agree, we should update the
> Social Contract to explain how our non-free-firmware section works, and
> what the images provide.

My concern is that this in proposal A:

We will publish these images as official Debian media, replacing the
current media sets that do not include non-free firmware packages.

and this in the Social Contract:

The packages in these areas are not part of the Debian system,
although they have been configured for use with Debian.

fit together oddly.  I think I can see the reasoning behind why folks
don't believe they conflict, but I must admit that my first reaction is
that they conflict.  I think the implication of them not conflicting is
that our official installers are not part of the Debian system?  Which
seems like an odd conclusion to me.

I don't really want to be the proponent of an option here, but I'm a bit
worried about not addressing this head-on.  So far, no one else who
supports including non-free firmware in the installer (as I do) has also
indicated that this bothers them, though, which to me argues against
adding yet another option for something that maybe only I care about.

(Proposal B and proposal C both avoid this problem.  I personally prefer
proposal A, though.)

-- 
Russ Allbery (r...@debian.org)  

Re: Changing how we handle non-free firmware

[Gunnar Wolf]

Russ Allbery dijo [Tue, Aug 30, 2022 at 02:38:13PM -0700]:
> > If it does not require the explicit approval of the sponsors, yes, I
> > agree this text clarifies and makes better the text I proposed.
> 
> I'm not Kurt, but I think A.1.3 applies here:
> 
> The proposer of a ballot option may amend that option provided that
> none of the sponsors of that ballot option at the time the amendment
> is proposed disagree with that change within 24 hours. If any of them
> do disagree, the ballot option is left unchanged.

Thanks, Russ. I don't have mind-cached all of the constitution. OK, I
confirm then my acknowledgement to Kurt's suggestion: Please add the
paragraph to my option.


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Gunnar Wolf]

Antoine Beaupré dijo [Tue, Aug 30, 2022 at 11:33:15AM -0400]:
> > Since I started talking about this, Ansgar has already added dak
> > support for a new, separate non-free-firmware component - see
> > [4]. This makes part of my original proposal moot! More work is needed
> > yet to make use of this support, but it's started! :-)
> 
> This, however, strikes me as odd: I would have expected this to be part
> of the proposal, or at least discussed here, not implemented out of band
> directly. I happen to think this is a rather questionable decision: I
> would have prefered non-free to keep containing firmware images, for
> example. Splitting that out into a different component will mean a lot
> of our users setup will break (or at least stop receiving firmware
> upgrades) unless they make manual changes to their sources.list going
> forward. This feels like a regression.
> 
> In general, I feel we sometimes underestimate the impact of sources.list
> changes to our users. I wish we would be more thoughtful about those
> changes going forward. It seems like this ship has already sailed, of
> course, but maybe we could be more careful about this in the future,
> *especially* since we were planning on having a discussion on
> debian-vote about that specific issue?

You make a very important and interesting point. I guess that part of
the fallout might be offset by the changes being part of the release
notes, and being enabled in practice starting with the new
release.

However, just pushing a not-well-thought-idea: Would dak, apt, or any
other bit of our infrastructure be very angry if non-free-firmware
were to be not an additional component, but a strict subset of
non-free?

That is, all packages accepted to non-free-firmware would still appear
as part of non-free (and thus, users having non-free listed would
still continue to receive updates).

I am sure this would have as a consequence the prominence of several
thorns I haven't thought about :-) but it might be a way to address
your point.

> Gulp, such a big jump! :) I personnally feel that we should make it
> easier for people to install Debian, but I'm not quite sure I'm ready to
> completely ditch the free images just yet. Maybe we could just promote
> non-free images a little better, but I would much rather keep the free
> images around. I guess that makes me a supporter of option "B", if I
> understand correctly, but I am known for struggling with parsing GR
> proposals. :)

As the proposer of option B: That's basically what I want. "Here,
these images have little bits of evil, but are necessary to boot on
most modern hardware. Of course, we also carry those, that are
completely non-evil".


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Steve McIntyre]

On Wed, Aug 31, 2022 at 05:50:17PM +0200, Bart Martens wrote:
>On Thu, Aug 18, 2022 at 08:58:21PM +0100, Steve McIntyre wrote:
>> So, I propose the following:
>> 
>> =
>> 
>> We will include non-free firmware packages from the
>> "non-free-firmware" section of the Debian archive on our official
>> media (installer images and live images). The included firmware
>> binaries will *normally* be enabled by default where the system
>> determines that they are required, but where possible we will include
>> ways for users to disable this at boot (boot menu option, kernel
>> command line etc.).
>> 
>> When the installer/live system is running we will provide information
>> to the user about what firmware has been loaded (both free and
>> non-free), and we will also store that information on the target
>> system such that users will be able to find it later.
>
>> The target
>> system will *also* be configured to use the non-free-firmware
>> component by default in the apt sources.list file.
>
>This means that non-free-firmware would be always enabled, also when the system
>would not determine that the included firmware binaries are required. Intended?

After a suggestion from Wouter I've agreed a change here for exactly
that reason - see Message-ID: <20220830200050.gz2668...@tack.einval.com>
yesterday.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Mature Sporty Personal
  More Innovation More Adult
  A Man in Dandism
  Powered Midship Specialty

Re: Changing how we handle non-free firmware

[Bart Martens]

On Thu, Aug 18, 2022 at 08:58:21PM +0100, Steve McIntyre wrote:
> So, I propose the following:
> 
> =
> 
> We will include non-free firmware packages from the
> "non-free-firmware" section of the Debian archive on our official
> media (installer images and live images). The included firmware
> binaries will *normally* be enabled by default where the system
> determines that they are required, but where possible we will include
> ways for users to disable this at boot (boot menu option, kernel
> command line etc.).
> 
> When the installer/live system is running we will provide information
> to the user about what firmware has been loaded (both free and
> non-free), and we will also store that information on the target
> system such that users will be able to find it later.

> The target
> system will *also* be configured to use the non-free-firmware
> component by default in the apt sources.list file.

This means that non-free-firmware would be always enabled, also when the system
would not determine that the included firmware binaries are required. Intended?

> Our users should
> receive security updates and important fixes to firmware binaries just
> like any other installed software.
> 
> We will publish these images as official Debian media, replacing the
> current media sets that do not include non-free firmware packages.
> 
> =
> 
> A reason for defaulting to installing non-free firmware *by default*
> is accessibility. A blind user running the installer in text-to-speech
> mode may need audio firmware loaded to be able to drive the installer
> at all. It's going to be very difficult for them to change this. Other
> people should be able to drive the system (boot menus, etc.) to *not*
> install the non-free firmware packages if desired.
> 
> We will *only* include the non-free-firmware component on our media
> and on installed systems by default. As a general policy, we still do
> not want to see other non-free software in use. Users may still enable
> the existing non-free component if they need it.
> 
> We also need to do the work to make this happen:
> 
>  * in d-i, live-boot and elsewhere to make information about firmware
>available.
> 
>  * add support for the non-free-firmware section in more places:
>ftpsync, debian-cd and more.
> 
> and I plan to start on some of those soon.
> 
> [1] https://blog.einval.com/2022/04/19#firmware-what-do-we-do
> [2] https://lists.debian.org/debian-devel/2022/04/msg00130.html
> [3] https://debconf22.debconf.org/talks/43-fixing-the-firmware-mess/
> [4] https://incoming.debian.org/debian-buildd/dists/buildd-unstable
> [5] https://lists.debian.org/debian-devel/2022/04/msg00214.html
> 
> -- 
> Steve McIntyre, Cambridge, UK.st...@einval.com
> You raise the blade, you make the change... You re-arrange me 'til I'm sane...



-- 

Re: Changing how we handle non-free firmware

[Santiago Ruano Rincón]

El 29/08/22 a las 09:06, Simon Josefsson escribió:
> Kurt Roeckx  writes:
> 
> > On Tue, Aug 23, 2022 at 10:39:57AM +0200, Simon Josefsson wrote:
> >> As far as I can tell, both Steve's and Gunnar's proposal would make
> >> Debian less of a free software operating system than it is today.  That
> >> makes me sad.  My preference for an outcome would be along the following
> >> lines.
> >
> > The key you signed this with (A3CC9C870B9D310ABAD4CF2F51722B08FE4745A2)
> > is not in the debian keyring.
> 
> I'm signing this with my debian RSA key.
> 
> /Simon
> 
> ==
> 
> We continue to stand by the spirit of the Debian Social Contract §1
> which says:
> 
>Debian will remain 100% free
> 
>We provide the guidelines that we use to determine if a work is
>"free" in the document entitled "The Debian Free Software
>Guidelines". We promise that the Debian system and all its components
>will be free according to these guidelines. We will support people
>who create or use both free and non-free works on Debian. We will
>never make the system require the use of a non-free component.
> 
> Therefore we will not include any non-free software in Debian, nor in the
> main archive or installer/live/cloud or other official images, and will
> not enable anything from non-free or contrib by default.
> 
> We also continue to stand by the spirit of the Debian Social Contract §5
> which says:
> 
>Works that do not meet our free software standards
> 
>We acknowledge that some of our users require the use of works that
>do not conform to the Debian Free Software Guidelines. We have
>created "contrib" and "non-free" areas in our archive for these
>works. The packages in these areas are not part of the Debian system,
>although they have been configured for use with Debian. We encourage
>CD manufacturers to read the licenses of the packages in these areas
>and determine if they can distribute the packages on their CDs. Thus,
>although non-free works are not a part of Debian, we support their
>use and provide infrastructure for non-free packages (such as our bug
>tracking system and mailing lists).
> 
> Thereby re-inforcing the interpretation that any installer or image with
> non-free software on it is not part of the Debian system, but that we
> support their use and welcome others to distribute such work.
> 
> ==

I won't vote for this, but I think it is important to have this option
on the ballot.

Seconded,

 -- Santiago


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Wouter Verhelst]

On Mon, Aug 22, 2022 at 12:32:54PM -0500, Gunnar Wolf wrote:
> I hereby propose the following alternative text to Steve's original
> proposal.
> 
> I'm only suggesting to modify the third paragraph, offering to produce
> two sets of images (fully-free and with-non-free-firmware), being the
> later more prominent.
> 
> =
> 
> We will include non-free firmware packages from the
> "non-free-firmware" section of the Debian archive on our official
> media (installer images and live images). The included firmware
> binaries will *normally* be enabled by default where the system
> determines that they are required, but where possible we will include
> ways for users to disable this at boot (boot menu option, kernel
> command line etc.).
> 
> When the installer/live system is running we will provide information
> to the user about what firmware has been loaded (both free and
> non-free), and we will also store that information on the target
> system such that users will be able to find it later. The target
> system will *also* be configured to use the non-free-firmware
> component by default in the apt sources.list file. Our users should
> receive security updates and important fixes to firmware binaries just
> like any other installed software.
> 
> While we will publish these images as official Debian media, they will
> *not* replace the current media sets that do not include non-free
> firmware packages, but offered alongside. Images that do include
> non-free firmware will be presented more prominently, so that
> newcomers will find them more easily; fully-free images will not be

I would state here instead

"Images that do include non-free firmware *may* be presented more
prominently, at the relevant teams' discretion".

(or something along those lines)

Rationale: we don't want to bind ourselves to an action that we're
taking because the situation is *currently* problematic. While unlikely,
it is certainly possible (given enough pressure) that at some undefined
point in the future the *majority* of firmware packages will no longer
be in the non-free section. At that point, we may want to decide to give
the image without non-free firmware priority again.

> hidden away; they will be linked from the same project pages, but with
> less visual priority.

Other than that, I would second this if I had a functional GPG key ;-)

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Changing how we handle non-free firmware

[Stefano Rivera]

Hi Russ (2022.08.30_02:55:11_+)
> Also, if the 3:1 majority option doesn't pass but a 1:1 option that
> doesn't require a supermajority does pass, that's also useful
> information.  (For example, I believe that would imply that such an
> installer has to continue to be labeled as unofficial and not a part
> of the Debian system, since I think that's the plain meaning of point
> 5 of the Social Contract.)

Reading this in LWN reminds me that I would don't agree with this
interpretation.

I'd probably vote both the 3:1 option and the 1:1 above NOTA.
This is because I believe that if enough of us agree, we should update
the Social Contract to explain how our non-free-firmware section works,
and what the images provide.

If the 3:1 option didn't pass, that wouldn't mean I don't stand behind
the 1:1 option of including non-free-firmware on images. It just means
we didn't get enough votes to change the SC.

Voting for the 3:1 option shouldn't effectively bury the 1:1 option, or
vice-versa. The point of ranked-choice voting is to be able to select
either of two acceptable options.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Re: Changing how we handle non-free firmware

[Russ Allbery]

Gunnar Wolf  writes:

> If it does not require the explicit approval of the sponsors, yes, I
> agree this text clarifies and makes better the text I proposed.

I'm not Kurt, but I think A.1.3 applies here:

The proposer of a ballot option may amend that option provided that
none of the sponsors of that ballot option at the time the amendment
is proposed disagree with that change within 24 hours. If any of them
do disagree, the ballot option is left unchanged.

-- 
Russ Allbery (r...@debian.org)  

Re: Changing how we handle non-free firmware

[Gunnar Wolf]

Kurt Roeckx dijo [Tue, Aug 30, 2022 at 10:29:28PM +0200]:
> > >> >What's the rationale for this one?
> > >> >
> > >> >I think it would make more sense to only configure the system to enable
> > >> >the non-free-firmware component if the installer determines that
> > >> >packages from that component are useful for the running system (or if
> > >> >the user explicitly asked to do so).
> > >> 
> > >> That's a fair point, my text was unclear here. Let's tweak it:
> > >> 
> > >> "Where non-free firmware is found to be necessary, the target system
> > >>  will *also* be configured to use the non-free-firmware component by
> > >>  default in the apt sources.list file."
> > >> 
> > >> Does that sound better?
> > >
> > >Is this something you want to adopt?
> > 
> > Yes, I think it improves things.
> 
> I've modified the vote page with what I think you wanted to change.
> 
> Gunnar, do you also want this change in your text?

If it does not require the explicit approval of the sponsors, yes, I
agree this text clarifies and makes better the text I proposed.


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Bastian Blank]

On Tue, Aug 30, 2022 at 05:05:35PM -0400, Antoine Beaupré wrote:
> Didn't we have buster/updates for a while? Is breakage related to that
> the reason why we're not doing this here?

We didn't have "buster" and "buster/updates" in the same place.  And
less "buster/updates" being a subset of "buster".

The support for "buster/updates" is a hack also.

Bastian

-- 
"Get back to your stations!"
"We're beaming down to the planet, sir."
-- Kirk and Mr. Leslie, "This Side of Paradise",
   stardate 3417.3

Re: Changing how we handle non-free firmware

[Antoine Beaupré]

On 2022-08-30 21:57:56, Steve McIntyre wrote:
> On Tue, Aug 30, 2022 at 04:27:17PM -0400, Antoine Beaupré wrote:
>>On 2022-08-30 21:11:07, Steve McIntyre wrote:
>>>
>>> But I want to be *very* clear here that we *don't* want to enable the
>>> whole of the non-free component for all users by default. That would
>>> be a grave disservice, and I think Ansgar agrees with me. There's no
>>> need to hold this back to be part of the GR here IMHO.
>>
>>Yeah, so I think that's a great advantage of splitting firmware out of
>>non-free: it keeps the "non-free blast radius" to a minimum, just to
>>make sure people can get their hardware working without getting all that
>>other stuff that they should really opt into.
>>
>>Yet I actually use non-free for other stuff as well, at a personal
>>level. Things like documentation, for example, often end up in non-free
>>for $reasons and I have non-free enabled for *both* this and firmware.
>>
>>In that sense, why wasn't it possible to have (say) non-free/firmware as
>>a component, so that when you opt-in to non-free you *also* get
>>firmware? That would have been a backwards-compatible change...
>
> I genuinely am not sure how various tools will interact with that kind
> of change to have nested components, tbh. I'd rather be clean and
> consistent here, and I believe Ansgar agrees. Similarly that's why the
> new non-free-firmware component has no special handling to try and and
> override package uploads there. Special cases suck, particularly
> as/when/if they stack on top of each other...

Didn't we have buster/updates for a while? Is breakage related to that
the reason why we're not doing this here?

-- 
The United States is a nation of laws:
badly written and randomly enforced.
- Frank Zappa

Re: Changing how we handle non-free firmware

[Bastian Blank]

Hi

On Tue, Aug 30, 2022 at 03:11:25PM -0500, Richard Laager wrote:
> DSC 1 says we will never "require the use of a non-free component". To me,
> this is the major relevant issue.

Nothing in Debian requires any non-free component.  Require would be:
can't be used without, which clearly is not true.

> Proposal A will use non-free-firmware by default, but "where possible...will
> include ways for users to disable this". Without the "where possible", I
> think this opt-out is compatible with the DSC. However, if it is not
> possible to disable the non-free-firmware, then it feels like the system is,
> in fact, requiring it. Thus this option, as worded, feels potentially
> incompatible with the DSC.

It is always possible to disable it: remove the entry from the
sources.list and the packages.

Also, you may want to explain why the installer is part of the system at
large.  Also please explain it in the context of DSC 4, the sections of
the DSC don't stand on it's own.

> d. The Secretary declares the option invalid and strikes it from the GR.
>This feels heavy handed given that other remedies are available,
>most notably (b), which is available even after (and if) A wins.

I fail to see where the secretary may do that.  The supermajority rules
are declarative, they don't need to be invoked.

> e. If Proposal A wins, the entire GR is declared invalid. This is the
>thing I'm objecting to.

I fail to see where this is allowed.

Bastian

-- 
One does not thank logic.
-- Sarek, "Journey to Babel", stardate 3842.4

Re: Changing how we handle non-free firmware

[Steve McIntyre]

On Tue, Aug 30, 2022 at 04:27:17PM -0400, Antoine Beaupré wrote:
>On 2022-08-30 21:11:07, Steve McIntyre wrote:
>>
>> But I want to be *very* clear here that we *don't* want to enable the
>> whole of the non-free component for all users by default. That would
>> be a grave disservice, and I think Ansgar agrees with me. There's no
>> need to hold this back to be part of the GR here IMHO.
>
>Yeah, so I think that's a great advantage of splitting firmware out of
>non-free: it keeps the "non-free blast radius" to a minimum, just to
>make sure people can get their hardware working without getting all that
>other stuff that they should really opt into.
>
>Yet I actually use non-free for other stuff as well, at a personal
>level. Things like documentation, for example, often end up in non-free
>for $reasons and I have non-free enabled for *both* this and firmware.
>
>In that sense, why wasn't it possible to have (say) non-free/firmware as
>a component, so that when you opt-in to non-free you *also* get
>firmware? That would have been a backwards-compatible change...

I genuinely am not sure how various tools will interact with that kind
of change to have nested components, tbh. I'd rather be clean and
consistent here, and I believe Ansgar agrees. Similarly that's why the
new non-free-firmware component has no special handling to try and and
override package uploads there. Special cases suck, particularly
as/when/if they stack on top of each other...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Every time you use Tcl, God kills a kitten." -- Malcolm Ray


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Steve McIntyre]

Hey Russ!

On Mon, Aug 29, 2022 at 07:55:11PM -0700, Russ Allbery wrote:
>Kurt Roeckx  writes:
>
>> It's my current interpretation that all voting options, even if they
>> might conflict with the DSC, will be on the ballot, and might not
>> require a 3:1 majority. That is, I don't think the Secretary can decide
>> not to include an option that might conflict, or put a 3:1 majority
>> requirement on it because they think it conflicts.
>
>I'm not disagreeing with Kurt's interpretation here, but as a voter I
>would love for one of the proponents of a ballot option to add non-free
>firmware to the installer to state that they are going for a 3:1 majority
>to modify the Social Contract and add an explicit statement to this effect
>to point 5 of the Social Contract.  It would only take a sentence, I
>suspect, something like:
>
>The Debian installer may include firmware that does not conform to the
>Debian Free Software Guidelines to enable use of Debian with hardware
>that requires such firmware.

If you were to propose an alternative to option A that added a 3:1
majority change to patch the SC, I would happily second it. But I
certainly don't personally feel strongly enough about that change to
propose it myself.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Kurt Roeckx]

On Tue, Aug 30, 2022 at 09:00:50PM +0100, Steve McIntyre wrote:
> Hi Kurt! Let's send this signed now,
> 
> On Sat, Aug 27, 2022 at 04:26:40PM +0200, Kurt Roeckx wrote:
> >On Fri, Aug 19, 2022 at 11:26:51AM +0100, Steve McIntyre wrote:
> >> Hey Wouter!
> >> 
> >> On Fri, Aug 19, 2022 at 12:19:55PM +0200, Wouter Verhelst wrote:
> >> >On Thu, Aug 18, 2022 at 08:58:21PM +0100, Steve McIntyre wrote:
> >> >> system will *also* be configured to use the non-free-firmware
> >> >> component by default in the apt sources.list file.
> >> >
> >> >What's the rationale for this one?
> >> >
> >> >I think it would make more sense to only configure the system to enable
> >> >the non-free-firmware component if the installer determines that
> >> >packages from that component are useful for the running system (or if
> >> >the user explicitly asked to do so).
> >> 
> >> That's a fair point, my text was unclear here. Let's tweak it:
> >> 
> >> "Where non-free firmware is found to be necessary, the target system
> >>  will *also* be configured to use the non-free-firmware component by
> >>  default in the apt sources.list file."
> >> 
> >> Does that sound better?
> >
> >Is this something you want to adopt?
> 
> Yes, I think it improves things.

I've modified the vote page with what I think you wanted to change.

Gunnar, do you also want this change in your text?


Kurt

Re: Changing how we handle non-free firmware

[Antoine Beaupré]

On 2022-08-30 21:11:07, Steve McIntyre wrote:
> Hey Antoine!
>
> On Tue, Aug 30, 2022 at 11:33:15AM -0400, Antoine Beaupré wrote:

[...]

>>> Since I started talking about this, Ansgar has already added dak
>>> support for a new, separate non-free-firmware component - see
>>> [4]. This makes part of my original proposal moot! More work is needed
>>> yet to make use of this support, but it's started! :-)
>>
>>This, however, strikes me as odd: I would have expected this to be part
>>of the proposal, or at least discussed here, not implemented out of band
>>directly. I happen to think this is a rather questionable decision: I
>>would have prefered non-free to keep containing firmware images, for
>>example. Splitting that out into a different component will mean a lot
>>of our users setup will break (or at least stop receiving firmware
>>upgrades) unless they make manual changes to their sources.list going
>>forward. This feels like a regression.
>
> So we'll need to advertise it well so that people pick these changes
> up. That's important.
>
> But I want to be *very* clear here that we *don't* want to enable the
> whole of the non-free component for all users by default. That would
> be a grave disservice, and I think Ansgar agrees with me. There's no
> need to hold this back to be part of the GR here IMHO.

Yeah, so I think that's a great advantage of splitting firmware out of
non-free: it keeps the "non-free blast radius" to a minimum, just to
make sure people can get their hardware working without getting all that
other stuff that they should really opt into.

Yet I actually use non-free for other stuff as well, at a personal
level. Things like documentation, for example, often end up in non-free
for $reasons and I have non-free enabled for *both* this and firmware.

In that sense, why wasn't it possible to have (say) non-free/firmware as
a component, so that when you opt-in to non-free you *also* get
firmware? That would have been a backwards-compatible change...

Thanks for the response,

a.
-- 
That's the kind of society I want to build. I want a guarantee - with
physics and mathematics, not with laws - that we can give ourselves
real privacy of personal communications.
 - John Gilmore

Re: Changing how we handle non-free firmware

[Steve McIntyre]

On Tue, Aug 30, 2022 at 09:22:39AM +0200, Simon Josefsson wrote:
>Steve McIntyre  writes:

...

>>>Thereby re-inforcing the interpretation that any installer or image with
>>>non-free software on it is not part of the Debian system, but that we
>>>support their use and welcome others to distribute such work.
>>>
>>>==
>>
>> This last bit of wording is slightly unclear to me. Should *Debian* be
>> allowed to distribute an installer or image with non-free software on
>> it?
>
>Hi Steve.  I'm not sure I can reliably answer -- the distinction between
>"Debian" as the project and "Debian" as the operating system is (for me)
>somewhat blurry and inconsistent throughout the current foundational
>documents, and it is equally unclear (to me) in your question.
>
>Do you intend the Debian OS (which to me includes various installers and
>other auxilliary software that is needed to produce and maintain an OS)
>or the Debian project (which to me is about the community and not the
>deliverable)?  Or is your understanding of the situation different than
>mine so your question really mean different things to us?  I have a
>feeling that is the case, but it is subtle.

To me, saying "we support their use and welcome others to distribute
such work" has an *implicit* suggestion that "the Debian project will
not distribute such work itself". I could be reading more into that
than was intended, so I thought it was worth checking! :-)

>I believe it used to be better in the older social contract which used
>'Debian GNU/Linux' in a couple of places which made it clear that the
>sentence referred to the deliverable and not the community.  That was
>lost a couple of years ago, replacing it with 'Debian' which makes it
>unclear what it refers to.  The website has been similary modified
>throughout the years, leading to the same ambiguity.
>
>Speaking personally (and thus merely as an anecdote), my way to resolve
>this conflict (when I belatedly decided to join as DD) has been that
>'Debian' as an OS is promised to be 100% DFSG free but 'Debian' as a
>project will accept to distribute certain non-free material on its
>servers.  Thus Debian can be labeled as a 100% free OS but Debian as a
>project deals with non-free content but not as a first-class citizen.
>This has lead to forks that don't want to be stuck with the same dilemma
>-- Ubuntu/etc as a non-free variant and gNewSense/PureOS/etc as a free
>variant.  This inconsistency may continue to be both a curse and a
>blessing, allowing Debian to be relevant to both worlds.

Right, thanks for clarifying here!

>I agree with you that improving clarity on this topic will be a good
>thing.  Fixing that is outside of my current goals though, as what I
>want to achieve is to see Debian continue to deliver a 100% DFSG-free
>Debian OS.  It makes me sad to see such efforts to stop that.

ACK, understood. It doesn't make me happy *either* that we're in this
situation, but there are often tradeoffs to be made where we collide
with the outside world. :-(

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Who needs computer imagery when you've got Brian Blessed?


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Richard Laager]

On 8/30/22 12:00, Kurt Roeckx wrote:

On Tue, Aug 30, 2022 at 03:27:46AM -0500, Richard Laager wrote:

Regardless of that, and probably more importantly, I object to the idea that
a GR option winning could result in the whole GR being voided. Our voting
system is explicitly designed to take into account supermajority
requirements. A GR option failing a supermajority requirement should fail by
itself, not take down the whole GR with it.


I'm not sure it's a good idea to reinterpret the results with that
option removed.


I agree with that statement 100%.

If we find ourselves in that position, I agree we should not try to 
reinterpret a GR.


But my point was to avoid getting into that situation in the first 
place, by either declaring options invalid or requiring 3:1 (whichever 
is appropriate). Then the result of the GR, whatever it is, is valid.



I think if an option wins and is later determine not
to be valid, the GR should just be done again.


Right.


I'm not sure how fast I will be to make such determinations.


Fair enough. But there does come a point where additional time will not 
add additional clarity and a decision has to be made.



I like to discussion about anything related to this, so that I can at
least get an idea what the consensus is.


DSC 1 and DSC 5 have some implications about "the Debian system" 
vis-a-vis non-free, but the plan here is to keep the firmware in a 
separate non-free-firmware analogous to non-free. That seems fine to me.


DSC 1 says we will never "require the use of a non-free component". To 
me, this is the major relevant issue.


Proposals B and C offer users the explicit choice of media. That feels 
clearly compatible with the DSC, as users are not required to use 
non-free bits.


Proposal A will use non-free-firmware by default, but "where 
possible...will include ways for users to disable this". Without the 
"where possible", I think this opt-out is compatible with the DSC. 
However, if it is not possible to disable the non-free-firmware, then it 
feels like the system is, in fact, requiring it. Thus this option, as 
worded, feels potentially incompatible with the DSC.


Note that Proposal B, while sharing the same wording for this portion, 
does NOT have the same DSC conflict. This is because Proposal B retains 
the free images as an option.


Possible remedies (ordered from best to worst, in my view):

a. The proposer amends it to explicitly remove the words "where
   possible" (and no sponsors object).
b. We take the position that, if Proposal A wins, implementors are bound
   by it and the DSC. The only ways to fulfill both are:
   b1) provide options to disable the non-free-firmware; in other words,
  "where possible" is rendered inoperative, or
   b2) retain free images (as in Proposal B).
c. The Secretary declares the option is amending the DSC by implication
   and requires 3:1.
d. The Secretary declares the option invalid and strikes it from the GR.
   This feels heavy handed given that other remedies are available,
   most notably (b), which is available even after (and if) A wins.
e. If Proposal A wins, the entire GR is declared invalid. This is the
   thing I'm objecting to.

Under (b2), Proposal A becomes equal to Proposal B and Proposal A should 
just be withdrawn. The fact that both A & B already exists suggests 
Proposal B and thus (b2) is objectionable to Proposal A's Proposer & 
Sponsors.


If the consensus among Proposal A's Proposer and Sponsors is (b1), then 
they should just make it explicit with (a).


If they object to (a), then I'd be very curious for their rationale; if 
they are trying to amend the DSC by implication, then (c) seems like the 
right answer.


--
Richard


OpenPGP_signature
Description: OpenPGP digital signature

Re: Changing how we handle non-free firmware

[Steve McIntyre]

Hey Antoine!

On Tue, Aug 30, 2022 at 11:33:15AM -0400, Antoine Beaupré wrote:

...

>I particularly want to salute your work on making our users actually
>capable of using more modern hardware. I think the proposal you bring up
>(and the others that were added to the ballot) will really help move
>this problem ahead. I'm actually quite happy with how the conversation
>went so far, it seems we have matured quite a bit in our capacity in
>handling difficult decisions such as this one.

Yes, definitely! I've been very happy that we can talk about
potentially divisive topics in a reasonable fashion. :-)

>> Since I started talking about this, Ansgar has already added dak
>> support for a new, separate non-free-firmware component - see
>> [4]. This makes part of my original proposal moot! More work is needed
>> yet to make use of this support, but it's started! :-)
>
>This, however, strikes me as odd: I would have expected this to be part
>of the proposal, or at least discussed here, not implemented out of band
>directly. I happen to think this is a rather questionable decision: I
>would have prefered non-free to keep containing firmware images, for
>example. Splitting that out into a different component will mean a lot
>of our users setup will break (or at least stop receiving firmware
>upgrades) unless they make manual changes to their sources.list going
>forward. This feels like a regression.

So we'll need to advertise it well so that people pick these changes
up. That's important.

But I want to be *very* clear here that we *don't* want to enable the
whole of the non-free component for all users by default. That would
be a grave disservice, and I think Ansgar agrees with me. There's no
need to hold this back to be part of the GR here IMHO.

>In general, I feel we sometimes underestimate the impact of sources.list
>changes to our users. I wish we would be more thoughtful about those
>changes going forward. It seems like this ship has already sailed, of
>course, but maybe we could be more careful about this in the future,
>*especially* since we were planning on having a discussion on
>debian-vote about that specific issue?

ACK, I understand.

>> I believe that there is reasonably wide support for changing what we
>> do with non-free firmware. I see several possible paths forward, but
>> as I've stated previously I don't want to be making the decision
>> alone. I believe that the Debian project as a whole needs to make the
>> decision on which path is the correct one.
>
>Gulp, such a big jump! :) I personnally feel that we should make it
>easier for people to install Debian, but I'm not quite sure I'm ready to
>completely ditch the free images just yet. Maybe we could just promote
>non-free images a little better, but I would much rather keep the free
>images around. I guess that makes me a supporter of option "B", if I
>understand correctly, but I am known for struggling with parsing GR
>proposals. :)

Nod, that's fair! I proposed option A as my personal favourite for the
GR to remove (YA) possible point of confusion for our users, but I'm
definitely not blind to the size of the change that it makes for us.
Option B definitely sounds like a preferred option for some, and I'm
OK with that. :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Steve McIntyre]

Hi Kurt! Let's send this signed now,

On Sat, Aug 27, 2022 at 04:26:40PM +0200, Kurt Roeckx wrote:
>On Fri, Aug 19, 2022 at 11:26:51AM +0100, Steve McIntyre wrote:
>> Hey Wouter!
>> 
>> On Fri, Aug 19, 2022 at 12:19:55PM +0200, Wouter Verhelst wrote:
>> >On Thu, Aug 18, 2022 at 08:58:21PM +0100, Steve McIntyre wrote:
>> >> system will *also* be configured to use the non-free-firmware
>> >> component by default in the apt sources.list file.
>> >
>> >What's the rationale for this one?
>> >
>> >I think it would make more sense to only configure the system to enable
>> >the non-free-firmware component if the installer determines that
>> >packages from that component are useful for the running system (or if
>> >the user explicitly asked to do so).
>> 
>> That's a fair point, my text was unclear here. Let's tweak it:
>> 
>> "Where non-free firmware is found to be necessary, the target system
>>  will *also* be configured to use the non-free-firmware component by
>>  default in the apt sources.list file."
>> 
>> Does that sound better?
>
>Is this something you want to adopt?

Yes, I think it improves things.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Steve McIntyre]

Hi Bart!

On Tue, Aug 30, 2022 at 09:12:23PM +0200, Bart Martens wrote:
>On Mon, Aug 29, 2022 at 09:49:14PM +0100, Steve McIntyre wrote:
>> Hi Simon!
>> 
>> On Mon, Aug 29, 2022 at 09:06:38AM +0200, Simon Josefsson wrote:
>
>> >
>> >Thereby re-inforcing the interpretation that any installer or image with
>> >non-free software on it is not part of the Debian system, but that we
>> >support their use and welcome others to distribute such work.
>> >
>> >==
>> 
>> This last bit of wording is slightly unclear to me. Should *Debian* be
>> allowed to distribute an installer or image with non-free software on
>> it?
>
>Debian already does that. Anything available for download on *.debian.org is in
>fact distributed by Debian. The label "unofficial" doesn't change that.
>My point is that the last paragraph in Simon J's proposal correctly reflects
>the current reality. (But I fail to see the value of Simon J's proposal on the
>ballot because it is in my understanding equivalent with "further discussion" /
>"none of the above" which is already on the ballot.)

I'm directly asking Simon for *his* thoughts here, though. It's *not*
necessarily the same as the status quo, and I think this needs to be
explored more.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Antoine Beaupré]

On 2022-08-30 21:28:08, Bart Martens wrote:
> On Tue, Aug 30, 2022 at 09:22:51PM +0200, Bart Martens wrote:
>> On Tue, Aug 30, 2022 at 11:33:15AM -0400, Antoine Beaupré wrote:
>> > Hi Steve (and everyone else),
>> > > I believe that there is reasonably wide support for changing what we
>> > > do with non-free firmware. I see several possible paths forward, but
>> > > as I've stated previously I don't want to be making the decision
>> > > alone. I believe that the Debian project as a whole needs to make the
>> > > decision on which path is the correct one.
>> > 
>> > Gulp, such a big jump! :) I personnally feel that we should make it
>> > easier for people to install Debian, but I'm not quite sure I'm ready to
>> > completely ditch the free images just yet. Maybe we could just promote
>> > non-free images a little better, but I would much rather keep the free
>> > images around. I guess that makes me a supporter of option "B",
>> 
>> Rather option C. Option B is reinforcing the current situation. C proposes to
>> promote non-free images a little better while keeping the free images.
>
> Oops, my bad. B and C are similar on this aspect. A relevant difference is
> however that in B the non-free images are promoted above the free ones.

Right, I think that something I agree with, even if I don't like it. :/

a.

-- 
My passionate sense of social justice and social responsibility has
always contrasted oddly with my pronounced lack of need for direct
contact with other human beings and communities. I am truly a "lone
traveler" and have never belonged to my country, my home, my friends,
or even my immediate family, with my whole heart; in the face of all
these ties, I have never lost a sense of distance and a need for
solitude.
   - Albert Einstein

Re: Changing how we handle non-free firmware

[Bart Martens]

On Tue, Aug 30, 2022 at 09:22:51PM +0200, Bart Martens wrote:
> On Tue, Aug 30, 2022 at 11:33:15AM -0400, Antoine Beaupré wrote:
> > Hi Steve (and everyone else),
> > > I believe that there is reasonably wide support for changing what we
> > > do with non-free firmware. I see several possible paths forward, but
> > > as I've stated previously I don't want to be making the decision
> > > alone. I believe that the Debian project as a whole needs to make the
> > > decision on which path is the correct one.
> > 
> > Gulp, such a big jump! :) I personnally feel that we should make it
> > easier for people to install Debian, but I'm not quite sure I'm ready to
> > completely ditch the free images just yet. Maybe we could just promote
> > non-free images a little better, but I would much rather keep the free
> > images around. I guess that makes me a supporter of option "B",
> 
> Rather option C. Option B is reinforcing the current situation. C proposes to
> promote non-free images a little better while keeping the free images.

Oops, my bad. B and C are similar on this aspect. A relevant difference is
however that in B the non-free images are promoted above the free ones.

> 
> > if I
> > understand correctly, but I am known for struggling with parsing GR
> > proposals. :)
> > 
> > Thanks again for all your work, and for everyone for having a (so far)
> > rather polite discussion on this possibly difficult topic.
> > 
> > a.
> > 
> > -- 
> > Time is a created thing. To say, "I don't have time" is like saying,
> > "I don't want to."
> > - Lao Tzu
> 
> 
> 

-- 

Re: Changing how we handle non-free firmware

[Bart Martens]

On Tue, Aug 30, 2022 at 11:33:15AM -0400, Antoine Beaupré wrote:
> Hi Steve (and everyone else),
> > I believe that there is reasonably wide support for changing what we
> > do with non-free firmware. I see several possible paths forward, but
> > as I've stated previously I don't want to be making the decision
> > alone. I believe that the Debian project as a whole needs to make the
> > decision on which path is the correct one.
> 
> Gulp, such a big jump! :) I personnally feel that we should make it
> easier for people to install Debian, but I'm not quite sure I'm ready to
> completely ditch the free images just yet. Maybe we could just promote
> non-free images a little better, but I would much rather keep the free
> images around. I guess that makes me a supporter of option "B",

Rather option C. Option B is reinforcing the current situation. C proposes to
promote non-free images a little better while keeping the free images.

> if I
> understand correctly, but I am known for struggling with parsing GR
> proposals. :)
> 
> Thanks again for all your work, and for everyone for having a (so far)
> rather polite discussion on this possibly difficult topic.
> 
> a.
> 
> -- 
> Time is a created thing. To say, "I don't have time" is like saying,
> "I don't want to."
> - Lao Tzu

Re: Changing how we handle non-free firmware

[Bart Martens]

On Mon, Aug 29, 2022 at 09:49:14PM +0100, Steve McIntyre wrote:
> Hi Simon!
> 
> On Mon, Aug 29, 2022 at 09:06:38AM +0200, Simon Josefsson wrote:

> >
> >Thereby re-inforcing the interpretation that any installer or image with
> >non-free software on it is not part of the Debian system, but that we
> >support their use and welcome others to distribute such work.
> >
> >==
> 
> This last bit of wording is slightly unclear to me. Should *Debian* be
> allowed to distribute an installer or image with non-free software on
> it?

Debian already does that. Anything available for download on *.debian.org is in
fact distributed by Debian. The label "unofficial" doesn't change that.
My point is that the last paragraph in Simon J's proposal correctly reflects
the current reality. (But I fail to see the value of Simon J's proposal on the
ballot because it is in my understanding equivalent with "further discussion" /
"none of the above" which is already on the ballot.)

> 
> -- 
> Steve McIntyre, Cambridge, UK.st...@einval.com
> < liw> everything I know about UK hotels I learned from "Fawlty Towers"
> 

 

Re: Changing how we handle non-free firmware

[Bart Martens]

On Mon, Aug 29, 2022 at 11:02:09PM +0200, Kurt Roeckx wrote:
> If you believe that any of the options conflict with the DSC, I would
> like to see a discussion about that too.
> 
> It's my current interpretation that all voting options, even if they
> might conflict with the DSC, will be on the ballot, and might not
> require a 3:1 majority. That is, I don't think the Secretary can decide
> not to include an option that might conflict, or put a 3:1 majority
> requirement on it because they think it conflicts.
> 
> However, if an option that might conflict wins, the Secretary might
> have to decide if it conflicts or not, and if it conflicts void the
> GR.

Or not void the GR and inform the DPL that the outcome of the GR cannot be
implemented until another GR about the DSC...

> 
> 
> Kurt
> 

Re: Changing how we handle non-free firmware

[Kurt Roeckx]

On Tue, Aug 30, 2022 at 03:27:46AM -0500, Richard Laager wrote:
> On 8/29/22 16:02, Kurt Roeckx wrote:
> > It's my current interpretation that all voting options, even if they
> > might conflict with the DSC, will be on the ballot, and might not
> > require a 3:1 majority. That is, I don't think the Secretary can decide
> > not to include an option that might conflict, or put a 3:1 majority
> > requirement on it because they think it conflicts.
> > 
> > However, if an option that might conflict wins, the Secretary might
> > have to decide if it conflicts or not, and if it conflicts void the
> > GR.
> I'm having trouble reconciling the two positions of "[not] put a 3:1
> majority requirement on it because...it conflicts" and "it conflicts void
> the GR".

I think that the Secretary when running a vote should just follow the
procedures for the vote. There is no text saying that the Secretary
should make sure that the option is valid. If there are enough people
to put an option on the ballot, the Secretary should put that option
on the ballot, even when it's clearly invalid. The Secretary can of
course say that they think it's not a valid option, and what might need
to change for it to be, but I think it should be on the ballot even
when not valid. We can still deal with it being not valid if it ends
up winning.

> The only way I can see to reconcile your positions is if a GR is not allowed
> to supersede a Foundation Document by implication, but must do so
> explicitly. Is that your rationale?

I have not made any decision about this yet, but if asked, will most
likely say so.

It's at least a reason why an option might not be valid.

> Regardless of that, and probably more importantly, I object to the idea that
> a GR option winning could result in the whole GR being voided. Our voting
> system is explicitly designed to take into account supermajority
> requirements. A GR option failing a supermajority requirement should fail by
> itself, not take down the whole GR with it.

I'm not sure it's a good idea to reinterpret the results with that
option removed. I think if an option wins and is later determine not
to be valid, the GR should just be done again.

> Since there's a good chance you have to make the determination either way, I
> think it's far better to make that determination before the vote than after.
> Making the determination now gives people the option to amend their GR
> options before we go through a vote. That saves time and energy.

I'm not sure how fast I will be to make such determinations.

> https://www.debian.org/vote/2008/vote_003
> https://www.debian.org/vote/2006/vote_007
> https://www.debian.org/vote/2006/vote_001
> https://www.debian.org/vote/2004/vote_004

Note that I've been Secretary since February 2009.

Disagreement about how vote 2008/vote_003 was run is what made the
previous Secretary quit.

I like to discussion about anything related to this, so that I can at
least get an idea what the consensus is.


Kurt

Re: Changing how we handle non-free firmware

[Russ Allbery]

Kurt Roeckx  writes:

> But it's currently not clear if this is a technical or non-technical
> decision, and so might require a 2:1 majority.

I forgot to comment on this point in my other message, but for what it's
worth, I have a hard time seeing any of the current ballot options as
technical.  They all state policy decisions and desired outcomes and don't
specify a techncial means to accomplish those outcomes (which is the sort
of thing that I think would trigger the 2:1 majority requirement).

The phrasing of the constitution here is that the 2:1 majority is required
for decisions that are authorized by the powers of the Technical
Committee, and I think this sort of policy decision about how to handle
non-free software is clearly outside the scope of the Technical Committee.
I can't imagine the TC being comfortable making a decision like this, or
the project being comfortable having them do it.

For others reading, here's what the constitution says are the powers of
the Technical Committee (there are other clauses, but I don't think
they're relevant here):

1. Decide on any matter of technical policy.

   This includes the contents of the technical policy manuals, developers'
   reference materials, example packages and the behaviour of
   non-experimental package building tools. (In each case the usual
   maintainer of the relevant software or documentation makes decisions
   initially, however; see 6.3(5).)

2. Decide any technical matter where Developers' jurisdictions overlap.

   In cases where Developers need to implement compatible technical
   policies or stances (for example, if they disagree about the priorities
   of conflicting packages, or about ownership of a command name, or about
   which package is responsible for a bug that both maintainers agree is a
   bug, or about who should be the maintainer for a package) the technical
   committee may decide the matter.

-- 
Russ Allbery (r...@debian.org)  

Re: Changing how we handle non-free firmware

[Antoine Beaupré]

Hi Steve (and everyone else),

> I'm proposing to change how we handle non-free firmware in
> Debian. I've written about this a few times already this year [1, 2]
> and I ran a session on the subject at DebConf [3].
> 
> TL;DR: The way we deal with (non-free) firmware in Debian isn't
> great. For a long time we've got away without supporting and including
> (non-free) firmware on Debian systems. We don't *want* to have to
> provide (non-free) firmware to our users, and in an ideal world we
> wouldn't need to. However, it's no longer a sensible path when trying
> to support lots of common current hardware. Increasingly, modern
> computers don't function fully without these firmware blobs.

First, I want to thank you for your patience and dedicated in working on
all those difficult problems. The installer is a difficult piece of
software to master and work on, and I cannot imagine all the work you
have poured into this.

I particularly want to salute your work on making our users actually
capable of using more modern hardware. I think the proposal you bring up
(and the others that were added to the ballot) will really help move
this problem ahead. I'm actually quite happy with how the conversation
went so far, it seems we have matured quite a bit in our capacity in
handling difficult decisions such as this one.

> Since I started talking about this, Ansgar has already added dak
> support for a new, separate non-free-firmware component - see
> [4]. This makes part of my original proposal moot! More work is needed
> yet to make use of this support, but it's started! :-)

This, however, strikes me as odd: I would have expected this to be part
of the proposal, or at least discussed here, not implemented out of band
directly. I happen to think this is a rather questionable decision: I
would have prefered non-free to keep containing firmware images, for
example. Splitting that out into a different component will mean a lot
of our users setup will break (or at least stop receiving firmware
upgrades) unless they make manual changes to their sources.list going
forward. This feels like a regression.

In general, I feel we sometimes underestimate the impact of sources.list
changes to our users. I wish we would be more thoughtful about those
changes going forward. It seems like this ship has already sailed, of
course, but maybe we could be more careful about this in the future,
*especially* since we were planning on having a discussion on
debian-vote about that specific issue?

> I believe that there is reasonably wide support for changing what we
> do with non-free firmware. I see several possible paths forward, but
> as I've stated previously I don't want to be making the decision
> alone. I believe that the Debian project as a whole needs to make the
> decision on which path is the correct one.

Gulp, such a big jump! :) I personnally feel that we should make it
easier for people to install Debian, but I'm not quite sure I'm ready to
completely ditch the free images just yet. Maybe we could just promote
non-free images a little better, but I would much rather keep the free
images around. I guess that makes me a supporter of option "B", if I
understand correctly, but I am known for struggling with parsing GR
proposals. :)

Thanks again for all your work, and for everyone for having a (so far)
rather polite discussion on this possibly difficult topic.

a.

-- 
Time is a created thing. To say, "I don't have time" is like saying,
"I don't want to."
- Lao Tzu


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Richard Laager]

On 8/29/22 16:02, Kurt Roeckx wrote:

It's my current interpretation that all voting options, even if they
might conflict with the DSC, will be on the ballot, and might not
require a 3:1 majority. That is, I don't think the Secretary can decide
not to include an option that might conflict, or put a 3:1 majority
requirement on it because they think it conflicts.

However, if an option that might conflict wins, the Secretary might
have to decide if it conflicts or not, and if it conflicts void the
GR.
I'm having trouble reconciling the two positions of "[not] put a 3:1 
majority requirement on it because...it conflicts" and "it conflicts 
void the GR".



The only way I can see to reconcile your positions is if a GR is not 
allowed to supersede a Foundation Document by implication, but must do 
so explicitly. Is that your rationale?


I think it's reasonable to take the position that GRs can only amend the 
constitution explicitly. The constitution is written in legalistic 
language and there is obvious value in having the rules written in one 
place.


For the Foundation Documents, it seems less cut-and-dried. This is 
especially true if, for example, a GR could purport to override a 
Foundation Document temporarily (still by 3:1 majority).


Whether permanently superseding part of the DSC by implication is 
constitutionally permissible is different from whether it is a good 
idea. The former is a question for the Secretary. The latter is a 
question for the Developers through the GR.



Regardless of that, and probably more importantly, I object to the idea 
that a GR option winning could result in the whole GR being voided. Our 
voting system is explicitly designed to take into account supermajority 
requirements. A GR option failing a supermajority requirement should 
fail by itself, not take down the whole GR with it.


Since there's a good chance you have to make the determination either 
way, I think it's far better to make that determination before the vote 
than after. Making the determination now gives people the option to 
amend their GR options before we go through a vote. That saves time and 
energy.


It also just doesn't look good for the Secretary to void the GR based on 
which option won. That makes it look like you're doing so because you 
disagree with the result. I'm not saying that is the case here. I'm 
saying the optics are worse with deciding after, so I think you should 
decide before.



In my view, if the Secretary determines that a GR option is 
constitutionally defective (for whatever reason), it should not be on 
the ballot. I think you should (in this and all GRs) rule each GR option 
one of:

- requires 1:1
- requires 2:1
- requires 3:1
- invalid


https://www.debian.org/vote/2008/vote_003 is precedent for:
  - a GR option could supersede a Foundation Document implicitly,
  - a GR option could supersede a Foundation Document temporarily (not
relevant here, but I made the point above), and
  - that such options require 3:1.

https://www.debian.org/vote/2006/vote_007 is precedent for:
  - a GR option could supersede a Foundation Document permanently and
explicitly but without amending its text, and
  - that such an option requires 3:1.

https://www.debian.org/vote/2006/vote_001 is precedent for:
  - a GR option could supersede a Foundation Document permanently and
implicitly (though curiously the vote statement says "DFSG article 3
would need to be changed, or at least clarified.")
  - that interpreting a Foundation Document needs only 1:1.

https://www.debian.org/vote/2004/vote_004 is precedent for:
  - a GR option could supersede a Foundation Document temporarily
(though this took a very different approach than 2008-003 did
later).

--
Richard


OpenPGP_signature
Description: OpenPGP digital signature

Re: Changing how we handle non-free firmware

[Simon Josefsson]

Steve McIntyre  writes:

> Hi Simon!
>
> On Mon, Aug 29, 2022 at 09:06:38AM +0200, Simon Josefsson wrote:
>>
>>==
>>
>>We continue to stand by the spirit of the Debian Social Contract §1
>>which says:
>>
>>   Debian will remain 100% free
>>
>>   We provide the guidelines that we use to determine if a work is
>>   "free" in the document entitled "The Debian Free Software
>>   Guidelines". We promise that the Debian system and all its components
>>   will be free according to these guidelines. We will support people
>>   who create or use both free and non-free works on Debian. We will
>>   never make the system require the use of a non-free component.
>>
>>Therefore we will not include any non-free software in Debian, nor in the
>>main archive or installer/live/cloud or other official images, and will
>>not enable anything from non-free or contrib by default.
>>
>>We also continue to stand by the spirit of the Debian Social Contract §5
>>which says:
>>
>>   Works that do not meet our free software standards
>>
>>   We acknowledge that some of our users require the use of works that
>>   do not conform to the Debian Free Software Guidelines. We have
>>   created "contrib" and "non-free" areas in our archive for these
>>   works. The packages in these areas are not part of the Debian system,
>>   although they have been configured for use with Debian. We encourage
>>   CD manufacturers to read the licenses of the packages in these areas
>>   and determine if they can distribute the packages on their CDs. Thus,
>>   although non-free works are not a part of Debian, we support their
>>   use and provide infrastructure for non-free packages (such as our bug
>>   tracking system and mailing lists).
>>
>>Thereby re-inforcing the interpretation that any installer or image with
>>non-free software on it is not part of the Debian system, but that we
>>support their use and welcome others to distribute such work.
>>
>>==
>
> This last bit of wording is slightly unclear to me. Should *Debian* be
> allowed to distribute an installer or image with non-free software on
> it?

Hi Steve.  I'm not sure I can reliably answer -- the distinction between
"Debian" as the project and "Debian" as the operating system is (for me)
somewhat blurry and inconsistent throughout the current foundational
documents, and it is equally unclear (to me) in your question.

Do you intend the Debian OS (which to me includes various installers and
other auxilliary software that is needed to produce and maintain an OS)
or the Debian project (which to me is about the community and not the
deliverable)?  Or is your understanding of the situation different than
mine so your question really mean different things to us?  I have a
feeling that is the case, but it is subtle.

I believe it used to be better in the older social contract which used
'Debian GNU/Linux' in a couple of places which made it clear that the
sentence referred to the deliverable and not the community.  That was
lost a couple of years ago, replacing it with 'Debian' which makes it
unclear what it refers to.  The website has been similary modified
throughout the years, leading to the same ambiguity.

Speaking personally (and thus merely as an anecdote), my way to resolve
this conflict (when I belatedly decided to join as DD) has been that
'Debian' as an OS is promised to be 100% DFSG free but 'Debian' as a
project will accept to distribute certain non-free material on its
servers.  Thus Debian can be labeled as a 100% free OS but Debian as a
project deals with non-free content but not as a first-class citizen.
This has lead to forks that don't want to be stuck with the same dilemma
-- Ubuntu/etc as a non-free variant and gNewSense/PureOS/etc as a free
variant.  This inconsistency may continue to be both a curse and a
blessing, allowing Debian to be relevant to both worlds.

I agree with you that improving clarity on this topic will be a good
thing.  Fixing that is outside of my current goals though, as what I
want to achieve is to see Debian continue to deliver a 100% DFSG-free
Debian OS.  It makes me sad to see such efforts to stop that.

/Simon


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Russ Allbery]

Kurt Roeckx  writes:

> If you believe that any of the options conflict with the DSC, I would
> like to see a discussion about that too.

> It's my current interpretation that all voting options, even if they
> might conflict with the DSC, will be on the ballot, and might not
> require a 3:1 majority. That is, I don't think the Secretary can decide
> not to include an option that might conflict, or put a 3:1 majority
> requirement on it because they think it conflicts.

I'm not disagreeing with Kurt's interpretation here, but as a voter I
would love for one of the proponents of a ballot option to add non-free
firmware to the installer to state that they are going for a 3:1 majority
to modify the Social Contract and add an explicit statement to this effect
to point 5 of the Social Contract.  It would only take a sentence, I
suspect, something like:

The Debian installer may include firmware that does not conform to the
Debian Free Software Guidelines to enable use of Debian with hardware
that requires such firmware.

(I hear the folks who think we need to define firmware; I don't agree, but
I respect the argument and wouldn't vote against an option that tried to
do that.)

The failure mode that I'm worried about here is that a ballot option
passes expressing a position that we should include non-free firmware but
since it doesn't explicitly update the Social Contract some folks who
disagree with this direction for Debian continue to believe doing so is
invalid and we don't actually put the argument to rest.  Also, if the 3:1
majority option doesn't pass but a 1:1 option that doesn't require a
supermajority does pass, that's also useful information.  (For example, I
believe that would imply that such an installer has to continue to be
labeled as unofficial and not a part of the Debian system, since I think
that's the plain meaning of point 5 of the Social Contract.)

> However, if an option that might conflict wins, the Secretary might have
> to decide if it conflicts or not, and if it conflicts void the GR.

It would be better if we could figure that out in advance of the vote, of
course, since it might be relevant to choice ranking.

-- 
Russ Allbery (r...@debian.org)  

Re: Changing how we handle non-free firmware

[Paul Wise]

On Mon, 2022-08-29 at 21:49 +0100, Steve McIntyre wrote:

> This last bit of wording is slightly unclear to me. Should *Debian* be
> allowed to distribute an installer or image with non-free software on it?

and if so, how/where should we be allowed to mention/document/promote
the images containing non-free firmware?

Currently the existing images containing non-free firmware are
mentioned on the download page linked from the website front page,
but are labelled "unofficial" and in the "Other Installers" section.

https://www.debian.org/download

The longer older download pages similarly labels the non-free firmware
images as "unofficial" and mention them at the very end of the page.

https://www.debian.org/distrib/

The even older Debian CD page doesn't mention non-free firmware at all.

https://www.debian.org/CD/

The Debian installation guide has sections on non-free firmware, the
first one seems to be outdated as it seems to imply the firmware images
are not possible.

https://www.debian.org/releases/stable/amd64/ch02s02.en.html
https://www.debian.org/releases/stable/amd64/ch06s04.en.html

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Changing how we handle non-free firmware

[Kurt Roeckx]

On Mon, Aug 29, 2022 at 09:38:52PM +0100, Steve McIntyre wrote:
> Hi Kurt!
> 
> On Sat, Aug 27, 2022 at 04:26:40PM +0200, Kurt Roeckx wrote:
> >On Fri, Aug 19, 2022 at 11:26:51AM +0100, Steve McIntyre wrote:
> >> Hey Wouter!
> >> 
> >> On Fri, Aug 19, 2022 at 12:19:55PM +0200, Wouter Verhelst wrote:
> >> >On Thu, Aug 18, 2022 at 08:58:21PM +0100, Steve McIntyre wrote:
> >> >> system will *also* be configured to use the non-free-firmware
> >> >> component by default in the apt sources.list file.
> >> >
> >> >What's the rationale for this one?
> >> >
> >> >I think it would make more sense to only configure the system to enable
> >> >the non-free-firmware component if the installer determines that
> >> >packages from that component are useful for the running system (or if
> >> >the user explicitly asked to do so).
> >> 
> >> That's a fair point, my text was unclear here. Let's tweak it:
> >> 
> >> "Where non-free firmware is found to be necessary, the target system
> >>  will *also* be configured to use the non-free-firmware component by
> >>  default in the apt sources.list file."
> >> 
> >> Does that sound better?
> >
> >Is this something you want to adopt?
> 
> Yes, I think it improves things.

So can you send a signed message saying that?


Kurt

Re: Changing how we handle non-free firmware

[Kurt Roeckx]

On Mon, Aug 29, 2022 at 09:36:37AM +0200, Simon Josefsson wrote:
> Jonas Smedegaard  writes:
> 
> > 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.
> 
> I also find this problematic.  As far as I can tell, the alternatives on
> this vote that results in Debian shipping non-free software will make
> the project violate the current DSC.
> 
> Reading https://www.debian.org/devel/constitution.en.html I don't
> understand who decides the majority requirements for voting options, can
> someone explain?  Is it the project secretary?  What are they for the
> current vote?

The majority requirement depends on which of the powers in 4.2 they
want to use. Some of the previous GRs where very explicit in which power
they want to use, like saying it's a position statement.

I currently believe that non of the options require a 3:1 majority since
they do not amend the constitution or a Foundation Document.

But it's currently not clear if this is a technical or non-technical
decision, and so might require a 2:1 majority.

> I believe it would be bad for the project if the supermajority
> requirements of changing a fundational document is worked around by
> approving a GR vote with simple majority that says things contrary to
> what the DSC says.

If you believe that any of the options conflict with the DSC, I would
like to see a discussion about that too.

It's my current interpretation that all voting options, even if they
might conflict with the DSC, will be on the ballot, and might not
require a 3:1 majority. That is, I don't think the Secretary can decide
not to include an option that might conflict, or put a 3:1 majority
requirement on it because they think it conflicts.

However, if an option that might conflict wins, the Secretary might
have to decide if it conflicts or not, and if it conflicts void the
GR.


Kurt

Re: Changing how we handle non-free firmware

[Steve McIntyre]

Hi Simon!

On Mon, Aug 29, 2022 at 09:06:38AM +0200, Simon Josefsson wrote:
>
>==
>
>We continue to stand by the spirit of the Debian Social Contract §1
>which says:
>
>   Debian will remain 100% free
>
>   We provide the guidelines that we use to determine if a work is
>   "free" in the document entitled "The Debian Free Software
>   Guidelines". We promise that the Debian system and all its components
>   will be free according to these guidelines. We will support people
>   who create or use both free and non-free works on Debian. We will
>   never make the system require the use of a non-free component.
>
>Therefore we will not include any non-free software in Debian, nor in the
>main archive or installer/live/cloud or other official images, and will
>not enable anything from non-free or contrib by default.
>
>We also continue to stand by the spirit of the Debian Social Contract §5
>which says:
>
>   Works that do not meet our free software standards
>
>   We acknowledge that some of our users require the use of works that
>   do not conform to the Debian Free Software Guidelines. We have
>   created "contrib" and "non-free" areas in our archive for these
>   works. The packages in these areas are not part of the Debian system,
>   although they have been configured for use with Debian. We encourage
>   CD manufacturers to read the licenses of the packages in these areas
>   and determine if they can distribute the packages on their CDs. Thus,
>   although non-free works are not a part of Debian, we support their
>   use and provide infrastructure for non-free packages (such as our bug
>   tracking system and mailing lists).
>
>Thereby re-inforcing the interpretation that any installer or image with
>non-free software on it is not part of the Debian system, but that we
>support their use and welcome others to distribute such work.
>
>==

This last bit of wording is slightly unclear to me. Should *Debian* be
allowed to distribute an installer or image with non-free software on
it?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< liw> everything I know about UK hotels I learned from "Fawlty Towers"

Re: Changing how we handle non-free firmware

[Steve McIntyre]

Hi Kurt!

On Sat, Aug 27, 2022 at 04:26:40PM +0200, Kurt Roeckx wrote:
>On Fri, Aug 19, 2022 at 11:26:51AM +0100, Steve McIntyre wrote:
>> Hey Wouter!
>> 
>> On Fri, Aug 19, 2022 at 12:19:55PM +0200, Wouter Verhelst wrote:
>> >On Thu, Aug 18, 2022 at 08:58:21PM +0100, Steve McIntyre wrote:
>> >> system will *also* be configured to use the non-free-firmware
>> >> component by default in the apt sources.list file.
>> >
>> >What's the rationale for this one?
>> >
>> >I think it would make more sense to only configure the system to enable
>> >the non-free-firmware component if the installer determines that
>> >packages from that component are useful for the running system (or if
>> >the user explicitly asked to do so).
>> 
>> That's a fair point, my text was unclear here. Let's tweak it:
>> 
>> "Where non-free firmware is found to be necessary, the target system
>>  will *also* be configured to use the non-free-firmware component by
>>  default in the apt sources.list file."
>> 
>> Does that sound better?
>
>Is this something you want to adopt?

Yes, I think it improves things.

>Would a non-free-firmware section in the archive be useful, so
>that other non-free software is not enabled by default?

Definitely, that's an important feature here IMHO. We already have
that new section available, it's just not supported everywhere yet.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"C++ ate my sanity" -- Jon Rabone

Re: Changing how we handle non-free firmware

[Simon Josefsson]

Vincent Bernat  writes:

> On 2022-08-23 10:39, Simon Josefsson wrote:
>
>> Therefor we will not include any non-free software in Debian, nor in the
>> main archive or installer/live/cloud or other official images, and will
>> not enable anything from non-free or contrib by default.
>
> The initial proposition was also pushing a new non-free-firmware
> component. Are you also against a new component that could be enabled
> by users without enabling contrib/non-free?

I don't know what that is so have not formed an opinion, but introducing
a new component or not sounds orthogonal to the question whether to
include non-DFSG content in the installer and enable it on installed
systems by default -- which I believe is against both the spirit and
letter of Debian's social contract.

/Simon


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Vincent Bernat]

On 2022-08-23 10:39, Simon Josefsson wrote:


Therefor we will not include any non-free software in Debian, nor in the
main archive or installer/live/cloud or other official images, and will
not enable anything from non-free or contrib by default.


The initial proposition was also pushing a new non-free-firmware 
component. Are you also against a new component that could be enabled by 
users without enabling contrib/non-free?