Linux Libre in Debian

[Simon Josefsson]

Jason Self <j at jxself.org> writes:

> On Tue, 2025-12-09 at 09:33 +0100, Simon Josefsson wrote:
>> So even if the deblob scripts will disappear, running a diff between
>> the linux-libre tarball that you publish and the upstream linux
>> kernel code, then applying that patch during build, will result in
>> the same input source for the build process.  So I think this
>> approach of doing a "delta" package can continue to work even if the
>> deblob scripts would disappear.
>
> Except not so much:
>
> On Mon, 2025-12-08 at 04:51 -0300, Alexandre Oliva wrote:
>> ...but publishing such scripts is probably not going to work,
>> freedom-wise.
>
> We currently have diffs that don't get published because the diffs
> contain the problematic stuff being deleted. Sharing them means also
> sharing that.

Agreed, but that is not a concern for the Debian community as they
already (and will continue to) ship non-free stuff in the kernel.

So preparing the delta patch is not something I expect you in the
linux-libre project to do forever.  It can be done by someone else.

Yes, a linux-libre-in-Debian effort is a compromise, more than what
linux-libre upstream is.  I think it helps to think of it as bringing
GNU tools to a non-free platform like Solaris, Windows or macOS.  You
are stuck with the limits of that OS and the community around it. But
the alternative to say, no, Emacs will not support macOS, may hurt more
than it helps.

And also, yes, I think we should go further than this.  ALSO.  So please
do for linux-libre.  But I see no technical conflict with working on
both efforts in parallel, and I think there is synergy between them, so
I appreciate discussion about this.

This is the main reason I'm hesitant about using the 'linux-libre' name
without blessing.

I think the practical outcome of the effort (a binary
'linux-image-libre' package that can be booted) is the same.  So the
name is relevant and appropriate from a user perspective.

However the process to get there may differ, as you explain.  A libre
kernel in Debian probably practically (at least today) have to start
from the Debian kernel source code with its non-free stuff in it.
Linux-libre upstream doesn't have to do that, but can re-create an
entire linux-libre git repository from the start without any non-free
blobs in it.  Sounds like a really large task, but is important for the
free software community.  Eventually such a source tarball may make it
into Debian proper, and then it does make some sense to have both
'linux-libre-image' and 'linux-deblob-image' in parallel (for some time)
to audit for differences.

/Simon
-------------- 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/650d2155/attachment.sig>