Re: LCC and blobs
Glenn Maynard <glenn@zewt.org> writes:
> On Sat, Dec 18, 2004 at 01:28:46AM +0100, Måns Rullgård wrote:
>> >> I'm convinced enough. Some time ago, I was playing around with an
>> >> emulator for Texas Instruments calculators. It obviously required a
>> >> ROM image to be useful, and the only legal way of obtaining one was
>> >> dumping it from your own calculator (an easy task). I still found
>> >> this emulator useful, since I happen to have one of the calculators.
>
>> > By your reasoning, everything in contrib should be moved to main, and
>> > contrib should not exist.
>>
>> That's not what I said, nor what I meant. For instance, a Matlab
>> program no doubt depends on Matlab, which is clearly non-free.
>
> Some time ago, I was playing with a program that depended on Matlab.
> it obviously required Matlab to be useful, and the only legal way of
> obtaining it was to purchase it. I still found the software useful,
> since I happened to own a license to Matlab.
>
> Matlab is non-free, just as the BIOS that you're copying off of the
> calculator is non-free; both the Matlab program and the emulator go
> in contrib, for the same reason.
I'm arguing the reasons are quite different. In the Matlab case, the
program could be considered to a piece of data, only useful together
with a program that knows what to do with it (in this case interpret
it as Matlab statements). The emulator is a program in its own right,
but requires some data to operate on (a ROM image). Those ROM images
that happen to be useful in practice for most people are of course
those found in actual calculators. The emulator could, however, also
be used by someone developing other (free) firmware.
> I might even have an (expensive) calculator that has Matlab in a ROM,
> which would make these cases even more parallel.
But then Debian wouldn't be involved at all. Debian is an operating
system for PC/workstation/server-class computers. Talking about
Matlab programs to be run by Matlab on a computer/calculator not
running Debian has no more significance in a discussion about Debian
than does any win32 application, for example.
>> OK, then it's about time someone removes libti68k ("Motorola 68000
>> emulation library for Texas Instruments calculators") from main. Not
>> only does it require a ROM image, it also depends on libticalcs3 and
>> libticables3, both of which require an actual calculator, and hence
>> the firmware (let's call it firmware, to make the analogy easier to
>> see), without which the calculator is useless.
>
> Requiring a calculator for a program designed to manipulate that
> calculator is OK, in the same fashion that requiring a 3c905 is OK
> for a 3c905 ethernet driver. The difference between software
> driving a piece of hardware, and an emulator requiring a non-free
> BIOS block (that happens to be available on a piece of hardware)
> seems clear to me.
Yes, there is a difference, but not one I consider significant. The
driver requires the hardware. When you buy the hardware, you receive
a box containing the hardware, and a CD with whatever drivers and
firmware are required to use it. Why is it OK to depend on the actual
PCI card, but nothing else in the box?
> While I can understand (even if I disagree with) arguments that they are
> the same, the conclusion of that line of reasoning seems to be "merge
> contrib entirely back into main", since I can take any non-free library,
> stick it in a flash, and say "look, now it's a hardware dependency!".
>
> (I don't have the energy to file a bug against libti68k about this at
> the moment, but if what you say is accurate, I suspect it should be
> done.)
I notice that gtktiemu, which seems to be little more than a frontend
to libti68k is in contrib.
I only started talking about emulators because someone said they were
useless without non-free software, and I happened to find on in main.
It is really beside the point under discussion.
>> Now you'll say the calculator doesn't need the firmware to be loaded
>> every time you want to use it, and that would somehow make a
>> difference. Suppose now, that TI released a new model, which didn't
>> have flash memory, so it would need to be reloaded if the batteries
>> were removed, while in all other respects being compatible to the
>> previous models. Would this suddenly render all those libraries
>> non-free?
>
> No, because (as has been said already) the existance of cases where
> you need non-free stuff isn't the issue; the issue is whether there
> exist cases where you don't. If nobody can use the software without
> needing non-free data, the software is (at best) contrib.
But if all the calculators required a reload after battery removal,
then the communication software would be non-free?
> If some people can use it without that data, it can go in main,
> regardless of the existance of people who can't. The existance of a
> free Matlab, or of a free calculator BIOS, would allow the program
> using Matlab and the BIOS emulator into main. The reason each is
> (or in the emulator case, should be) in contrib is because a free
> version of this stuff does not exist, not because non-free versions
> do exist.
I fail to see how the free-ness of some particular piece of code (the
driver) can depend on whether some hardware uses flash or volatile
memory.
>> Suppose some piece of hardware had a Compact Flash reader, and came
>> with a Compact Flash card containing firmware necessary for the
>> hardware to run. Would this also be non-free?
>
> I believe software that only works with this reader would go in contrib,
> if that's what you mean, unless the data on that card was Free itself.
I meant something like a PCI card that was capable of loading its
firmware from an onboard Compact Flash reader. If such a design made
the driver non-free, just take one of these cards, glue the Compact
Flash module to the socket. This would be equivalent of having the
firmware builtin, so this case must be considered free.
Imagine now that this PCI card also had the option of receiving its
firmware from the driver. Would this make a difference?
> It's a dependency on non-free software. (It's not the same as having
> the firmware stored in flash memory on a device, since removable devices
> are expected to be removed, overwritten, or lost; where I'd call a device
> with a hosed flash "broken". (The former I'd sell on eBay as "drive
> only, no packaging, drivers or manuals"; the latter I'd expect to see
> sold "AS-IS, UNTESTED".)
What about a card with firmware in a socketed flash chip? If the
manufacturer were kind enough to include a copy of the firmware on a
CD, so someone with adequate hardware could reprogram it in case of
damage, would this also be considered non-free?
> However, this is a corner case, and I think the "simpler" cases of simple
> on-card flash should be dealt with before banging our heads on the corner
> cases.
With the firmware-is-software viewpoint, the corner cases become very
many, and very tricky, indeed. I can think of many more, even nastier
ones...
Why is it that it makes any difference whatsoever, by which means the
firmware is loaded onto the hardware?
--
Måns Rullgård
mru@inprovide.com
Reply to: