On Sat, Nov 27, 2004 at 05:20:46PM +0100, Wesley W. Terpstra wrote: > What is a binary image? I think it makes most sense that it includes the > entire shipped product---both my executable and it's dependent: his. > > Whether the library and binary form a single file seems irrelevant. > Otherwise, .dll's or .so's would also avoid this 'binary image' issue. > What is the difference between 'dlopen' and 'system'? You're almost right. The technical method by which derivation or aggregation is accomplished is irrelevant. Varying the method will not change the state from derivation to aggregation, or vice versa: ld is not automatically derivation, nor is tar automatically aggregation. The state of a work being derived is intrinsic to the work itself. It doesn't become derived because you add a useless unnecessary -l argument to the compiler, and it doesn't stop being derived because you have a trained monkey copying the data around by hand between processes. When we talk about 'linking', we're really referencing the fact that it's normally used in a certain way. It's not magic, it just happens that linking to a library will normally occur in the cases where you've got a derived work, because anything else is insane from a technical perspective. Getting overly attached to the notion of 'linking' leads to navel-gazing exercises and not much else. The exact determination of what is and is not derived is notoriously fuzzy and ultimately a matter for the courts (yeah, copyright sucks). I find a good rule of thumb to be: "If your application will only work in the presence of some specific other code, it's a derived work, otherwise it's not", which leads neatly to the library API thing. In essence: playing games at the interface boundary cannot exempt you from license requirements. Only a sufficiently expensive lawyer can do that. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- |
Attachment:
signature.asc
Description: Digital signature