Olivier Galibert writes:
OG> The XEmacs CVS package repository is the preferred form for the
OG> sources for modification.
My point is that it's not, not even using the incorrect interpretation
of "convenience for a particular user". It is *a* preferred form
optimal for certain kinds of modifications---specifically,
modification with intent to distribute as free software.
However, when some !"#$%ing package goes south on me in the middle of
work, *my* preferred form of source for modification is the one at the
other end of M-x find-library, and I do *not* rebuild the package with
"make".
I conclude that legally "preferred form" can't refer to a specific
tree of files.
OG> Amusingly enough, some people argue that the GPL source
OG> distribution of anything that is kept under a SCM system should
OG> be done with the complete SCM history included, because the
OG> source alone does not meet the "preferred form" criteria.
I don't find that amusing at all, because it's a perfectly logical
extension of what I understand David to be asking for, and both are
misinterpretations of the language in the GPL IMO. In fact I think
the XEmacs Project should strive to achieve that goal, but it's
clearly an unjustified infringement of freedom to *require*
redistributors to do so.
It's pretty clear from the juxtaposition of "source" and "preferred
format" in the GPL that "preferred format for modification" is
intended to refer to the *content of the source files* and not to the
organization or functionality of the source package. Ie, the idea is
to prevent a simple-minded definition of source as "a file that can be
run through a translator" being interpreted to allow calling a gzipped
executable "source". The functionality of the source distribution is
clearly stated: to build modified executables. The organization is
not intended to be dictated at all, as long as the user can use it to
build modified executables without undue effort.
It is *possible* that a court would decide that the phrase "scripts
used to build the executable" refers to the literal Makefile that was
used to build the executable distributed in the binary package. If
so, I consider that a bug in the GPL, because it amounts to mandating
a specific structure for source packages. (Being a bug doesn't
prevent it from being legally binding, of course.) However, I don't
think that a court would do so, given the stated purpose of the GPL
(specifically, to enable people to create and execute derived versions
of the software) and the surrounding language. I think that if I
bring my laptop into court and demonstrate rebuilding a package with a
few keystrokes (not including the string "make" :-), they'll rule that
said package does not have any scripts that are needed to build it.
OG> BTW Stephen, is there any real reason not to include the two files
OG> [David talks about], even if they're pretty much unusable outside
OG> of a CVS context from what I understand? They can have some value
OG> as an example, I guess.
My main reason is ethical: if I'm right, then David is trying to
restrict our freedom in a way not justified by the license. Caving in
to his bullying and FUD would be at a similar ethical level to buying
a Linux license from SCO.
For potential practical implications of deciding to include those
files, see my response to Glynn Clements.
I think a better response is to make it absolutely clear that the
installed binary-with-source package is designed so as not to need the
package tree infrastructure. Add to xemacs-base (not xemacs-devel!):
;;; placate-dak.el --- support rebuilding packages in the installed tree
;; #### Naming bug: this is hardly likely to placate David Kastrup.
;;;###autoload
(defun placdak-rebuild-package (package)
"Rebuild a binary-with-source package PACKAGE.
Call this function from an installed package root."
(interactive "sName of package to rebuild: ")
(cd (file-name-as-directory (expand-file-name package "lisp")))
;; if PACKAGE-placate-dak exists, it contains a replacement for
;; this function
(load (expand-file-name (concat package "-placate-dak")
(current-directory)))
(let ((func (intern (concat package "-placdak-rebuild-package))))
(if (fboundp func)
(funcall func package)
(update-autoload-files (default-directory) package)
(cd (file-name-as-directory (expand-file-name package "../man")))
(shell-command (concat "makeinfo -o ../info/" package ".info "
package ".texi")))))
(provide 'placate-dak)
;;; placate-dak.el ends here
Of course you could do this with a similarly simple Makefile per
package, too.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta