Mats Lidell <matsl(a)xemacs.org> writes:
>>>>> David Kastrup <dak(a)gnu.org> writes:
David> That does not mean that XEmacs central is not free to throw
David> away Makefile and autoconf from upstream and replace them by
David> whatever is more convenient for them, but it does mean that
David> whatever they replace it with for the sake of building this
David> particular package has to accompany the package or be
David> downloadable from the same location.
The GPL issue must then be that the files needed to build the XEmacs
Package binaries in the XEmacs Package Tree isn't included today with
the binaries.
If you can't download the build structure today, except through CVS,
that is a problem then. For each SUMO release there should be a source
tar ball as well I think.
Well, one of the basic meters for GPL adherence with regard to the
source and the spirit is the question "Could I take everything that is
called `corresponding source code' and fork the whole project right
now, given that I have access to all _independent_ tools required?".
As far as I can see, the answer for XEmacs right now might well be
"no".
XEmacs without packages is IIRC not usable since at least xemacs-base
would be required, and that is not built without the package system
which is not available as a source download.
So I think it likely that XEmacs does not meet the "could fork"
metric without reverting to more than what is offered as
"corresponding source code".
For example, did the SXEmacs project start from the existing binary
packages, or did it start from the CVS package tree? Or is it merely
a fork of the binary and thus irrelevant in this context since it
relies on the same packages as XEmacs?
--
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