Re: LCC and blobs
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 might even have an (expensive) calculator that has Matlab in a ROM,
which would make these cases even more parallel.
> 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.
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
> 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
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. 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.
> 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.
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".)
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