Linux Libre in Debian

[Simon Josefsson]

Alexandre Oliva <lxoliva-3d8yaqT+vUfYtjvyW6yDsg at public.gmane.org>
writes:

> Hello, Simon,
>
> Thanks for undertaking debian-libre, it's very valuable IMHO.

Thanks for support!  I'm trying to navigate things in a way that makes
practical progress possible.

> On Dec  1, 2025, Simon Josefsson <simon-RTwAkxXyIg6Ei8DpZVb4nw at public.gmane.org> wrote:
>
>> Maybe naming here is a problem though.  If this doesn't use your
>> linux-libre sources, or even your deblob script, how do you feel about
>> even calling that 'linux-libre'?
>
> IMHO, as long as you follow the same approach and reach the same goal of
> GNU FSDG-compliance, there's no reason to mind your calling it
> Linux-libre, even if you need to adjust some details because you're
> starting from a slightly different baseline.

Ok.  I'm beginning to find the name 'linux-deblob' more appropriate to
what I'm attempting, because that 1) matches the approach taken to use
the deblob scripts, and 2) allows for a a futre 'linux-libre' package
following some other approach, and 3) doesn't hijack the linux-libre
name for things that may end up being somewhat different due to Debian
vs linux-libre packaging concerns.

If at the end of this 'linux-deblob' and 'linux-libre' is identical,
that's great, but there seems to be signs that there will be some small
differences (for example, the kernel config to use).  Calling something
similar but not identical by the same name may be confusing.

One pun here is that 'deblob' contains the beginning of 'DEBian' too.

> There's one concern in my mind, however, about what corresponding
> sources you'd publish.  If you just add cleaning-up scripts to Debian's
> sources, you'll be already better off than those who publish upstream
> sources plus scripts, because they still make binary blobs available
> under obnoxious licenses as part of their source trees, whereas I
> believe Debian cleans those up.  You might still be shipping plenty of
> binary blob names and freedom-averse pieces of documentation, unless you
> publish as corresponding sources the *result* of the cleaning up.

I'm not sure I follow all the subtleties involved here, but two
approaches:

1) A 'linux-deblob' Debian source package that have 'linux-source-6.18'
as Build-Depends and just contain the deblob-* scripts, run those on the
Debian source code (which contains offensive blobs), and build a binary
image package e.g. 'linux-image-deblob-*'.

2) Doing 1) but ALSO output a new binary package
'linux-source-deblob-6.18' which is the output of running the deblob
scripts on the source code.  I'm not sure what use there is for such a
package really, but maybe it fits some piece of the puzzle here.  It
would serve the same purpose as the current 'linux-source-6.18' package,
which is for later consumption by others who doesn't want to duplicate
the deblobing process.

> I'll second Jason's warning that the script-based approach to cleaning
> up is to be phased out when we switch to a manually-cleaned repository.

Debian is tarball centric, and if I understand correctly, the resulting
tarball of your linux-libre will be identical regardless if they were
prepared via git-scrubbing or through a deblob script.  So I'm not sure
this aspect is that relevant for Debian packaging.

> We will still have a deblob-check, but the plan was to not have a
> deblob-<kver> any more.
>
> That said, maybe we can figure out a way to turn diffs between upstream
> and libre releases into a script that cleans things up.  That may
> involve running patch to do part of the job, but publishing such scripts
> is probably not going to work, freedom-wise.

A future simulation of the 'deblob' script could be just doing:

1) wget linux-6.18.tar.gz
   wget linux-libre-6.18.tar.gz
   unpack
   diff -ur linux-6.18 linux-libre-6.18 > deblob-6.18.patch

2) and a hypothetical deblob-6.18 would just contain:
   patch -p1 < deblob-6.18.patch

This ought to work for Debian too, modulo some DFSG-cleanups that Debian
is already doing to the upstream source code.

For Debian needs, which is tarball centric, the current deblob-* script
approach seems easier to audit for what kind of non-free stuff is
actually removed, compared to the above approach.  The diff will not be
easy to read, whereas the deblob script appears to be as simple as they
can be.

>> anyone have ideas for names, that would be great ('linux-deblob'?).  I
>
> linux.deblibred could be fun if you'd rather go for a name other than
> linux-libre.

I like that!  Or 'linux-deblibre' combining both DEBian and 'libre'.  Or
'linux-deblib' to imply that this is a Debian-variant of the deblob
scripts.

/Simon

PS. This is a re-send, I think the original never showed up, sorry if
this ends up as a duplicate somehow.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1251 bytes
Desc: not available
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20251209/5f3e93f2/attachment-0001.sig>