On Sun, Apr 25, 2004 at 03:39:55PM -0400, Nathanael Nerode wrote: > Yep. I have not complained about those which are not obviously microcode. You're right, you have not. My post also wasn't targeted at you. Without a clear policy on the matter, I believe we are in danger of crossing the bounds of reason. I intended to demonstrate that the current method of determining whether an otherwise free binary blob is not DFSG-free, is too much of a "put a finger to the wind" approach for it to scale to the size of this project. > Putting burden of proof in the wrong place, again. At the very least, if it > looks and smells like machine code, and I have no evidence that it isn't, > I'm going to assume it is. Anything else would be stupid. Stupid? It looks like two different approaches to the same problem. Your approach presumes guilt and waits for someone else to confirm innocence. It may be the safest approach in a ridiculously pedantic way, but I don't see how it renders all other approaches stupid. Another approach would be to tread carefully around unidentified blobs, separating them from program material when possible, but not sending them to non-free on the sole basis that we have not the means to identify them. > How about the label "microcode (from ATI)"? In this given instance, certainly. Do the circumstances of this instance map onto all instances of the same general problem? > Anyway, perhaps you're thinking too abstractly. Naw. > For any given blob, the question is "is this the preferred form for > modification?" If it looks like it's a large quantity of microcode, then > given that almost nobody hacks large quantities of microcode in hex, we > figure it's probably *not*. If it looks like it's something else, we deal > with that in the way that's appropriate for that. What is a large quantity? The current forms of microcode seem to be less than 1K large on average. I can say with absolute certainty that I have maintained assembly listings of that approximate size without the help of a high-level compiler. In any case, the DFSG says nothing about the preferred form of modification whatsoever. It says "source". An assembly listing of a program originally compiled in C would satisfy the DFSG requirement. Additionally, if something is not a program, its source is not required by the DFSG. This is only an issue in the GPL-compatibility context: > > said tool in our hands to verify such claims. Also, if we went this > > route, a binary-blob which was previously free could be rendered > > non-free by a vendor suddenly creating a tool which generates such > > blobs. Would that make any sense at all? > No, that's not right at all. It's a *particular* blob we're talking about, > and it's the factual question of whether it is the preferred form for > modification. If no high level tool exists, then the binary is the preferred form. If a high level tool exists, and people use it to generate the binary, then the high level source is the preferred form. > In the cases which have been removed, I haven't met anyone who's admitted to > modifying the 'blob' form of microcode, and it's a form which is almost > always modified in a different form. (If people said "Oh yeah, we modify > the hex," that would be factual evidence that it *was* the preferred form.) Finding out how people do not modify the binary is irrelevant. The question is, have you met anyone who confirmed that they modify it in a higher-level form which is then compiled to the binary form, and do the numbers of those people outweigh the numbers who hand-hack it? If so, then the binary is not the preferred form. This is why the "preferred form" clause in the GPL needs work. Preference is subject to individual taste and the constraints of a given project. The most convenient metric for preference would be the results of a survey. Anything else is just handwaving. > In contrast, in the case of the various lookup and transformation tables in > the sound drivers, which are *also* hex blobs, their creation is > documented, and I can believe (in some cases) that they are modified by > hand. Excellent! That is the type of information that needs to accompany these blobs to remove all question as to their GPL compatibility. Back to Debian: > The firmware hunks we're talking about are definitely executable programs, > though. Nobody has actually claimed that they aren't. Although some > people have claimed that "we don't know", we're actually pretty sure. So > Debian requires source for them to go into 'main'. Here's where my personal involvement comes in. The WARP microcode in the MGA XFree86 driver is to be removed to non-free. I have seen nothing that indicates the microcode is a program, besides the fact that it is referred to as "microcode". I have never seen any technical details on the microcode or the WARP core aside from the slim mention in the databook, and the smashed-together doc on how to send vertex data and 3D commands to the "microcode" that was released in a previous life of Matrox. So we have a couple hundred bytes of "microcode" for each "program" that is loaded into the "processor". Without more documentation or confirmation from Matrox on the nature of the blob or the G-series chips, there is nothing, besides the name "microcode" in the variables, to lead us to believe that these things are actually programs and user-modifiable to produce different behavior. After all, I could just start naming random binary blobs asdf_microcode in my programs, just to induce false positives with this heuristic. For all we know, they are configuration images ala configurable logic devices, or a sequence of bytes that are sent to initialize various registers within the WARP or to configure the order of existing logic units within the hardware. It is not a program if the state machine does not use the data to determine what state to proceed to next. If it is not a program, DFSG#2 does not require source. So anyway, this is getting moved to non-free, and the situation will be much worse than before. There are two possibilities that are acceptable to me: 1) mga_ucode left alone in XFree86 driver (not going to happen, as this blob-without-source is part of a program and would cause XFree86 driver to fail DFSG#2) 2) mga_ucode split out to a separate file loaded at runtime by XFree86 driver and distributed with XFree86 since it is assumed to not be a program and thus satisfied DFSG (my preferred approach) There is a third approach that still sucks, but isn't quite so bad. 3) mga_ucode assumed to be guilty program-without-source. moved to non-free. XFree86 driver checks for its existence and loads it if it is there. If not, 3D functions don't work, nor does RENDER. I think 2D is still operational. But instead, we are doing the following: 4) mga_ucode moved to non-free. Kernel ioctl developed to load a microcode. XFree86 driver has to call this ioctl every time it wants a new ucode loaded, and a userspace agent is invoked on its behalf to find the microcode file and load it. Now we have 3-4 context switches per polygon depending on how many pipeline stages are needed, since there is a different ucode for each pipeline stage (and also different ucodes when multitexturing is being used). I am going to hate my mga card really quickly if this approach is seriously taken. But I seem to have little leverage to convince people that assuming ucode==program and waiting to be proven wrong is a worse idea than the inverse. Seriously inconveniencing users in the face of dubious and perhaps not even any gain in freedom does not seem to be a good plan to me. But I am only one voice. I can undermine my own argument here by saying that I feel inconvenienced by Matrox in that I feel that it is possible to implement T&L pipeline stage on G-series hardware, but cannot because of lack of docs or source to the current microcode (if it is a program). But by saying that, I am making an assumption that the hardware is capable of even doing such a thing, and that the current "microcode images" are not just playing a connect-the-dots game with fixed hardware functionality units. We can assume one way or the other in this case. If we assume they are programs and fail DFSG#2, the user gets a serious inconvenience, and if it is a false positive, we have not gained anything in freedom; and if the guess happens to hit the mark, we still have gained no leverage with Matrox, though we have succeeded in our goal of freedom. If we assume they are not programs, it is possible that a false negative will be applied. Either way, in the short run, the user will not be inconvenienced. In the long run Matrox will not change their ways. It is a trade-off of a definite outcome versus a roll of the dice. We are trading a 100% chance of an inconvenience to users, for a less-than-100% chance that the blob in any particular case is a program-without-source and is thus hampering the freedom of the user. > > If programs(=software, then the given statement is true, if we consider > Do you mean != perhaps? or <= ? Subset relationship. > > non-executable supporting materials not to be software. > Do you mean "to be software, but not to be programs"? Yes. I keep making that slip and it keeps undermining my argument. :) -- Ryan Underwood, <nemesis@icequake.net>
Attachment:
signature.asc
Description: Digital signature