Andrew Suffield <[EMAIL PROTECTED]> writes: > On Thu, Jan 13, 2005 at 04:11:22PM +0100, M?ns Rullg?rd wrote: >> Brian Thomas Sniffen <[EMAIL PROTECTED]> writes: >> >> > Combining X+Y in the way that you have described is anything but >> > mechanical: it is a task which typically takes a skilled programmer a >> > great amount of time and thought. Different programmers might do it >> > in different ways. I'm not referring here to the work done by ld, but >> > to the process of building a new program which has libfoo as a >> > component. >> > >> > Additionally, the program ultimately delivered to the user isn't X >> > with some minor bits of Y. It contains big chunks of Y -- one per >> > function used, at least -- directly copied. Just being in a different >> > memory space isn't enough to change the relationship between the >> > creative parts of the works. The program vim encompasses a copy of >> > libc. >> >> Wrong. A dynamically linked program in ELF format (the most common on >> Linux systems) contains a list of undefined symbols, and a list of >> sonames to search for those symbols. I have a hard time seeing how >> this would make a program derived from the library. If multiple >> independent implementations of the library exist, which would the >> program be derived from? > > You've got the causality backwards here. The program is linked to the > libraries because it is a derivative of the libraries. Not the other > way around. > > Derivation is something that happens when you *write* the program. Not > when you build it.
How many times does it have to be stated that *using* an API does not form a derivative work of *any* implementation of the API? Any other interpretation invariably leads to contradictions. -- Måns Rullgård [EMAIL PROTECTED]