Re: Going ahead with non-free-firmware

[Hideki Yamane]

Hi,

On Sun, 24 Feb 2019 16:44:39 +0100
Ansgar  wrote:
> Sadly no; I think some later discussion made me doubt that there was
> indeed consensus about having non-free-firmware (and only that and not
> non-free-doc, non-free-drivers, non-free-*).  Nor about how it would
> work.
> 
> I don't think we should add a new component without having that
> (component meaning main, contrib, non-free, non-free-firmware here).
> They are not nice to handle on the archive side.

 Thanks for your reply. Well, then is there any proposal to improve
 setting non-free firmware in installer now?


-- 
Hideki Yamane 

Re: Going ahead with non-free-firmware

[Ansgar]

Hi,

Hideki Yamane  writes:
>  Is there any progress about non-free-firmware section?

Sadly no; I think some later discussion made me doubt that there was
indeed consensus about having non-free-firmware (and only that and not
non-free-doc, non-free-drivers, non-free-*).  Nor about how it would
work.

I don't think we should add a new component without having that
(component meaning main, contrib, non-free, non-free-firmware here).
They are not nice to handle on the archive side.

Ansgar

>> Hi,
>> 
>> I think there was consensus to introduce the non-free-firmware section
>> and move the non-free firmware blobs there.  I'm wondering what we need
>> to do next?
>> 
>> Besides the ftp team setting the new section up, I expect the installer
>> would need changes to enable it instead of non-free when non-free
>> firmware is required; maybe it still needs to ask for non-free as well
>> for other reasons?  Other teams might also need to add the new section,
>> e.g. the release team, packages.d.o, ...  I expect the list to be
>> hard-coded in quite a few places.
>> 
>> Then the release notes need to document that "non-free-firmware" might
>> have to be added to sources.list.
>> 
>> Finally we need to identify the packages that should move there.  I
>> guess all non-free packages named "firmware-*" would be a good match.
>> 
>> Ansgar

Re: Going ahead with non-free-firmware

[Hideki Yamane]

Hi,

 Is there any progress about non-free-firmware section?


> Hi,
> 
> I think there was consensus to introduce the non-free-firmware section
> and move the non-free firmware blobs there.  I'm wondering what we need
> to do next?
> 
> Besides the ftp team setting the new section up, I expect the installer
> would need changes to enable it instead of non-free when non-free
> firmware is required; maybe it still needs to ask for non-free as well
> for other reasons?  Other teams might also need to add the new section,
> e.g. the release team, packages.d.o, ...  I expect the list to be
> hard-coded in quite a few places.
> 
> Then the release notes need to document that "non-free-firmware" might
> have to be added to sources.list.
> 
> Finally we need to identify the packages that should move there.  I
> guess all non-free packages named "firmware-*" would be a good match.
> 
> Ansgar

-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Re: Going ahead with non-free-firmware

[Adam Wilson]

On Sat, 9 Jan 2016 19:27:22 -0500
Hendrik Boom  wrote:

> On Sat, Jan 09, 2016 at 10:36:53PM +0100, Philippe Cerfon wrote:
> > And btw:
> > Even if Debian doesn't want to do the non-open thing now or perhaps
> > generally doesn't want to allow people to opt-out of closed source
> > software while keeping other non-free software, then the name
> > non-free-firmware seems to break the current naming, doesn't it?
> > main
> > contrib
> > non-free
> > 
> > These all give the "license status" of their packages.
> > But non-free-firmware, would give license status and package type.
> > 
> > 
> > Oh and since this has been brought up by someone.
> > It seems better if packages wouldn't be in multiple suites.
> > That's also what I'd have intended with non-open, in other words, a
> > package that is in non-open is only there and not also in e.g.
> > non-open/firmware (and vice versa).  
> 
> Maybe closed-source would be clearer than non-open.
> 
> -- hendrik
> 

One thing that really bugs me about the Debian component system is failure to
differentiate between software (the functional component to any computer
system) and data (the non-functional component of a computer hardware/software
system). Example: I personally oppose non-free software and will not install or
run it. But I have no such qualms about non-free data- that is something for
the free *culture* movement, not the free *software* movement- of which Debian
is a project, and in which Debian should maintain its focus.

The inclusion of both non-free software and data in non-free means that in
order to use, say, AlienArena, which is free software but relies on non-free
data, one must enable both non-free and contrib! It is a pretty silly
situation- that in order to play a free game one must sacrifice their freedom
and enable the non-free component.

I would divide the Debian package repository as follows:

1. free-software
This would be for free software.

2. free-data
This would be for free data.

3. non-free-software
This would be for non-free software.

4. non-free-data
This would be for non-free data.

One could go even further and divide the non-free-software component into
components based on exactly *what* freedom is being withheld- so 'drm' (for
freedom 0), 'no-source' (for freedom 1), 'non-redistributable' (for freedom 2)
and 'non-modifiable' (for freedom 3) or something along those lines.

Of course, being a free software fanatic myself, I would prefer that Debian
just stopped encouraging the use of and distributing non-free software, but
since that isn't happening anytime soon, I see this as the best solution.

Re: Going ahead with non-free-firmware

[Adam Wilson]

On Sat, 9 Jan 2016 20:56:08 +0800
Paul Wise  wrote:

> On Sat, Jan 9, 2016 at 6:51 PM, Ansgar Burchardt wrote:
> 
> > I think there was consensus to introduce the non-free-firmware section
> > and move the non-free firmware blobs there.  I'm wondering what we need
> > to do next?  
> 
> I have a question about the implementation; will non-free firmware be
> in non-free and non-free-firmware or just non-free-firmware?
> 

If one wanted both non-free firmware and other non-free packages one would
simply enable both non-free and non-free-firmware. There need be no duplication
of package placement.

Going ahead with non-free-firmware

[Ansgar Burchardt]

Hi,

I think there was consensus to introduce the non-free-firmware section
and move the non-free firmware blobs there.  I'm wondering what we need
to do next?

Besides the ftp team setting the new section up, I expect the installer
would need changes to enable it instead of non-free when non-free
firmware is required; maybe it still needs to ask for non-free as well
for other reasons?  Other teams might also need to add the new section,
e.g. the release team, packages.d.o, ...  I expect the list to be
hard-coded in quite a few places.

Then the release notes need to document that "non-free-firmware" might
have to be added to sources.list.

Finally we need to identify the packages that should move there.  I
guess all non-free packages named "firmware-*" would be a good match.

Ansgar

Re: Going ahead with non-free-firmware

[Paul Wise]

On Sat, Jan 9, 2016 at 6:51 PM, Ansgar Burchardt wrote:

> I think there was consensus to introduce the non-free-firmware section
> and move the non-free firmware blobs there.  I'm wondering what we need
> to do next?

I have a question about the implementation; will non-free firmware be
in non-free and non-free-firmware or just non-free-firmware?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Going ahead with non-free-firmware

[Cyril Brulebois]

Ansgar Burchardt  (2016-01-09):
> I think there was consensus to introduce the non-free-firmware section
> and move the non-free firmware blobs there.  I'm wondering what we need
> to do next?
> 
> Besides the ftp team setting the new section up, I expect the installer
> would need changes to enable it instead of non-free when non-free
> firmware is required; maybe it still needs to ask for non-free as well
> for other reasons?  Other teams might also need to add the new section,
> e.g. the release team, packages.d.o, ...  I expect the list to be
> hard-coded in quite a few places.

As far as the installer goes, I suspect things like the following packages
might need to be looked at:
 - apt-setup
 - discover, discover-data

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Going ahead with non-free-firmware

[Philippe Cerfon]

And btw:
Even if Debian doesn't want to do the non-open thing now or perhaps
generally doesn't want to allow people to opt-out of closed source
software while keeping other non-free software, then the name
non-free-firmware seems to break the current naming, doesn't it?
main
contrib
non-free

These all give the "license status" of their packages.
But non-free-firmware, would give license status and package type.


Oh and since this has been brought up by someone.
It seems better if packages wouldn't be in multiple suites.
That's also what I'd have intended with non-open, in other words, a
package that is in non-open is only there and not also in e.g.
non-open/firmware (and vice versa).

Thanks and regards,
Philippe

Going ahead with non-free-firmware

[Philippe Cerfon]

Ansgar Burchardt wrote:
> I think there was consensus to introduce the non-free-firmware
> section
> and move the non-free firmware blobs there.  I'm wondering what we
> need
> to do next?

While it's good that at least something happens it's really sad and
kinda disturbing to see that a more narrow-minded solution is taken,
while a better proposal lies on the table.
Especially since the non-free-firmware seems to make it less likely,
that a non-open could ever happen.

When Debian is anyway about to add new suites and people will have to
adapt to that, why not implementing a more powerful schema that not
only allows to opt-in to closed-source firmware, but also allows to,
at the same time, opt-out of other closed-source software, while
allowing at the same time to opt-IN to non-free, but open software?

It'll be just one further suite that needs to be added, gaining far
more possibilities.

- non-free (as the current non-free, excluding anything that would
need to go to non-open)
- non-open (everything from non-free for which there are no sources available)
- non-open/firmware (firmware that would be in non-open)

perhaps arguably a 4th one:
- non-free/firmware (i.e.that would be firmware that is open but not
e.g. freely distributable, but does that even exist?)

Alternatively one could just have:
- non-free (as the current non-free, excluding anything that would
need to go to non-open)
- non-open (everything from non-free for which there are no sources available)
- firmware (any non-free or non-open firmware)


So again, what's wrong with the proposal I've made few days ago in #809705?
It doesn't seem to require much more technical work, just moving
packages and it's a far more powerful solution.


Sincerely,
Philippe.

Re: Going ahead with non-free-firmware

[Hendrik Boom]

On Sat, Jan 09, 2016 at 10:36:53PM +0100, Philippe Cerfon wrote:
> And btw:
> Even if Debian doesn't want to do the non-open thing now or perhaps
> generally doesn't want to allow people to opt-out of closed source
> software while keeping other non-free software, then the name
> non-free-firmware seems to break the current naming, doesn't it?
> main
> contrib
> non-free
> 
> These all give the "license status" of their packages.
> But non-free-firmware, would give license status and package type.
> 
> 
> Oh and since this has been brought up by someone.
> It seems better if packages wouldn't be in multiple suites.
> That's also what I'd have intended with non-open, in other words, a
> package that is in non-open is only there and not also in e.g.
> non-open/firmware (and vice versa).

Maybe closed-source would be clearer than non-open.

-- hendrik