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

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

Sorry for late reply.

On Tue, Mar 30, 2004 at 09:03:19AM +0200, Sven Luther wrote:
> Notice that there is 200bytes or so of m68k asm, most of them A-trap
> calls to the Mac OS rom, concerned. I doubt you have much chance of
> getting anything but a 100% identical code, whatever the way you go at
> generating it.
> Anything you may do, these calls are needed, you could add some noop
> calls in between, or some random stuff, but i doubt that this will be
> more than smoke and mirrors.

Case law (see Sega v. Accolade) suggests that trivial boot programs that
are required for third party interoperability with the hardware are not
copyrightable.  (See the part about the Genesis III console
specifically.  Accolade used a boot loader copied from commercial
Genesis cartridges to get around Sega's hardware lockout.)

In no case does copyright protection for an original work of authorship
extend to any idea, procedure, process, system, method of operation,
concept, principle, or discovery, regardless of the form in which it is
described, explained, illustrated, or embodied in such work 

Unless activation of these ROM functions is covered by a patent, it
looks like it would fall clear on the side of a "process" or "method of
operation".  Calling ROM functions is a process required to boot this
machine.  Furthermore, there is only one way to express this process
as encoded computer instructions.  That would seem to suggest that it is
trivial, and thus would not qualify as a sufficiently original
expression, as required by the Copyright Act for a work to be

IANAL, etc.  Permission from Apple would be great, but without
permission, this becomes like the UNIX ABI thing.  Are the various forms

mov ax, my_syscall
int 0x80

scattered throughout my program (included from proprietary system headers)
considered to be copyrightable?  It just wouldn't make any sense.  Nor
would it make any sense for code that does nothing significant besides
perform calls to a proprietary ROM.

Perhaps it would be a good idea to document exactly what this code does
that is not utterly trivial.  Then we can make a decision whether or not
reimplementing it is worth pursuing or if it will even afford us any extra
protection at all, based on the above historical information.

Ryan Underwood, <nemesis@icequake.net>

Attachment: signature.asc
Description: Digital signature

Reply to: