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

Rahul Sundaram sundaram at fedoraproject.org
Tue Mar 25 20:44:22 UTC 2008


Alexandre Oliva wrote:
> On Mar 25, 2008, Rahul Sundaram <sundaram at fedoraproject.org> wrote:
> 
>> Similarly, you can choose to incrementally move things out of the
>> kernel which judging from this thread is a approach that Fedora can
>> work with without having to introduce a new kernel.
> 
> 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? Permanently carrying a variant 
doesn't look like a feasible solution to me.

>> Just look at the mess with a separate xen kernel to understand this.
> 
> I do understand it, and I realize it's a very different issue.
> Removing code, as done in kernel-libre, is *much* easier than
> forward-porting large patches.

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.

> 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. Remember, Free software 
development originally happened on proprietary systems before getting 
incrementally replaced by Free software bits.

Rahul




More information about the devel mailing list