On Sun, Mar 28, 2004 at 12:29:42PM -0600, Steve Langasek wrote: > On Sun, Mar 28, 2004 at 07:27:33PM +0200, Sven Luther wrote: > > > > Sven Luther wrote: > > > > Well, the solution would be to force add the miboot stuff to the > > > > debian-installer svn tree, and use it to build. This would make > > > > debian-installer contrib/non-free though, which is why i asked for > > > > debain-legal help. > > > > > > > > Note that one solution for this would be to make an exception for such > > > > bootloader stuff, and have them in the debian-installer SVN, in a > > > > boot-loader directory or something, and use them directly. This will not > > > > break autobuild, and everything would be fine, except when you upload > > > > said stuff to main. > > > > > > That would violate the TOS for alioth. Do not check non-free code into > > > the d-i subversion repository. > > > Well, the main point is, can you really speak about code when you are > > contemplating a 1k boot-sector, which is why i have CCed debian-legal, > > but got no response yet. > > Legally, yes, you probably can.
Well, and what about the bitmap yaboot needs to boot on chrp-rs6k hardware. This is also a fixed bitmap of around 1K of size, without which you cannot use it. Also, did we not have msdos boot sectors in the past, before the advent of the mbr package ? I am not familiar with that as my involvement with x86 hardware is rather recent. > But that's not really the main point, since we've also seen that miBoot > is currently not buildable using a free toolchain, and I get the > impression that no one thinks this can be fixed before sarge's release. Yeah, but the fact that you cannot use a free toolchain means it is a contrib matter, and not a non-free one. > Whether or not the boot block is non-copyrightable (and therefore free), > miBoot will not meet the criteria for main in time for sarge, and we > will need some infrastructure to support contrib/non-free bits for d-i > (which will mean images also not in main). Yeah, the main point is that it will probably never make it, and that given the state of the old hardware concerned, it may probably not make sense to use time to implement said free alternatives. Do we really need to ? Could we not make an exception for boot-loaders, especially those who are GPLed, but need to be built on the native OS of the hardware ? > Joey Hess's suggestion seems like a good one. A loosy one though, and one which probably mean we will loose support for debian-installer on a wide range of older hardware. > > Also, i wonder how free a free replacement could be, if in order to work > > it would have to be exactly the same as the one in question here. Do we > > really need to consider source code for this one ? And in this case, > > what would the source code of a small binary sector look like ? > > > I thought that copyright mat not apply to such cases, where there is > > only one way of making this kind of stuff work, and where the bit > > sequence is accordying short. > > 1k is definitely long enough to be copyrightable in prose and poetry. I > don't know of any counterexamples in programming. Yeah, the main point i am making is that it is probably not easily possible to achieve the same functionality with another bitmap combination. Like said, altough i have not looked personally and have no knowledge of mac os 9, i have been told that all this boot sector does is make a few mac os rom calls, initialize the HFS partition, the mac os System file (or more exactly the later stage miboot maskerading as System file), and launch the stage 2 boot loader, which is free and GPLed. Plus additionally some checksum info and other padding. There is probably not many ways to implement this, so a free alternative would probably not be much more than an illusion. Also, Rick mentioned that apple distributes freely the OS 7 floppies, which probably contain this same info. Probably free as in beer though. > The FSF requires copyright assignment for any contributions of *source* > greater than 7 lines. 7 lines of source code, compared to 1K of boot sector, which may contain less than 7 actual instructions ? Friendly, Sven Luther
