Plan for tomorrows (20080522) FESCO meeting

[Alexandre Oliva]

On May 21, 2008, David Woodhouse <dwmw2 at infradead.org> 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}