Michael Poole wrote: > Walter Landry writes: >>What if there was a package wget++ that communicated with openssl >>entirely through system() or exec() calls? It would construct >>appropriate input and parse openssl's output. Would that constitute >>linking? It ends up using all of the same code as the directly linked >>version. >> >>If it is not linking, why couldn't you do this with all GPL'd >>libraries? You could write a GPL'd wrapper around a library, and just >>use the wrapper with exec(). >> >>In essence, why does using exec() suddenly break the chain, while a >>linker or classloader does not? > > exec() does not break the chain of derivation. My understanding is > that the Objective C front-end for gcc was released as free software > because the (corporate) author's attempted exec()-based abstraction > around the gcc back-end did not break the chain. Rather than fight it > out in court, that company decided to make it free. While it is true that exec() does not automatically break the chain of derivation (it may or may not depending on the circumstances, though it most often does), it was not the issue in the particular case of gobjc. NeXT intended to distribute .o files for linkage with GCC by end-users. >>From the law's perspective, the intent and result (in terms of > copyrightable expression) are far more important than the mechanism > through which software works. That is why rules about static linking > versus dynamic linking versus I/O streams versus other IPC can only be > rules of thumb. They can hint at the type of relationship, but do not > determine it. Agreed entirely. - Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature