Re: On interpreting licences (was: KDE not in Debian?)
On Tue, 1 Feb 2000 I wrote:
> So in this case distribution of non-GPL-ed source code must still be subject
> to [GPL section 2], if that source is part of the "complete sources" of the
> binary distributed, and the exception for OS components does not apply.
>
> I suppose that a program dynamically linked against a library does not
> contain any of the code of that library, so does the source for that library
> count as part of the complete source for the dynamically linked
> "executable"? GPL says
>
> 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.
>
> Possibly the letter allows exclusion of the sources for the library in this
> case, because the binary does not contain any modules of the library, and
> even the interface definition files for the library may be considered to not
> be associated to the modules that are included in the binary (even if they
> are used by those modules). However, such reading does seem to violate the
> spirit of the GPL, since (1) the term "complete sources" itself does not
> suggest this reading, (2) it rests on a somewhat technical distinction
> between dynamically linked and statically linked executables, (3) what would
> the purpose of requiring inclusion of scripts be, other than to allow using
> them to recreate a modified binary after changing the sources, requiring at
> least access to the interface definition files of the library, and (4) such
> reading makes the exception for OS components mostly unnecessary (do
> executables usually contain modules that also classify as "anything that is
> normally distributed... with the major components... of the operating system
> on which the executable runs"?). As for reason (2), how would the intent of
> the GPL, which is clearly to ensure that anybody using GPL-derived programs
> is able and free to improve the sources and redistribute, be served by
> allowing dynamically linked binaries where it forbids statically linked
> ones?
>
> Yet, why has nobody recently put forward this way of resolving the KDE/Qt
> issue? I've seen drastic bending of the meaning of much more unambiguous
> parts of the GPL. Maybe this was discussed and resolved long ago, or maybe
> I'm just too blind too see the obvious? Anybody please explain.
To which David Johnson replied:
> I have put this opinion forth (that Qt is distinct from the application and
> not a module) in the past, but [...] I have become "gun shy" and have
> refrained from stating what I see as obvious.
Then Raul Miller responded: [...]
> So copyright law grants some fairly broad protections. Without broad
> protections, you could never prove copyright violation. [Which, some people
> might argue, is a good reason for getting rid of copyright laws -- but
> that's a whole different discussion.]
>
> And, at least in the U.S., you don't actually have to make the illegal
> copies to be guilty of copyright violation: you just have to make it easy
> for the illegal copies to be made.
>
> So treating "unlinked" code as independent works doesn't cut it, not when
> the usual practice is to use these "independent pieces" together on the
> target machine.
I would like to note that the discussion has by now made a strange turn. I was
discussing the interpretation of "complete sources" in GPL section 3.
Everybody agrees that one has to meet the conditions of GPL in order to
distribute an executable built from GPL-ed sources; the ordinaray protections
of copyright law will guarantee that. So section 3 could require whatever it
likes, and define "complete sources" in any way it finds suitable. My only
observation was that the language it uses taken literally does not seem to
include sources for the library in the case of distribution of dynamically
linked executables. Now I know this is not what the FSF wants it to mean; I
already noted the interpretation seems to run contrary to the spirit of the
GPL, and on http://www.fsf.org/philosophy/license-list.html, the FSF says:
Since the QPL is incompatible with the GNU GPL, you cannot take a
GPL-covered program and Qt and link them together, no matter how.
That is an overstatement since the GPL itself admits: "Activities other than
copying, distribution and modification are not covered by this License; they
are outside its scope." But again that is besides the current point. That
point is: why does GPL section 3 not say something like the following?
For object code or other kinds of executable work, complete source code
means the full source text for all executable code that will be executed as
a direct consequence of executing the work, and whose presence on the same
computer as the work is a prerequisite for proper execution of the work; in
addition it includes any associated interface definition files, plus the
scripts used to control compilation and installation of the executable.
That would fairly unambiguously include and libraries dynamically linked to.
It would also include OS kernel routines that implement system calls made by
the executable, providing a good reason to subsequently exclude components of
the OS from the obligations otherwise imposed with respect to the source code,
as the GPL does. As the GPL actually reads, I cannot see how such components
are included in the definition of complete source code in the first place.
A possible objection of the above formulation would be that it is too broad to
be practical. If for instance I were to write some Mathematica code
(Mathematica is an interpreted language whose only existent interpreter is
proprietary software of Wolfram Inc.) and wish to distribute it under GPL,
then that code might be considered executable in source form (the language
being interpreted) so that GPL section 3 would apply, requiring distribution
of the "complete source", which under the above definition would include the
sources for the Mathematica program (which moreover is not an OS component),
effectively making distribution impossible. That would be quite a stretch
however, and easily mended by making clear that section 3 does not apply when
executable code coincides with the source code. So I am at a loss why GPL does
not employ such a broader definition, if that meaning is what the FSF intends.
Marc van Leeuwen
Universite de Poitiers
http://wwwmathlabo.univ-poitiers.fr/~maavl/
Reply to: