kernel-libre (hopefully 100% Free) for Fedora 8 and rawhide

[Alexandre Oliva]

On Mar 25, 2008, Rahul Sundaram <sundaram at fedoraproject.org> wrote:

> Alexandre Oliva wrote:
>> But this doesn't get me a kernel I can distribute today.  Or a kernel
>> I can use today.  Or a kernel that could go in Fedora 9.

> No, it wouldn't but we need to look at this from a long term
> perspective as well. If we agree to introducing a variant today, what
> have you planned to merge these changes upstream?

No plan, just awareness that upstream isn't interested in hearing
about this, especially from people like me, and realization that I'm
unsuited to make the suggested changes.

> Permanently carrying a variant doesn't look like a feasible solution
> to me.

Why do you think so?

It's not like we don't maintain a number of patches ourselves.

And we're not even talking about patches.  We're talking about a bunch
of 'rm -f's over upstream tarballs and 'sed "/x/,/y/d"' over upstream
patches.  Think IcedTea.

And then, if the kernel is indeed headed to moving firmware out, then
it's even more like IcedTea, because we'll eventually be able to
discontinue the separate package, in a similar fashion to the decision
to stop shipping non-smp kernels for x86_64.

But then, one way or the other, unless there's commitment from
upstream to not do this, we'd have to keep on monitoring the kernel to
make sure new non-Free bits don't sneak in.  And that's where most of
the maintenance goes.  Fortunately, I got this script that checks the
entire linux-libre-2.6.24 tarball for non-Free blobs in just over 10
minutes on my 3-year-old notebook.  But about 45 minutes for the
linux-2.6.24 tarball, that contains a bunch of nasty blobs that
trigger bad behavior from the regexps I've chosen; but I do have plans
to improve that, check the TODO in
http://www.fsfla.org/svn/fsfla/software/linux-libre/deblob-check

Most of the maintenance would be just automated checking in this
regard.  And then, since I have this checking built into the
kernel-libre package, at the time a patch is applied, all that it
really takes is scanning new kernel major releases, with the wisdom
from blobs that may have appeared in -rc and -git patches.  No biggie.

> Easier for you as the package maintainer but the overhead is not just
> for the maintainer. A new kernel variant is a big deal for a
> distribution and that is the reason you are seeing the opposition to
> the path you are taking.

I understand that.  I wish it could just be accepted as a package like
any other.  I don't quite see why the fact that it's an alternate
kernel is such a big deal.  Considering the social and political
issues, I don't see that this should be decided solely from a
technical standpoint.

>> And then, how would I post patches upstream that remove the offending
>> bits from upstream without re-distributing the very offending bits I
>> find it immoral to distribute in the first place?  That's why won't
>> even distribute a patch from original to modified sources: it contains
>> the non-Free bits in /^-/ lines.  That's a line I'm not willing to
>> cross.

> I don't understand this logic at all. If a piece of Free software has
> some non-free bits, you wouldn't do a patch to remove it? Sure, that
> patch would be in a form of a diff against the non-free code but I
> can't imagine why that would be considered immoral.

It would not only contain the entire piece of non-Free Software,
making it trivial for someone to reverse the patch to add it back
(that's why I distribute xdeltas for the tarballs and patches at
http://www.lsd.ic.unicamp.br/~oliva/snapshots/linux-libre/).

It's also that working to make it easier for people to use these
firmwares, I'm working in favor of a social problem, and against the
goals of Free Software movement.

> Remember, Free software development originally happened on
> proprietary systems before getting incrementally replaced by Free
> software bits.

Exactly.  That software was being used to develop its own replacement.
That's the only morally-acceptable reason to accept a non-Free
Software license, because it's a use that puts an end to the long-term
harm.

So, show me someone who's using non-Free firmware to develop a
replacement Free firmware, and I'll be happy to help them.

But if someone were to ask me to help people accept and use non-Free
firmware, which will in turn get more people into this trap, I'd
respond "Thanks, but no, thanks."

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}