On Wed, Mar 23, 2005 at 06:41:58PM +0100, M�ns Rullg�rd wrote: > > Inline functions are certainly being included in the machine code that > > comes out of the compiler, at least if they are called by the rest of > > the compilation unit. > > Irrelevant. If someone chooses to implement a particular interface > using an inline function, that should not impact the derivedness of > code using the interface.
Obviously it doesn't impact whether *source code* using that interface is a derivative work, but it certainly affects whether *binary code* is. The resulting binary from compiling against a header containing inline code can contain substantial pieces of that code--almost verbatim, if it's inline assembly--and that obviously makes the binary connected to the source. (Whether it's a "derived work" or a "combined work" or an "aggregate" work or something else, I'm not sure--it's clearly not a creative transformation--but the result is certainly affected by the license of that code.) > >> extern char **__err_msgs; > >> #define perror(s) (fprintf(stderr,"%d:%s:%s\n",errno,__err_msgs[errno])) > > > >> Is "myfile.c" a derivative work on "errno.h"? The answer is NO. > > > > Of course. But myfile.o might have been if perror() were complex > > enough to leave any room for expressive choice. > > Again, irrelevant. If your implementation puts things in macros, > that's your problem. Uh, what? If my implementation puts things in macros, and you distribute my implementation as part of your binaries as a result, that's *your* problem. I don't even know what you're trying to say here--"you put your copyrighted code in a header and I copied it into my object file--that's your problem, not mine!" doesn't make any sense at all. -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
