On May 21, 2008, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: > On Wed, 2008-05-21 at 18:21 -0300, Alexandre Oliva wrote: >> I believe I've already explained why I can't do that. I refuse to >> distribute non-Free Software, and posting a patch that removes these >> bits amounts to posting those very bits. > Really, that's a stupid objection. Just post it in ed form. Assuming that's acceptable upstream. I sort of doubt it, but then, I could send xdeltas as well, and if you've been part of the discussion, then you probably know that that's not the only reason why I can't take part in this plan. Another I still haven't mentioned is that I have no interest in being harrassed and verbally abused like the last discussion about freedom issues I got into there. Now, let me show you why this proposed plan is an impossible mission that people are trying to drive me into. Consider this snippet from http://www.fsfla.org/svn/fsfla/software/linux-libre/scripts/deblob-2.6.25 # SND_KORG1212 - Korg 1212 IO clean_ifdef sound/pci/korg1212/korg1212.c CONFIG_SND_KORG1212_FIRMWARE_IN_KERNEL clean_blob sound/pci/korg1212/korg1212-firmware.h # SND_MAESTRO3 - ESS Allegro/Maestro3 clean_ifdef sound/pci/maestro3.c CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL # SND_YMFPCI - Yamaha YMF724/740/744/754 clean_blob sound/pci/ymfpci/ymfpci_image.h clean_ifdef sound/pci/ymfpci/ymfpci_main.c CONFIG_SND_YMFPCI_FIRMWARE_IN_KERNEL clean_blob() removes long sequences of numbers, whereas clean_ifdef() runs unifdef on the named file assuming the named variable is undefined. Could you honestly tell me, with a straight face and a reasonable degree of assurance, that a patch that performs these actions stands any chance whatsoever of being accepted upstream? The firmwares are already optional to compile in, they can already be loaded with the standard firmware loading machinery. But while they're there, in the source code, distributing the kernel sources amounts to distributing this non-Free Software, and distributing binaries built out of these sources, even with these options disabled, amounts to distributing the this non-Free Software as part of the kernel sources or committing to distributing it over the next 3 years. One way or another, it amounts to propagating the problem. If you tell me with a straight face that something like this stands a chance of being accepted, I will give that a try. Otherwise, please stop sending me in a mission that can't possibly be accomplished in a way that achieves our shared goals of providing users with freedom, with an operating system built out of only Free Software. If Fedora cares about users' freedom, why would it follow and abide by policies and dubious legal theories set by someone who doesn't and is proud of it? Does anyone think the issue about non-Free firmwares is any different from the issue of non-Free drivers for nvidia cards, except for the irrelevant detail that these different pieces of software can corrupt the system (technically and morally) running on different CPUs? Seriously? Why do we bend over to keep compatibility and even distribute binary-only code published by with vendors who have taken dubious measures such as releasing code under the GPL without sources, or explicitly contributing, to the kernel Linux, code under licenses incompatible with its license, when an alternative is readily available and looking forward to being included and with an active maintainer that has already proved to be able to keep up even with daily rawhide builds, and at the same time we proudly defend the decision to ship X drivers that disregard (for good reasons) compatibility with non-Free code? What is it that appears to make these issues different? Is nVidia any less supportive to our community than any of the other vendors who push hardware and then push non-Free Software to enable their customers to use the hardware at full power? Aren't we forgetting something, or drawing a line at a point that is absolutely arbitrary (which might be fine) and not in sync with our mission (with is certainly not fine)? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ¡Sé Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list