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

Re: Debian-installer, older hardware, boot loaders, miboot & amiboot & ..

Scripsit Lewis Jardine <s9902074@sms.ed.ac.uk>
> Henning Makholm wrote:

> > Read my lips: I am *not* talking about "a *functionally* identical
> > result" or "clean rooms". I am talking about a deliberate (and quick)
> > reconstruction of assembler source for the excat bits that Apple has a
> > copyright on.

> How does this differ from simply running the code through a
> disassembler?

Not much, except in order to get source that we could comfortably
comsider source for the purposes of DFSG, we'd need to distinguish
between assembler instructions and data values (such as magic values
for the ROM bootloader and other meta-information about the
partition), and also add some comments.

> In my opinion, there is a very good chance that Apple would be able
> to claim that this not reverse engineering, merely copying in court,
> and win.

Exactly. That's why my suggestion was "ask Apple for permision to do
it this way" rather than just "do it this way instead".

> This being the case, what's the point in providing disassembled
> source?

We need to be able to provide source in order to put the thing in main
or contrib.

> It is very likely that the bootsector is straight-line code, for which
> assembler source gives very little benefit over machine code.

I think that even for straight-line code, assembler source is more
readable and maintainable than hex. Definitely more preferred for

> If you can make a disassembly with such minimal effort, why not just
> ask Apple to release the boot sector into the public domain?

That would work too, but would be asking more than we need. They may
be happier with allowing us to license the reconstructed source as
GPL, for example. (I'm thinking about knee-jerk reactions from
corporate lawyers here, of course. But only knee-jerking corporate
lawyers would dream of enforcing copyright on a 20-year-old boot
block anyway, so those are the ones we have to target).

> If the code is as small and simple as described, clean-room
> implementation should take about as much time as getting a reply from
> Apple

The problem with clean-room implementations is not so much producing
them as debugging and testing them enough to be reasonably sure that
they will work in *all* computers that were built to accept the
original. If we could (legally) produce something what is bitwise
identical to the original, we could sidestep that whole problem.

Henning Makholm                                   "No one seems to know what
                                       distinguishes a bell from a whistle."

Reply to: