Dynamic linking, was: Re: Dispelling BSD License Misconceptions

Chuck Swiger chuck at codefab.com
Mon Jan 29 19:53:48 UTC 2007


On Jan 28, 2007, at 12:21 PM, Ben Tilly wrote:
>> With the appropriate parts of the compiler toolchain (ar, nm,
>> objdump, etc), you can actually examine the contents, symbol headers,
>> and timestamps of libraries, object files, and executables.
>
> I think that intent enters into it.  Sure, it frequently is possible
> to divide it back up into pieces, but nobody intends for such a
> division to ever happen.  Therefore the file is not just a "mere
> aggregation".

A reasonable position-- I would generally agree that statically  
linking resources into an executable implies an intent to create a  
compilation or derivative work that goes beyond "mere aggregation".

On the other hand, it is possible to include (link in) a library from  
which no symbols are being referenced (via GNU ld's --whole-archive  
option, for example)...and this can be done at any time, including  
after an executable has been created.

Let's suppose someone who holds the perspective that "any linking  
against a GPL'ed library means that the associated binary must be  
distributed under the terms of the GPL, even if the executable does  
not depend on that GPL'ed library"-- such a person could relink any  
given proprietary binary against GNU readline and then demand that  
the vendor of the proprietary program release their sources, even  
though the binary does not know about, use, or depend on GNU readline  
in any fashion when originally distributed.

[ I don't think the vendor of the proprietary binary would have any  
obligation or responsibility for actions which lie completely outside  
of their control; it would be the responsibility of the person doing  
this linking to either obtain the sources or to refrain from  
redistributing their modified version if the result was not in  
compliance with the GPL's requirements. ]

> And sometimes such a division is not possible.  The
> difference between those two cases takes more skill to determine than
> the vast majority of computer users possess.

Oh, certainly.  But courts may well pay attention to facts which may  
not be significant or discernible to a layman but are evident to  
expert examination.

>> > Another case of interest is the web.  Suppose that I write GPLed
>> > software that produces a website.  There is no question that the  
>> web
>> > pages that I display include lots of stuff that is part of my
>> > codebase.  I think they should therefore be GPLed.  And every  
>> time you
>> > fetch a page, a derivative work has been distributed.  Does every
>> > page, therefore, need to include a copy of the GPL?
>>
>> We'd discussed this back in the thread "GPL for JS libraries (Was:
>> Re: Redefining GPL?)"

[ ...Msg-Id's snipped as you've found the right message... ]

> In any case you raised a number of interesting points in that email.
> A key one is that in your opinion distributing a hyperlink to the GPL
> along with a GPLed file should count as distribution of the GPL
> license.  While this seems like a reasonable practice, it doesn't
> match my understanding of the GPL that one can merely offer the
> license text in place of giving the license text to the recipient.
> (The license says that one must give the recipient the license.)

Yes, it does.  If you've redistributed GPL'ed software such as  
JavaScript code, CSS, etc, then you need to provide the text of the  
GNU General Public License to the recipients.

To me, that means you need to make the text downloadable as a  
normal .txt or HTML file from the site which offers the GPL'ed  
software, not that you need the whole text of the GPL on every single  
page of the site, or included with every single resource files which  
comprises the site.  After all, you can GPL image resources like PNG/ 
GIF/JPG/etc files, but the image file formats do not lend themselves  
to including the GPL text with these image files...

-- 
-Chuck




More information about the License-discuss mailing list