Structure of package /man
dak at gnu.org
Wed Jun 8 08:32:39 EDT 2005
"Stephen J. Turnbull" <stephen at xemacs.org> writes:
>>>>>> "David" == David Kastrup <dak at gnu.org> writes:
> David> Quoting from the GPL:
> David> The source code for a work means the preferred form of
> David> the work for making modifications to it.
> The intent of that passage is clearly to prevent distribution of
> obfuscated sources, not to create special privileges for the
> upstream vendor to specify "preferred form" to the detriment of
> downstream developers.
> As far as I can tell, your interpretation of that phrase prohibits
> partial redistribution of the sources,
If the non-distributed parts of the source are required for
regenerating the distributed software after modifications, yes. That
is the whole point of the source requirement in the first place.
> and prohibits any reorganization that would make the upstream
> Makefile fail to produce working executables. Both are restrictions
> incompatible with software freedom.
You are free to throw out any material that is not needed for making
modifications to the package as you distribute it. You don't need to
include the upstream Makefile if it is not used in the process of
creating your package. But you have to include your own Makefile or
description or whatever else if the package can't be regenerated
That is the whole point of the GPL.
> David> There are no scripts or other files (like XEmacs.rules or
> David> similar) whatsoever included that would be needed for
> David> rebuilding the package in any manner.
> The GPL doesn't require that users be able to rebuild the _package_.
> It requires that they be able to rebuild the _program_.
Well, and how do you support that? By saying "write your own bloody
scripts and rule files"?
> David> Fine, but some things are definitely necessary for
> David> creating an XEmacs package, and you include nothing
> David> whatsoever. It is not possible to drop the package in
> David> its current form into an XEmacs package source tree and
> David> recompile it.
> The GPL doesn't require that derivatives support that, not even for
> their own distribution format. It requires that if you distribute a
> working copy of the program, and the recipient wishes to change its
> behavior, she must have access to the sources ("preferred form for
> modification") of the objects that produce that behavior, as well as
> any interfaces, scripts, etc, required to produce objects that
> generate the _behavior_.
And I don't see that you include any of that. It is likely that
including XEmacs.rules in a package would solve that aspect. But as
long as you only include man/*.texi without including the recipes you
use for recreating the info files from them, it is an empty gesture
that does not in my point of view meet the requirements for "full
source code" that the GPL demands.
I quote again:
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.
I don't see how you can consider a package to contain the complete
source code when the package-specific "associated interface definition
files, plus the scripts used to control compilation and installation
of the executable" are not present. While the AUCTeX-independent
parts of the build environment are clearly out of the scope of the
package source code, the XEmacs.rules (presumably) is obviously a
package specific part of the source code as defined by the GPL.
Since you can't readily recompile man/*.texi into their info files
without this specific information, I can't see how you can consider it
not part of the source. That you need a particular build environment
for making use of those descriptions is not a problem. But the
package-specific parts of the scripts (which have to be changed along
with every release of the software) are certainly by all means, letter
and spirit, part of the source as defined by the GPL.
It may be that the absence of this file (as presumably it is just one
file) was just an accidental oversight, easily fixed, but you are so
reflexive about saving face that it is not possible to distinguish the
> Your interpretation evidently goes far beyond that, well into
> non-free territory.
Well, the freedom to modify is a fundamental software freedom. You
are obviously of the opinion that it is a non-freedom if you are not
permitted to distribute sterile compiled versions that can't be
recompiled by anybody else because the required associated description
files are missing.
Well yes: exactly that is what the GPL does _not_ give you freedom to
do, and that is pretty much its sole point and the reason it has to
define "source code" very carefully.
David Kastrup, Kriemhildstr. 15, 44793 Bochum
More information about the XEmacs-Beta