Re: Question About GNU General Public License

[Alexander Terekhov]

David Kastrup wrote:
[...]
> Just for the record, I mentioned this once already: dynamic linking
> enters a lot of binary addresses into a program, making it an image
> in memory that is completely dependent and "linked" with the library
> in question.  Calling dlopen from inside of a module to load a
> library and call its functions explicitly instead of by linking
> doesn't.

So what? Linking (both static and dynamic) is the same as framing 
and mounting.

http://www.law.cornell.edu/copyright/cases/125_F3d_580.htm

<quote>

If the framing process does not create a derivative work, then 
mounting [...] does not create a derivative work. What is more, 
the ninth circuit erred in assuming that normal means of 
mounting and displaying art are easily reversible. A painting 
is placed in a wooden "stretcher" as part of the framing 
process; this leads to some punctures (commonly tacks or 
staples), may entail trimming the edges of the canvas, and may 
affect the surface of the painting as well. Works by Jackson 
Pollock are notoriously hard to mount without damage, given the 
thickness of their paint. As a prelude to framing, photographs, 
prints, and posters may be mounted on stiff boards using wax 
sheets, but sometimes glue or another more durable substance is 
employed to create the bond.

</quote>

> 
> While this is a fine line, it is obviously thick enough to have caused
> RMS to refuse letting a module loader (which would have used dlopen)
> be put into Emacs because he thinks that in that case
> Emacs/proprietary combinations could become more legally viable than
> desirable.

Yeah. I know quite well that RMS is amusingly insane.

http://groups.google.com/groups?selm=40320716.E5FF569C%40web.de
http://groups.google.com/groups?selm=403344E5.E7872D34%40web.de

He and his "pro bono"-me counsel can't even grasp the difference 
between "derivative works" and "compilations" (collective works 
including).

> 
> Of course, on a typical system Emacs is dynamically linked with a
> number of libraries already, but not via the "dlopen by program"
> method.

regards,
alexander.