On Mon, Dec 31, 2012 at 01:09:30PM -0500, Richard Fontana wrote:
"Source code for a work means the preferred form of the work
for
making modifications to it. For an executable file, complete source
code means all the source code for all modules it contains; but, as a
special exception, it need not include source code for modules which
are standard libraries that accompany the operating system on which
the executable file runs, or for standard header files or definitions
files that accompany that operating system."
In this above paragraph, "definition files" seems to be a
generalization of "header files", which is a very C-specific thing.
If this is what got later defined as "interface definition files",
then a reasonable reading would be that this is just supposed to be a
more generalized term of what in the Unix/C world we would call
"header files".
In that more general sense, RPC IDL files are very similar to header
files, in that they contain the definition of the interface which
allow you to use the services provided by the RPC server, just as the
header file contains the definition of the interface which allow you
to use the OS system library.
RMS tells me that my source code is incomplete because I failed to
provide one or more "interface definition files". I say to RMS that I
provided everything that that paragraph seems to call for. RMS
reluctantly decides not to disagree, perhaps suggesting that I have
exploited an ambiguity in GPLv1, and proceeds to revise the GPL so
that the corresponding paragraph reads.
"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." [Emphasis added.]
The general thrust of the GPL's definition of corresponding source is
that there needs to be enough there so that you can (a) build the
binary/executable from the source files, (b) where the source files
are files that normal human beings would want to modify, and (c)
enough so you can install said binary/executable. (The last one is
the one which is most contentious today, since it bears down on the
anti-Tivoization clause and related questions.)
If we use the theory that "associated interface definition files" are
related to header files", the only thing I can think of is if there
was some lanage or programming environment where there are "interface
definition files" which are necessary to make use of a library or
other programmatic interface (much like header files are needed to
compile programs which use a C library), but which are not necessary
to actually compile said library (or RPC server, etc.).
This is not the case with C --- in general the header file used by
consumers of a library is needed to produce the library itself. In
some cases the publically exported header file is a subset of the
header file used to build the library, but in general, you can either
generate the publically exported header file from the internal header
file, or the header file is separted into a public version and an
internal version which is only used when compiling the library --- but
in that case the library would need to public header file to build
itself, so it would be considered part of the corresponding source.
So the only reason to call out "interface definition files" would be
if there was some case where this was not the case.
Also, am I right that the "interface definition file" that
Ted Ts'o
explained is entirely different from the "interface definition file"
that you (Josh) have in mind? BTW, you (Josh) speak of "system
interface definition files", but weren't those explicitly excluded
from the definition of complete source code in GPLv1? (Otherwise, what
you mean by a "system interface definition file" must be different
from what GPLv1 means by "standard header files or definitions files
that accompany that operating system" in the GPLv1 version of the
system library exception.)
Assuming that the above theory I've outlined is correct, then both
header files and RPC IDL files are both instantiations of the more
general concept, "interface definition file". In both of these cases,
though, since they are needed to compile the executable, they would
fall under the definition of corresponding source even in the GPLv1
definition. So they do not explain why the GPLv2 has an explicit call
out to include "interface definition files" specifically.
Hope this sheds more light than confusion,
- Ted