On Thu, 13 Jan 2005 09:08:59 -0500, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote: > 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.
I agree that competent build integration is hard; I've done it many times, and it's real work. But "work" isn't the criterion for copyright; it's "inclusion of copyright material". No matter how complex the ld incantation required, the action performed by that incantation is mechanical and un-creative. The ld incantation might be a copyrightable fragment, but X+Y isn't a copyrightable collection. I think (IANAL). And in any case it isn't a derivative work. > 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. Do you have precedent on this? Check out the Lexmark decision for an example of how a court will slice things along a "functional vs. expressive" plane to find that one piece of software that uses another doesn't infringe its copyright unless a human has selected expressive portions for copying into the flow of the new work's source code. Lifting an implementation from one code base and placing it in another is copyright infringement (Cadence v. Avant!, etc.). Calling the implementation via a public API isn't. And as for the "header fragments" bit, I would expect a court to rule that they're entirely functional and, even if they weren't, there's an implied license to use them for their functional purpose. Cheers, - Michael
