[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gNewSense-users] firmware in cx88-blackbird.c

From: Sam Geeraerts
Subject: Re: [gNewSense-users] firmware in cx88-blackbird.c
Date: Thu, 19 Jun 2008 22:31:50 +0200
User-agent: Mozilla-Thunderbird (X11/20080420)

Peter and Jesse wrote:
ubuntu/media/cx88/cx88-blackbird.c does not seem to have any large hex
tables, but has functions like blackbird_load_firmware. I identified it
as non-free, but maybe someone else should double-check.
By the way, maybe someone who knows more about this could update the
wiki site. The KFV site still implies that all we are doing is checking
for the license. What exactly are we looking for when we are looking for
firmware and blobs? We've covered this somewhat in our lists, but it
would be helpful if they were all compiled on the wiki.
 Peter Stevenson

I agree that it would be nice to have some rules of thumb for distinguishing non-free firmware/blobs. The problem is that a lot of times it's kind of a you-know-it-when-you-see-it thing. You can't really put a hard limit on how large a table of hex values should be to mark it as non-free.

There's also the problem of 'expert knowledge'. A table of hex values could seem unreadable in the eyes of a layperson, but the same table might make a lot of sense to an expert. [1] is not the best illustration of my point, but you get the idea. There's a huge thread somewhere on the fedora-devel mailing list where Alexandre Oliva lobbies for a strictly libre Fedora kernel. There, Alan Cox (among others) argues that

a) some hex data is common knowledge the field
b) some of it is the result of trial and error tweaking because that's the only way to develop for that kind of chip or hardware.

The trouble with (a) is that we probably don't have any experts working on gNewSense, so some data is probably incorrectly marked as non-free.

For (b) we need to decide wether this is an acceptable method to produce libre software. If so then we also need a way to recognize it.

More practically, what we could do (and should have done more formally during KFV) is make a clear note about why a certain piece of data or file is marked (or not marked) as a non-free blob. Those notes can be summarized in a table or list in the wiki. Every time a new (suspected) blob is found the list should be checked and if necessary extended.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]