On Wednesday, August 19, 2015 10:53:39 PM Rich Freeman wrote: > On Wed, Aug 19, 2015 at 10:37 PM, Fernando Rodriguez > <frodriguez.develo...@outlook.com> wrote: > > > > Try a different exercise. Go buy a Quran. Now use it as a cryptographic key to > > encrypt an email. Is the email now a derived work? That's no a perfect analogy > > but it's more like what happens when you dynamic link a library. > > But that isn't what happens with dynamic linking. > > In the paragraph below, insert word 1 after the 3rd word in place of > the xx, and insert word 2 after the 9th word in place of the xx. > > This is an xx of dynamic linking. I have a xx where various elements > are replaced with others. > > Somebody else will tell you next week what word 1 and word 2 are. He > owns the copyright on those words, but he will refer to them as word 1 > and word 2. > > Dynamic linking doesn't render code unreadable the way encryption > does. It just means that not all of the code is actually present. > All the original code written by the author of the object file is > actually present, and in completely executable form except where it > accesses memory that isn't a part of the object file. You can > actually execute parts of an object file as a result.
The point I was trying to make is that just like the email would be useless unless I have a Quran so will a program be useless without the library it depends on. I did say it wasn't a very good analogy. > > > It's not the symbols that are copyrighted, it's the code that those symbols > > load into your programs address space. > > The symbols don't load anything. The linker loads the external code > into RAM, and inserts its address into your own code where it > references the exported symbols. In the example above my instructions > don't actually do anything. They just tell you what to do when you > find out what words 1 and 2 are. The linker/loader doesn't load anything either, it just tells the kernel to load it...the kernel doesn't load it either, it tells the cpu to do it and so on. The point is that the symbols are instructions too, they're just not executed by the processor but interpreted by the loader. It all starts with the developer's decision to link against the library in order to take advantage of _existing works_. > > Here's a better example, see the Mona Lisa example in wikipedia[1]. Now, > > suppose I write a small program that downloads a Mona Lisa picture of the > > internet and displays it with a mustache overlaid? Is my program now a > > derivative work of the Mona Lisa? That's *exactly* what happens when you > > dynamic link to a library. > > That program would not be a derivative work of the Mona Lisa. The > picture it displays would be a derivative work of the Mona Lisa. The > analogy isn't perfect, but it is decent. > > Executing the program might or might not be a violation of copyright, > but distributing the program itself would not be. At most you could > argue it is inducing copyright violation, which is a horrible legal > argument, but admittedly one that US courts have seemed to embrace. > Go Mercia! Yet just about everyone would agree that if I fireup gimp and edit the picture and save it as a jpg would be a derived work. But for an end user there's no difference. The difference is only in the implementation. Both files contain binary code, one is interpreted by the cpu the other by an image viewer. One is statically linked to the original work the other dynamically. If this does goes to court a judge will have to determine if the letter of the law still serves it's intended purpose if it doesn't (and it obviously doesn't) then it's obsolete and the loophole needs to be patched. -- Fernando Rodriguez
