Re: [comp.emacs.xemacs] AUCTeX 11.84 released
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Glynn Clements writes:
> It's not clear that a CVS repository and an FTP server running on the
> same host are even "the same place". And, AFAICT, cvs.xemacs.org and
> ftp.xemacs.org aren't even on the same network.
IANAL, but my feeling is that different protocols are different
places.[1] I would vocally :-) oppose XEmacs relying on the argument
that on the Internet all commonly used media amount to the same place.
That's not in the spirit of trying to conform.
> > BTW Stephen, is there any real reason not to include the two files the
> > crybaby is having a fit over, even if they're pretty much unusable
> > outside of a CVS context from what I understand? They can have some
> > value as an example, I guess.
>
> Given that the XEmacs "binary" packages are so close to being "the
> complete source code" (they may even be so; IANAL, and, AFAIK, neither
> is David), adding those files would mean that access to the CVS
> repository should be a non-issue.
First, those files are definitely insufficient.
Of course, you would know better than me.
AFAICT David is referring to the Makefile and XEmacs.rules (plus
"template files," by which I suppose he means package-info.in). But
XEmacs.rules calls several Lisp files as well as including at least
the Local.rules Makefile. Furthermore, in the case of AUCTeX, the
xemacs-base package is loaded from its source location at build
time. I don't see any point in a source package which doesn't
include those prerequisites, which vary by individual package,
although it's not legally required AFAICS (the xemacs-base source
tarball would be available in the same place).
Basically, the criteria for a source package would be to have
everything that would be missing if one removed AUCTeX completely from
the XEmacs package tree. All the rest is not "source code of AUCTeX",
whether or not it is required for building.
The necessity for availability of the rest could be argued, but since
nobody is asking for a "lex AUCTeX" in particular, there seems little
point in doing so: treatment should be the same for all packages.
My tentative conclusion is that the (comparatively ;-) sane thing to
do is to bundle up the whole source tree and call that the "complete
source", which can be used to build a variety of packages.
As long as one can get the corresponding source version (and not
something later) for any package that one would download in binary
form from the same location as the binary package, yes, such a single
"sumo" source file capable of rebuilding every downloadable binary
package would meet the GPL criteria.
It would probably be quite more inconvenient than individual source
packages, but convenience is not required for compliance.
> Personally, I'd suggest ensuring that one can rely solely
upon
> the argument that the binary packages really do consitute the
> complete source code as defined by the GPL,
That cannot be done if the Makefiles are required by the GPL,
because they are non-functional in the installed context.
(Remember, in the source tree, auctex is a child of xemacs-packages,
whereas in the installed tree it is always a grandchild.) The GPL
doesn't require "documentation of the build process", it requires
"the scripts *used* to build the executable." Adopting the
"historical" interpretation of "used" would be unacceptable to me if
it's merely a way to dodge our responsibility to provide full,
working source in "the same place".
I concur that a package containing all files without a working general
way to arrange those files into the form required for compilation in
the source tree would not cut it. While it could be argued to meet
the letter of the GPL, it does not really match the intent.
I conclude that if the CVS tree Makefiles are part of the complete
source, a separate source package should be constructed.
Or a file should be included that indicates where what should go. The
information is already there how to arrange the files in the source
tree into installed package order. It might be feasible to use this
information for doing the reverse.
Footnotes: [1] I consider this a bug in the GPL. The Internet is an
ether, so as long as the client is easily available, and CVS is, a
CVS server and a FTP server on a different planet are "the same
place".
Unless the firewall of the user does not let ssh connections through.
Or the user does not have ssh installed. Or does not have a CVS
client available. Or does not want to install the proprietary VCS
client that is used for accessing the development data or a number of
other possibilities that offer options for inconvenience or loopholes.
I think the "same location" requirement quite sensible, even though it
probably stil can be loopholed (for example, by providing only a sumo
source package of 500MB size in parallel to small binary packages over
the same bandwidth-limited server dropping connections every 20
minutes).
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta