Bug#323182: a bit more about miboot's legal status

2005-09-01 Thread SR, ESC
Le lun 2005-08-22 a 02:15:55 -0400, Jeremie Koenig <[EMAIL PROTECTED]> a dit:
> At the time I looked into the quik side, it seemed the only thing it
> missed was the ability to deduce the floppy device name from its
> configuration in order to be installable on a floppy, but I don't know
> wether this omission was deliberate or not.

no, simply never added. the current maintainer has this on his TODO
list for quik (floppy boot).

> -- 
> Jeremie Koenig <[EMAIL PROTECTED]>

-- 
"Only a brain-damaged operating system would support task switching and not
make the simple next step of supporting multitasking."
-- George McFry


pgpsdUEiuesQv.pgp
Description: PGP signature


Bug#323182: a bit more about miboot's legal status

2005-08-22 Thread SR, ESC
Le lun 2005-08-22 a 10:09:45 -0400, Jeremie Koenig <[EMAIL PROTECTED]> a dit:
> On Mon, Aug 22, 2005 at 11:50:37AM +0200, Sven Luther wrote:
> 
> The header file in question, Optimization.h (attached, piped through
> tr '\r' '\n') is a rather trivial file, and I doubt there's any problem
> here. In the worst case it would take a minor change and a rebuild to
> get a 100% clean miBoot binary.
> 

wow, neat, certainly bodes well. i'll take a look too. thanks for the
time to look this through.

-- 
Cold pizza and cold coffee, second best thing to cold pizza and warm beer.
-- me


pgpOCHpSbMmoi.pgp
Description: PGP signature


Bug#323182: a bit more about miboot's legal status

2005-08-22 Thread Sven Luther
On Mon, Aug 22, 2005 at 04:08:54PM +0200, Jeremie Koenig wrote:
> On Mon, Aug 22, 2005 at 11:50:37AM +0200, Sven Luther wrote:
> > > I understand this, but was speaking about a different problem. IIRC
> > > miBoot itself uses a non-free library from Apple, in addition to being
> > > loaded by a non-free bootloader.
> > 
> > Ah, which one ? I thought it only used codewarrior 4 to build, and then used
> > probably the runtime, not sure. What is this library you are speaking about 
> > ?
> 
> I had a quick look, and found this text is at the top of the copy of the
> GPL in the Sources directory of BootX 1.2.2:
> 
> | NOTE: The included pieces called "MoreFiles", "MoreCFMPatches" and
> | other "More" in the "lib" directory are pieces of Apple's
> | MoreFiles and MoreIsBetter packages.  Those are freely distributed
> | source packages containing various pre-made tools, by Apple.  The
> | licence on those package is quite "light" and probably conflicts with
> | the GPL. They are _NOT_ covered by BootX GPL, BootX licence covers
> | only the directories others than "lib".
> 
> However, after checking, it seems these libraries are practically not
> used to build miBoot, with the exception of the inclusion of one of
> their headers from common/elf_loader_defs.h (the code in the common/
> subdir is used both by miBoot and BootX.)
> 
> The header file in question, Optimization.h (attached, piped through
> tr '\r' '\n') is a rather trivial file, and I doubt there's any problem
> here. In the worst case it would take a minor change and a rebuild to
> get a 100% clean miBoot binary.

Header files can be reused, provided you drop all comments. (or so i was told
byt the FSF about my libparted amiga partition table support, where i copied
the partition blocks structures.

And the below file will doesn't seem to be containing any trade secret or
otherwise stuff we cannot remove in the long run.

Friendly,

Sven Luther



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#323182: a bit more about miboot's legal status

2005-08-22 Thread Jeremie Koenig
On Mon, Aug 22, 2005 at 11:50:37AM +0200, Sven Luther wrote:
> > I understand this, but was speaking about a different problem. IIRC
> > miBoot itself uses a non-free library from Apple, in addition to being
> > loaded by a non-free bootloader.
> 
> Ah, which one ? I thought it only used codewarrior 4 to build, and then used
> probably the runtime, not sure. What is this library you are speaking about ?

I had a quick look, and found this text is at the top of the copy of the
GPL in the Sources directory of BootX 1.2.2:

| NOTE: The included pieces called "MoreFiles", "MoreCFMPatches" and
| other "More" in the "lib" directory are pieces of Apple's
| MoreFiles and MoreIsBetter packages.  Those are freely distributed
| source packages containing various pre-made tools, by Apple.  The
| licence on those package is quite "light" and probably conflicts with
| the GPL. They are _NOT_ covered by BootX GPL, BootX licence covers
| only the directories others than "lib".

However, after checking, it seems these libraries are practically not
used to build miBoot, with the exception of the inclusion of one of
their headers from common/elf_loader_defs.h (the code in the common/
subdir is used both by miBoot and BootX.)

The header file in question, Optimization.h (attached, piped through
tr '\r' '\n') is a rather trivial file, and I doubt there's any problem
here. In the worst case it would take a minor change and a rebuild to
get a 100% clean miBoot binary.

-- 
Jeremie Koenig <[EMAIL PROTECTED]>
/*
**	Apple Macintosh Developer Technical Support
**
**	DirectoryCopy: #defines that let you make MoreFiles code more efficient.
**
**	by Jim Luther, Apple Developer Technical Support Emeritus
**
**	File:		Optimization.h
**
**	Copyright © 1992-1998 Apple Computer, Inc.
**	All rights reserved.
**
**	You may incorporate this sample code into your applications without
**	restriction, though the sample code has been provided "AS IS" and the
**	responsibility for its operation is 100% yours.  However, what you are
**	not permitted to do is to redistribute the source as "DSC Sample Code"
**	after having made changes. If you're going to re-distribute the source,
**	we require that you make it clear in the source that the code was
**	descended from Apple Sample Code, but that you've made changes.
**
**	The Optimization changes to MoreFiles source and header files, along with
**	this file and OptimizationEnd.h, let you optimize the code produced
**	by MoreFiles in several ways.
**
**	1 -- MoreFiles contains extra code so that many routines can run under
**	Mac OS systems back to System 6. If your program requires a specific
**	version of Mac OS and your program checks for that version before
**	calling MoreFiles routines, then you can remove a lot of compatibility
**	code by defining one of the following to 1:
**
**		__MACOSSEVENFIVEONEORLATER	// assume Mac OS 7.5.1 or later
**		__MACOSSEVENFIVEORLATER		// assume Mac OS 7.5 or later
**		__MACOSSEVENORLATER			// assume Mac OS 7.0 or later
**
**	By default, all compatibility code is ON.
**
**	2 -- You may disable Pascal calling conventions in all MoreFiles routines
**	except for system callbacks that require Pascal calling conventions.
**	This will make C programs both smaller and faster.
**	Just define __WANTPASCALELIMINATION to be 1 to turn this optimization on
**	when building MoreFiles for use from C programs (you'll need to keep
**	Pascal calling conventions when linking MoreFiles routines with Pascal
**	programs).
**
**	3 -- If Metrowerks compiler is used, "#pragma internal on" may help produce
**	better code. However, this option can also cause problems if you're
**	trying to build MoreFiles as a shared library, so it is by default not used.
**	Just define __USEPRAGMAINTERNAL to be 1 to turn this optimization on.
**
**	Original changes supplied by Fabrizio Oddone
**
**	File:	Optimization.h
*/


#ifndef __MACOSSEVENFIVEONEORLATER
	#define __MACOSSEVENFIVEONEORLATER 0
#endif

#ifndef __MACOSSEVENFIVEORLATER
	#define __MACOSSEVENFIVEORLATER __MACOSSEVENFIVEONEORLATER
#endif

#ifndef __MACOSSEVENORLATER
	#if GENERATINGCFM
		#define __MACOSSEVENORLATER 1
	#else
		#define __MACOSSEVENORLATER __MACOSSEVENFIVEORLATER
	#endif
#endif


#ifndef	__WANTPASCALELIMINATION
	#define	__WANTPASCALELIMINATION	0
#endif

#if	__WANTPASCALELIMINATION
	#define pascal	
#endif


#ifndef __USEPRAGMAINTERNAL
	#define	__USEPRAGMAINTERNAL	0
#endif

#if	__USEPRAGMAINTERNAL
	#if defined(__MWERKS__)
		#pragma internal on
	#endif
#endif



Bug#323182: a bit more about miboot's legal status

2005-08-22 Thread Sven Luther
On Mon, Aug 22, 2005 at 08:15:26AM +0200, Jeremie Koenig wrote:
> On Mon, Aug 22, 2005 at 07:55:42AM +0200, Sven Luther wrote:
> > >   - miboot itself uses free-as-in-beer libraries from Apple, which are
> > > shipped together with the source code, so we would have to ask
> > > miboot's author to add an exception for them to its licensing terms,
> > > which he hadn't done yet, though comments in the source distribution
> > > seemed to indicate he's aware of the problem.
> > 
> > This doesn't make miboot free, and is not really an issue, since the boot
> > sector is not linked, i belive, but only agregated into the same media. Same
> > as your bios is not linked to lilo.
> 
> I understand this, but was speaking about a different problem. IIRC
> miBoot itself uses a non-free library from Apple, in addition to being
> loaded by a non-free bootloader.

Ah, which one ? I thought it only used codewarrior 4 to build, and then used
probably the runtime, not sure. What is this library you are speaking about ?

> > mkvmlinuz is different, it uses the already existing zImage.coff format, 
> > which
> > was in use before quik, yaboot or bootx where around.
> 
> My understanding was that oldworld OpenFirmware were broken wrt loading
> such images (I can't remember where I got this impresstion, though.)

Well, it is supposed to work, never tested though.

> Is there a way to load such an image from an old OpenFirmware?

Sure, usually by netbooting it.

> Also, does anyone expect quik to be loadable from a floppy? (ie would
> that work with those old broken OF's?)

There is work rumored to be started on this, and maybe another project
involving the m68k mac loader, if i remember well. I know at least p2mate and
aurelien where investigating this things.

> At the time I looked into the quik side, it seemed the only thing it
> missed was the ability to deduce the floppy device name from its
> configuration in order to be installable on a floppy, but I don't know
> wether this omission was deliberate or not.

I think the problem was the floppy driver, but then, no idea really.

Friendly,

Sven Luther



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#323182: a bit more about miboot's legal status

2005-08-21 Thread Jeremie Koenig
On Mon, Aug 22, 2005 at 07:55:42AM +0200, Sven Luther wrote:
> >   - miboot itself uses free-as-in-beer libraries from Apple, which are
> > shipped together with the source code, so we would have to ask
> > miboot's author to add an exception for them to its licensing terms,
> > which he hadn't done yet, though comments in the source distribution
> > seemed to indicate he's aware of the problem.
> 
> This doesn't make miboot free, and is not really an issue, since the boot
> sector is not linked, i belive, but only agregated into the same media. Same
> as your bios is not linked to lilo.

I understand this, but was speaking about a different problem. IIRC
miBoot itself uses a non-free library from Apple, in addition to being
loaded by a non-free bootloader.

> mkvmlinuz is different, it uses the already existing zImage.coff format, which
> was in use before quik, yaboot or bootx where around.

My understanding was that oldworld OpenFirmware were broken wrt loading
such images (I can't remember where I got this impresstion, though.)

Is there a way to load such an image from an old OpenFirmware?

Also, does anyone expect quik to be loadable from a floppy? (ie would
that work with those old broken OF's?)

At the time I looked into the quik side, it seemed the only thing it
missed was the ability to deduce the floppy device name from its
configuration in order to be installable on a floppy, but I don't know
wether this omission was deliberate or not.

-- 
Jeremie Koenig <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#323182: a bit more about miboot's legal status

2005-08-21 Thread Sven Luther
On Mon, Aug 22, 2005 at 07:20:25AM +0200, Jeremie Koenig wrote:
> Hello all,
> 
> On Mon, Aug 15, 2005 at 09:02:06PM +0200, Sven Luther wrote:
> > The boot.img are the miboot floppies for oldworld pmacs. These are saddly 
> > not
> > useable in sarge, because miboot is non-free (due to the one boot block 
> > which
> > is coming directly from apple and has a couple tens of m68k assembly
> > instructions nobody could be bothered to reverse-enginneer).
> 
> I seem to recall this wasn't the only legal problem:
>   - since miboot requires a non-free compiler to build (and changing
> that would be quite difficult,) it couldn't be part of Debian proper;

That means it would be in contrib though and not in non-free.

>   - miboot itself uses free-as-in-beer libraries from Apple, which are
> shipped together with the source code, so we would have to ask
> miboot's author to add an exception for them to its licensing terms,
> which he hadn't done yet, though comments in the source distribution
> seemed to indicate he's aware of the problem.

This doesn't make miboot free, and is not really an issue, since the boot
sector is not linked, i belive, but only agregated into the same media. Same
as your bios is not linked to lilo.
> (all IIRC, would need some checking)
> 
> I had some hope when mkvmlinuz, which claims to work for oldworld macs,
> was added to Debian, however I never managed to make it work.

mkvmlinuz is different, it uses the already existing zImage.coff format, which
was in use before quik, yaboot or bootx where around.

> To the OP: you may want to try woody on your machine, whose installer
> works reasonably well, and upgrade to sarge from there. You may need to
> tweak the boot floppy to add or remove "video=ofonly" from the kernel
> command-line, if you encounter problems when booting the image.
> 
> I know this email is very late. I haven't been able to put any work into
> the oldworld stuff for a very long time, and resumed my occasional
> reading of debian-boot only recently. I'd like to take this opportunity
> to say I'm feeling a bit sorry for leaving this work unfinished. While
> it's quite clear it won't happen in the next few months, I hope (once
> more) I will eventually be able to change that.
> 
> Sven (or anyone else), in the meantime, I'd be happy to test stuff for
> you (please request via direct e-mail.) And that crappy old machine is
> yours if you want to do some work on it (but I'd say playing nethack
> would be a more constructive way of wasting your time :-)

I already have some oldworld machine (two in fact, altough one is not
connected), but am lacking time.

> And to everyone here: d-i is a piece of fine art, thanks for your work !

:)

Friendly,

Sven Luther



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



Bug#323182: a bit more about miboot's legal status

2005-08-21 Thread Jeremie Koenig
Hello all,

On Mon, Aug 15, 2005 at 09:02:06PM +0200, Sven Luther wrote:
> The boot.img are the miboot floppies for oldworld pmacs. These are saddly not
> useable in sarge, because miboot is non-free (due to the one boot block which
> is coming directly from apple and has a couple tens of m68k assembly
> instructions nobody could be bothered to reverse-enginneer).

I seem to recall this wasn't the only legal problem:
  - since miboot requires a non-free compiler to build (and changing
that would be quite difficult,) it couldn't be part of Debian proper;
  - miboot itself uses free-as-in-beer libraries from Apple, which are
shipped together with the source code, so we would have to ask
miboot's author to add an exception for them to its licensing terms,
which he hadn't done yet, though comments in the source distribution
seemed to indicate he's aware of the problem.
(all IIRC, would need some checking)

I had some hope when mkvmlinuz, which claims to work for oldworld macs,
was added to Debian, however I never managed to make it work.

To the OP: you may want to try woody on your machine, whose installer
works reasonably well, and upgrade to sarge from there. You may need to
tweak the boot floppy to add or remove "video=ofonly" from the kernel
command-line, if you encounter problems when booting the image.

I know this email is very late. I haven't been able to put any work into
the oldworld stuff for a very long time, and resumed my occasional
reading of debian-boot only recently. I'd like to take this opportunity
to say I'm feeling a bit sorry for leaving this work unfinished. While
it's quite clear it won't happen in the next few months, I hope (once
more) I will eventually be able to change that.

Sven (or anyone else), in the meantime, I'd be happy to test stuff for
you (please request via direct e-mail.) And that crappy old machine is
yours if you want to do some work on it (but I'd say playing nethack
would be a more constructive way of wasting your time :-)

And to everyone here: d-i is a piece of fine art, thanks for your work !

-- 
Jeremie Koenig <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]