[Qt-interest] Licensing

[Steven Doerfler]

On 5/29/2010 5:25 PM, Constantin Makshin wrote:
> I'm afraid there are some ambiguities:
> 1) when a program uses shared libraries, is that treated as a single or separate distributions (the program itself and libraries), even if they are provided in one package?
>   

Good point.  The license talks about "mere aggregation", but doesn't
specify where the line is.

But I'm not sure this ambiguity has any practical consequence for those
wishing to distribute Qt-using programs.

> 2) section 5 says to refer section 6 "if the work is a derivative of the Library". But, according to the 2nd paragraph of section 5, are applications linked to shared libraries derivative works of those libraries (they don't contain any portions of libraries except macros and inline functions)?
>   

Many Qt programs may fall under section 6 before they even get to the
linking stage.  Qt has lots of inline functions longer than 9 lines.  So
merely compiling your program, not even linking it, could produce a
derivative work (unless you're careful not to call any of Qt's longer
inline functions).  Nokia's Qt LGPL Exception then comes into play.  But
it explicitly says you have to comply with section 6 of the LGPL.

But let's say your program calls none of Qt's longer inline functions,
uses no big Qt macros, and so your object file alone doesn't fall under
section 6.

Does linking such a program using a Qt shared library produce an
executable that's a derivative of Qt?  Such an executable doesn't
include any additional Qt code, but it does incorporate data from Qt's
shared object library, which is presumably protected just like the rest
of Qt.

Here are two reasons to believe such an executable is a derivative of Qt.

1. Section 5 says it is:

  However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library".

It doesn't say "statically linking a work", but simply "linking".  The
license seems to be claiming that any linking, even dynamic linking,
produces an executable with enough of the library to count as a
derivative work.  (It could be that there isn't enough Nokia-owned
content in the executable for any copyright claim to apply.  In other
words, the license might be overreaching and trying to claim rights it's
not entitled to.  But I'm only going to address the rights license
claims, not whether they have the right to claim them.)

2. Section 6b implies such an executable is a derivative work.  Suppose
the authors of the LGPL believed that dynamically linking a work that
uses an LGPL library with that library doesn't put the resulting
executable under section 6.  Then why would they tell you how, in
section 6, you can legally distribute such an executable by having it
use a copy of the library already on the user's system?  There would be
no need for that section, since a program that dynamically linked to to
an LGPL library wouldn't be restricted at all, under this reading.

But since the LGPL tells you one way your work that dynamically links to
an LGPL library can comply with section 6, its authors must have
believed that section 6 applies to such works.

Suppose, though, that merely dynamically linking to an LGPL library
didn't create a derivative work.  Then a commercial software developer
could link against the (LGPL'd) GNU C library, and distribute the result
without even mentioning the library or telling their users about its
terms, as long as they avoided using static linking.  (Presumably they'd
either be distributing exclusively to systems that already had whatever
shared libraries they used, or else getting their users to acquire the
needed LGPL libraries separately.)  Under that interpretation, the
commercial developer could completely avoid all the requirements of
section 6, even the ones requiring them to acknowledge using GNU work,
or to distribute the LGPL license, since their executable would be a
"work that uses the library" and not subject to any of the rules in the
LGPL.  Do you really think the GNU folks could have meant that?


> 4) when an application is distributed through a web site, does "get from the same place" mean exactly "get from the same web site" or "get from Internet" is OK?
> One of GNU FAQ entries (http://www.gnu.org/licenses/gpl-faq.html#AnonFTPAndSendSources) says "if you'd like, you can alternatively provide instructions for getting the source from another server", so giving instructions how to get Qt source code from Nokia site may not be a [L]GPL violation.
> Another FAQ entry (http://www.gnu.org/licenses/gpl-faq.html#DistributeWithSourceOnInternet) states that providing the code via Internet (particularly FTP) when the program is distributed on physical media is allowed.
>   

But notice that both your links refer very specifically to GPL v3.  This
is because GPL v3 has some additional wording:

If the place to copy the object code is a network server, the
Corresponding Source may be on a different server (operated by you or a
third party) that supports equivalent copying facilities, provided you
maintain clear directions next to the object code saying where to find
the Corresponding Source.

This additional permission doesn't appear in the previous version of the
GPL, nor in the version of the LGPL that Nokia uses.  It just says "the
same place".  I don't think you can reasonably claim that all sites on
the internet are really "the same place".

Steven