Re: The future of "nv" driver (was: Linux compatible mainboards -another thought)
On Mon, 26 Apr 2010 17:03:07 -0500
"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> wrote:
> On Monday 26 April 2010 16:34:36 Celejar wrote:
> > On Mon, 26 Apr 2010 16:16:32 -0500
> > "Boyd Stephen Smith Jr." <bss@iguanasuicide.net> wrote:
> > > On Monday 26 April 2010 15:09:57 Celejar wrote:
> > > > What makes the non-free firmware question particularly interesting is
> > > > that the alternative is often to hardcode the functionality into the
> > > > hardware. Now, if you had a board with completely closed HW, but that
> > > > presented an open, well documented interface for the driver, most
> > > > people would be very happy (although there are, of course, the open
> > > > hardware crusaders - more power to them!). So, now that they've simply
> > > > implemented some of that functionality in SW, in the form of firmware
> > > > which the driver installs on the card, but which has nothing to do with
> > > > your host machine, are you really any worse off?
> > >
> > > As a distributor you may very well be. If you can't provide the source
> > > code, you can't satisfy the terms of the GPL (usually).
> >
> > ? We're talking about firmware for things like wireless cards, produced
> > by the HW manufacturers, e.g., Broadcom. Where does the GPL enter into
> > this?
>
> Some are included in the tarball provided by the Linux kernel team, which is
> distributed under the GPLv2. In particular, I am thinking of the iwl3945
> firmware that is required to run my wireless card.
>
> It doesn't matter what upstream wants to call source code. The GPL(v2)
> defines it as the preferred form for making modifications. (GPLv2, section
> 3.) It is unlikely that the firmware was written in a hex editor (or
> equivalent). Most likely it is C source for a freestanding (non-hosted)
> environment with some manufacturer-specific libraries, but it could also be in
> some manufacturer-specific assembly code. Either form would be better for
> making modifications than a binary blob.
This is all very well, but the context of this subthread is James's
statement that he avoids installing the non-free firmware that his HW
requires out of a commitment to FLOSS ideals, to which I responded that
I'm not sure if one is really worse off installing such firmware, or
using a card that just has that logic built in to its non-free HW.
Celejar
--
foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator
mailmin.sourceforge.net - remote access via secure (OpenPGP) email
ssuds.sourceforge.net - A Simple Sudoku Solver and Generator
Reply to: