|
From: Richard A. B. <ric...@ho...> - 2002-08-23 09:36:18
|
----- Original Message ----- From: "Andy Green" <an...@wa...> To: <eth...@li...> Cc: <Xbo...@li...> Sent: Wednesday, August 21, 2002 4:47 PM Subject: [Xbox-linux] Question on supporting nVidia .o driver > The main question is, what's the prevailing opinion about using a .o in > this way GPL-wise. It has been suggested that we'll be okay if we do > not distribute the .o but make our GPL project consist of everything > but. (Because we are running on the xbox only, portability is not a > concern). 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. The law makes no distinction between static linking and dynamic linking. So, when you compile an executable and you link it dynamically to a GPLed library, the executable must be distributed as free software with the library. This also means that you can not link dynamically both to a GPLed library and a proprietary library because the licenses of the two libraries conflict." If that is the case, it doesn't appear to matter if you distribute the library or not, the fact that you intend to link with it makes it a derived work. The suggested work around is to use something else, or get the maker of the library to release it under the GPL - great work arounds, why didn't we think of these! :-). "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. Has anyone actually spoken to a Legal expert on this? Or someone from GNU/FSF? They may be able to clear it up once and for all. 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? 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. Richard. |
