"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Let me try to briefly set the record straight as to what I believe
the technical facts relevant to determining whether XEmacs packages
are conformant to the GPL requirement to distribute source.
From the legal point of view, we distribute *two* derivative versions
of each package. The first derivative version is distributed only
as source (and therefore has no problem with that requirement), as
part of the collective work known as the "XEmacs package CVS
repository." This is the preferred version for development
Cf. GPL clause 3:
The source code for a work means the preferred form of the work
for making modifications to it.
You even use the same wording.
The second version of each package, which is a separate derivative
Work (see footnote 1), is a *binary-with-source distribution* that has
the following properties:
1. The files that need processing (ie, Lisp) are in the right
In the right place for _execution_. Not for development/modification.
2. The objects produced by processing them (ie, the .elcs)
automatically are installed in the right place (ie, next to
the corresponding .el). The required processor is part of
the core XEmacs binary and its associated Lisp.
You use "automatically" here for "if one manually calls the byte
compiler on the directory" and for "in the course of normal build
process, part of the normal development cycle, the preferred form for
3. The auto-autoloads.el file is produced by a processor which
part of the core XEmacs binary and its associated Lisp.
Again you gloss over the distinction between "there is a way to
manually do something" and "the preferred way for modification".
4. Other data files are in the right place; they can be edited
the user's taste in place.
In the right form for the binary end-product, not in the preferred
form for modification.
5. We provide prebuilt auto-autoloads and .elcs for
There is no need for a Makefile, because everything that needs to be
edited or rebuilt is already in place.
But it isn't. If it were, then you'd have no problem taking the
binary AUCTeX package we produce and dropping it into your package
repository, the preferred form for modification.
Installing other than to an installed XEmacs package tree is not
required; our *binary-with-source distribution* is restricted by
design to use in that context.
But the preferred form for modification/development is not by
hand-editing and handcompiling. They are in the XEmacs CVS package
repository. This form is so much the preferred form for modification
that you don't even _allow_ anything else into your package servers
and the repository.
Installing, other than by unpacking the tarball, is not required;
our *binary-with-source distribution* is designed to be unpacked in
the installation destination. Creating the tarball, whether
upstream-style or an XEmacs *-pkg.tar.gz, is not required, because
the tarball is the *medium*, not the *message*. If you want any of
those features (and they are all desirable, of course!), you would
be well-advised to use either the XEmacs CVS repository version or
the upstream AUCTeX version.
Because that is the preferred form for modification, the corresponding
source code, including, I quote from the GPL:
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.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
In other words, you have to look at what we actually *do* distribute
as a "binary-with-source" distribution to see whether it really is
necessary to distribute Makefiles etc for it. The GPL doesn't say
"you must provide all the infrastructure needed to set up as a
Certainly not. And we are not talking about the _infrastructure_
here. We are talking about the _package-specific_ template and
Makefiles here, those that are _not_ part of the XEmacs
infrastructure, but control the compilation and installation of the
particular resulting package.
The GPL doesn't say "you must provide a source package in
format that you received it".
Certainly. It says that you have to provide the complete, machine
readable source code in the form preferred for modification. And if
you don't provide it by default, the least is to do is to provide
equivalent access from the same place. And a central CVS server is
not the same place or equivalent access as scattered ftp mirrors.
The GPL doesn't say "you must provide sources that can be
build all the configurations imaginable." It says "you must provide
the sources for the executable you distribute, as well as the
scripts used to build it." We do. It happens that AFAICS no
scripts are needed to build the executable.
Interface definition files and Makefile templates are needed. That is
the reason why we still don't have an uptodate AUCTeX package in the
XEmacs package repository. Because your form of modification, the one
you prefer so much that you don't allow any other one into
distribution, requires those files.
Furthermore, in practice *no scripts are used* to build from the
"binary with source" distribution. I do edit and rebuild packages
in the installed tree frequently, and have never felt a need for a
script (with the single exception of rather old versions of VM---for
which we *do* provide the Makefile!)
Your very own FAQ states:
Q6. What if I maintain a package and want to distribute XEmacs binary
A6. Just drop your sources into an appropriate subdirectory of the
CVS tree, add an XEmacs-style makefile and package-info.in
(documentation and examples in the Lispref), and type "make
This "makefile" and "package-info.in" are _clearly_ scripts and/or
interface files controlling the compilation of the package, and you
don't distribute them along with the package.
It is true that a script is used in building the distribution, and
therefore the specific instance of the executable in the tarball.
The literal interpretation of "scripts used to build it" as meaning
"in the physical history of the distributed executable" is
plausible, of course.
Straw man. The history is irrelevant. The question is what is the
preferred form for modification. And the preferred form for
modification, to a degree that you don't permit anything else into
your package tree, is the XEmacs CVS form with "makefile" and
But I think the interpretation of "used" as hypothetical
"scripts used to build it [in case you had modified it]") is more in
keeping with the intent and spirit of the rest of the GPL, which
tries to give maximum freedom for creating derivative works attuned
to user needs, without sacrificing those users' freedoms to "change
the software or use pieces of it in new free programs".
And what user freedoms do you preserve by not distributing "makefile"
XEmacs-Beta mailing list