[Top][All Lists]

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

Re: [GNU-linux-libre] Nouveau: NONFSDG listing and current status?

From: Brett Smith
Subject: Re: [GNU-linux-libre] Nouveau: NONFSDG listing and current status?
Date: Tue, 17 May 2011 17:31:46 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110223 Thunderbird/3.1.8

On 05/17/2011 04:44 PM, Rubén Rodríguez wrote:
>> Right now a nouveau-kernel-source package is listed on the NONFSDG
>> page ( 
> That entry relates to karmic and jaunty, which both reached end of life.

Well, that might be confusing point #1.  :)  Put that way, it's not
immediately obvious to me whether this means "The blobs were in the
upstream source as of karmic's release, but gone by lucid's," or whether
it means the blobs were specifically added in Ubuntu (less likely, but
still possible).

> The current nouveau implementation in most distros is blob-free,
> although it seems to be some new (optional, IIRC) blobs in the latest
> kernels, so partial deblobbing may be necessary again in the future.

That generally sounds like good news, thanks.  Is there a Nouveau
version number or something like that that made the whole thing nonfree?
 If so, I think it would be most helpful to list Nouveau generally in
NONFSDG, with a note that the problem was resolved as of version X --
that's a pretty common situation on the list at this point.

> About the other free drivers, I've been looking into the Radeon blobs,
> and in most cases they are simple 2kb -with some padding zeroes-
> register dumps for a state machine initialization. If someone more
> skilled than me could break them into something documented we could have
> a lot more cards supported.

If we know for *sure* that they're just initialization values for
registers, then I think they're okay to include as long as the license
allows it.  As the distro guidelines say:

"To be clear, not every array of numbers in a driver is firmware.
It's important to understand the purpose of the data before deciding
whether or not it's appropriate for a free system."

Initialization values aren't code as such and so they don't seem
problematic to me personally (although I wouldn't mind getting a second
opinion on that).

Brett Smith
License Compliance Engineer, Free Software Foundation

Support the FSF by becoming an Associate Member:

reply via email to

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