Re: [comp.emacs.xemacs] AUCTeX 11.84 released

Mats Lidell <matsl(a)xemacs.org&gt; writes: Well, having the endproduct available as a reference should certainly not do much harm. Its job is much more general than that of building an XEmacs package. It is used for installing into existing distribution-, site- or user-wide trees of either Emacs or XEmacs and has to cater for typical distributions as well. More likely you mean the XEmacs build structure. You have to arrange the files and write some template files. The GPL states 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. It is the stance of the XEmacs team (or at least of Stephen Turnbull) that the package-specific template files controlling the compilation and installation in the XEmacs package build structure somehow are not covered by the above condition. Thus they purportedly do not need to get distributed with "binary packages". That means that a binary package can't be rebuilt by unpacking it into the XEmacs package build structure, yet the XEmacs team claims that it delivers "full source code". Of course, this deficiency is glaringly obvious with AUCTeX: the binary package generated by the AUCTeX team has _exactly_ the same structure as a binary package from the XEmacs team would have, yet the XEmacs team claims at the same time that a) it is not possible to reasonably use this without a large effort as a source for the XEmacs build structure, b) packages that have _exactly_ this form are to be considered to contain the complete source code and need not be accompanied by anything else on the XEmacs package servers. The actual package-specific build template files are actually not large: putting them into binary packages would hardly be a burden (after all, the whole point of the XEmacs package build structure is to be able to implement such policy changes just in one place), and adding the information about how to arrange back the files into source order is probably also not too complicated when the final arrangement has been generated automatically, but it would require a change to existing practices and policies, and some work, and admitting that something was not quite perfect. This is not a problem specific to AUCTeX, and I don't feel like I am the one who'd want to beat the XEmacs team into changing their package distribution policies into something which could be considered GPL-compliant by actually providing something that can count as source code with good conscience. The AUCTeX case just illustrates that the binary packages, in spite of consistent claims to the contrary, don't contain the complete source and control files needed for compiling. If they did, it would not take years to make a finished binary package fit into the XEmacs build tree. -- David Kastrup _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta