Re: GPL-licensed packages with depend-chain to OpenSSL
Steve Langasek <vorlon@debian.org> writes:
> If your understanding of the license exception requirements were
> correct, it would be a very easy loophole for people to exploit, using
> GPL-compatible library layers to "sanitize" the licenses of library
> dependencies.
>
> But in fact, the GPL's definition of source code is:
>
> The source code for a work means the preferred form of the work for
> making modifications to it. For an executable work, complete source
> code means all the source code for all modules it contains, plus any
> associated interface definition files, plus the scripts used to
> control compilation and installation of the executable. However, as a
> special exception, the source code distributed need not include
> anything that is normally distributed (in either source or binary
> form) with the major components (compiler, kernel, and so on) of the
> operating system on which the executable runs, unless that component
> itself accompanies the executable.
>
> For GPL applications linked against curl, "all modules it contains"
> includes both libcurl and libssl.
When using dynamic linking that is not necessarily the case. Most
dynamic linkers use lazy loading of libraries, such that the openssl
libraries would not actually be mapped in to the process address space
until one of its functions is called. If, as per assumption, the
application does not use any ssl related features of curl, the openssl
libraries would never be touched, except for a possible scan of its
symbol table. The openssl libraries could be replaced by another
library containing dummy entries for all the required symbols and the
curl using application would still function correctly. How the
presence or absence of a particular library at runtime could possibly
change the derivedness of a some program from said library is beyond
my comprehension.
--
Måns Rullgård
mru@mru.ath.cx
Reply to: