On Wed, 4 Jan 2006, Mike Meyer wrote: > Terry Hancock <[EMAIL PROTECTED]> writes: > >> It is interesting to note that the FSF holds the position that the >> language that "gives you this right" *doesn't* -- it just clarifies the >> fact that you already hold that right, because it is provided by "fair >> use". Their position is that it is not possible to restrict the *use* >> of software you have legally acquired, because copyright only controls >> copying. > > I believe there is precedent that contradicts the FSF's > position. There are two arguments against it: > > 1) Executing software involves several copy operations. Each of those > potentially violate the copyright, and hence the copyright holder > can restrict execution of a program. > > 2) Executing a program is analogous to a performance of the software. > Copyright includes limits on performances, so the copyright holder > can place limits on the execution of the software. > > Personally, I agree with the FSF - if own a copy of a program, executing > it should be fair use.
I'm with you - i don't accept either of those legal arguments. The copying that copyright talks about is the making of copies which can be distributed - copies which are the equivalent of the original. It doesn't mean the incidental, transient copies made during use - otherwise, it would be illegal to read a book, since a copy of the text is transiently made in your visual cortex, or to listen to a record, since a copy of the music is transiently made in the pattern of sound waves in the air. The performance that the law talks about is not like execution, but is communication, and so a form of copying - by performing a play, you're essentially giving a copy of the text to the audience. Executing a program doesn't communicate it to any third parties. Of course, in practice, it matters rather little whether i accept either of those, since i'm not a judge trying the relevant test case! > While I'm here, I'll point out the the "address space" argument is > specious. What if I bundle a standalone GPL'ed application with my own > application, and distribute binaries for a machine that has a shared > address space? By that criteria, I'd have to GPL my code for the > distribution for the shared address space machine, but not for a Unix > system. I'm not buying that. I also agree that the address space thing is bunk. What if i write a CORBA/RPC/COM/etc wrapper round some GPL'd library, release that under the GPL, then write my non-GPL'd program to access the wrapped library via a socket? Or if i write a wrapper application that takes a function name and some parameters on the command line, calls that function, and writes the result to stdout, then access it via popen? I get the use of the library, without sharing its address space! On the flip side, we could argue that an application which uses a dynamic library *is* a derivative work, since we need a header file from the library to compile it, and that header file is covered by the GPL. What happpens when you compile with a non-GPL but compatible header (say, one you've clean-roomed) but link to a GPL library at runtime, though? tom -- I am the best at what i do. -- http://mail.python.org/mailman/listinfo/python-list
