> -----Original Message----- > From: Jeroen Janssen [mailto:[EMAIL PROTECTED]]
> Anyway, this does this mean we also can't do the following? : > * fix any problems in the bootmanager or plex86 that prevents > plex86 to > be able to *run* the bootmanager (from a floppy) The changes to the boot manager to make it work with Plex86 would need to be GPL. Personally I would pass those changes back to the boot manager maintainer under GPL. Then the changes to Plex86 to make it work with the boot manager would be LGPL and just reincorporated into Plex86. Two separate works, two separate licenses. > * make an image of a floppy containing the bootmanager (or > tell people > how to make one) You can tell them how to make one and make one for yourself. > * put the floppy image online somewhere? I believe if you distribute a floppy image, you also have to distribute the source for what it contains when the contents are GPL, in this case, the boot manager. I know it works this way for normal executables, I assume it works the same way for boot code. Any lawyers in the house? While you didn't ask, the sticky point where things get cloudy for me is if Plex86 incorporated a local copy of the boot manager code that still remained a separate executable, but might be used to automate the creation of a floppy image. I think this would be allowed, but the boot manager and any changes to it would remain under GPL, while Plex86 remained under GPL. Plex86 still could not make direct use of the GPL'd code. As long as the coupling is not intimate you should be alright. The following from the GPL FAQ might be clearer: The question, "I have written an application that links with many different components, that have different licenses. I am very confused as to what licensing requirements are placed on my program. Can you please tell me what licenses I may use?" leads to another "What is the difference between 'mere aggregation' and 'combining two modules into one program'?" to which part of the answer is: "By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program" -- "The world was a clear place until with lawyers came smog."
