|
From: Stefan R. <st...@su...> - 2002-08-23 10:32:34
|
* Richard Antony Burton <ric...@ho...> [020823 11:35]: > >From http://www.codelearn.com/cpp/gnutools/node56.html > > "Some people feel that linking to the library dynamically avoids making the > executable derived work of the library. A dynamically linked executable does > not embed a copy of the library. Instead, it contains code for loading the > library from the disk during run-time. However, the executable is still > derived work. This would mean that a) You're not allowed to boot Windows using Lilo b) You're not allowed booting Windows CE using LinuxBIOS. The border is pretty philosophical I guess. But still. As long as the closed source blob would not call symbols from it's "loader", but just gets parsed and executed, this is not a library. The missing memcpy could be linked against the nv module (Thus creating a non-GPLed memcpy function before to avoid license problems) When the loader functionality is generic enough to only interact as a intermediate boot API layer, "using" the nv object as data. Otherwise I would not be allowed to write closed source commercial software when using vim. Or am I completely wrong? > "Note that there is no conflict when a GPLed utility is invoked by a > proprietary program or vice versa via a system () call." Can we > modprobe/insmod from a system call to load the module? That would bring us > to this: "However, a free program that depends on a proprietary program for > its operation can not be included in a free operating system, because the > proprietary program would also have to be distributed with the system." > Hence the not distributing the .o file idea. It would be enough though to show the functionality of the link layer by having one example where an open source driver uses this as well. Whether this example actually works should not even matter as long as it is there and shows the principles. There is no law telling that the software I give out for free is forced to be fully operational > If there is a licence conflict, hasn't it already been broken by the > distribution of nvnet.o with the current version of xbox linux? Probably, yes. SuSE does not deliver this with it's distribution, but rather contains a bunch of scripts downloading it for you. Same applies for some Truetype Fonts (here you even have to acknowledge the licenses to these) > And are we just looking at getting a replacement driver from the etherboot > project? Or are we looking at remote booting the xbox? I'd be happier with a > standalone box, not dependant on being served it's boot image. I hope that > will still be an option. remote booting is the way to go as long as you develop the basic system functionality. As soon as it's possible to install Linux natively you will very likely not need it. Stefan -- The x86 isn't all that complex - it just doesn't make a lot of sense. -- Mike Johnson, Leader of 80x86 Design at AMD Microprocessor Report (1994) |
