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 fedora-devel-list
mailing list