Thanks, of course if anybody else wants to do the upgrade, this is more than welcome. Uwe _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> The latest version is also GPLv3, unless I'm mistaken. We Stephen> can't distribute it until we relicense. OOPS! Stephen> If somebody wants to get working on that, be my guest. Stephen> Basically we need to put GPLv3-or-later notices in all the Stephen> files that currently have "standard" GPLv2-or-later notices, Stephen> and get a list of files that Stephen> (a) don't have a notice, (b) have GPLv2-only notices, (c) have some Stephen> other kind of notice, and decide what to do about each type (a), (b), Stephen> and (c). I fear there are some questions to sort out before digging into this ;-) - Do we really have to relicense all packages at the same time? (Which means we can't do a release until they are all fixed in CVS? Nothing more, nothing less.) Since the XEmacs packages are distributed together in some sense the GPLv3 really means it is an all or nothing thing? That each package in some other sense is a package on its own doesn't matter? - There is no problem with us relicensing GPLv2 stuff code to GPLv3 because that right is granted by GPLv2. Right? - Some packages are already GPLv3 upstream. Would syncing as part of this task be worth while? (I guess it would best to decided this on a per package basis since some syncs might be very time consuming!?) Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Uwe Brauer writes: I didn't realize that; you should check exactly what the licensing of reftex is, then. If it's not v3, we're definitely OK. If it is v3, we may still be OK, but the problem is that packages are useless without XEmacs (I wouldn't claim that we're distributing them so that GNU Emacs can use them), and Richard Stallman has made claims that I understand to mean that makes them "part" of XEmacs. Nobody knows, because no court has ruled on it. Richard says "yes" (except that he'd whack you with a piece of lead pipe for using a disease metaphor), Larry Rosen says "no". I trust Larry more than I trust Eben Moglen, who backs up Richard. But Richard gets his lawyer's court time for free, we would have to pay for ours. He doesn't hesitate to use the threat of imposing litigation costs to get his way, either. See my reply to Mats. I think the ONLY thing that relicensing a package forces to be relicensed is a SUMO. We don't need to relicense the package infrastructure[1], we don't need to relicense XEmacs core. I don't have time to go into detail, but I have a comment from RMS on a related issue that leads me to believe that is true. Footnotes: [1] Subject to David Kastrup's claim that the package infrastructure is the "scripts used to build the executable code". I disagree with that but need to ask a lawyer. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Rodney Sparapani writes: I know people *do* use XEmacs packages with GNU. Nonetheless the extra stuff (package-info etc) is designed to work with XEmacs, and GNU Emacs provides no support for that. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Well but 11.84 is GPL2+ _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> No, I don't think it's all or nothing. The packages are a Stephen> "mere aggregation" AFAIK. The SUMOs have to be licensed as Stephen> GPLv3 if they contain GPLv3 packages, but that doesn't Stephen> prevent individual files from having their own licensing, as Stephen> long as it is upwardly compatible to GPLv3. We only have to Stephen> relicense packages that themselves contain GPLv3 code. OK. So what it boils down to is this?: - to distribute a SUMO all files in all packages must at least be of GPLv2 status. - when a single package is synced with a GPLv3 version up stream the whole package, all files in the package, must be GPLv3, Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> Mats Lidell writes: Stephen> No. A SUMO is a mere aggregation. As I understand it, the Stephen> SUMO as a whole is distributed under the GPLv3, but Stephen> individual packages can be separated out under their own Stephen> licenses. OK. I was a bit vague here. What I should have said was: (to distribute a SUMO all files in all packages must at least be) "upwardly compatible to GPLv3." So this is the task. Find all files not compatible with GPLv3 and fix them. Stephen> Probably the easiest thing is to just upgrade all files in a Stephen> package when we upgrade any single one. As part of this task we should IMHO, in order to be able to complete it, only upgrade packages that isn't upwardly compatible to GPLv3. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> Mats Lidell writes: Stephen> Well, that's not as easy to do as to say; I know... Stephen> if they are not GPLv3- compatible we need permission of the Stephen> author to fix them. Yes. Stephen> I'm not sure what you're saying here. Well, maybe it is to obvious, but I think we should not at the moment bother upgrading or syncing packages that already is GPLv3 compatible. We should focus on the packages that isn't in order to bring the SUMO into shape for a GPLv3 release. So the plan could be like this: 1. Go through the list of files that needs to be investigated manually in order to classify them. 2. Based on this classification also classify each package. 3. For packages that isn't GPLv3 compatible se what can be done. Possibly contacting the copyright holder. 4. Do what ever is needed for each package based on the analysis. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: I think the "mere aggregation" angle does not cut it since it leaves the build system uncatered for. You have previously stated that the build system is not considered part of the individual packages and so the control files for building packages need not be distributed as package source. Now the GPL states The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work. You have previously stated that the control files used for building the packages are not supposed to be part of the package source. Now if Sumo is supposed to be a mere aggregation, then those control files also are not part of Sumo. They are not part of XEmacs proper either, since XEmacs is distributed without them and without any preinstalled packages. So what are they part of? -- 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

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: You are confused. .deb files are not even supposed to contain the source code to a package. They are only distributed accompanied with the corresponding Debian source file packages (from the same server, or available at no extra cost), and those certainly contain debian/rules. Your XEmacs package distribution does not include either instructions how to get the source, nor is the package-specific build source distributed alongside. Not on the same server, not on request. There are no XEmacs source packages containing the package specific scripts for building the binary packages. So don't use Debian packages as an excuse: Debian _does_ distribution of the complete sources and build scripts, as source packages accompanying the binary packages. Nobody but you claims that .deb is supposed to include source. -- 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

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: That's because you haven't heard anybody else's opinion: I have stated the problem just on this list, and the developers leave it to you to bluster your way out of any licensing problem. So you make it appear basically as sort of a standoff between the two of us: nobody but you claims that XEmacs packages are including all of the corresponding source required for building them, according to the letter and spirit of the GPL. The problem is that making it appear like a standoff does not help in addressing the problem: if anybody tries solving what actually is a technical problem in a technical way, he would appear as opposing you as the project leader. If you prefer getting a more authoritive opinion from the FSF copyright clerk, I can certainly inquire there. Of course, you'll picture a potentially unfavorable result as some sort of David and/or GNU vendetta specifically aimed at XEmacs. It is a bit hard to phrase an appropriate reply since you are vacillating between various excuses (I'll take the GPLv3 language here since the "bluster our way out of this" approach will most likely continue through the GPLv3 licensing. Since the GPLv3 provisions are even more lenient where different, this does not actually invalidate the point I am making). a) The GPL language of The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. somehow does not apply to all the source needed to generate a particular XEmacs package file, specifically not the scripts controlling this activity. Note that I am not talking about the generic XEmacs package build system here (which I regard as an independent work), but the package-specific control files, like XEmacs.rules (IIRC). b) The GPL language of d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements. somehow implies that sticking the files on some CVS server without public access and without announcement in packages or elsewhere is supposed to constitute "equivalent access" to packages widely distributed via different channels: ftp, disks, Linux distributions, XEmacs mirrors and so on. Your recent The GPL doesn't require that Debian distribute debian/rules with every .deb built from GPL sources, and it doesn't require us to distribute XEmacs.rules with every -pkg.tar.gz. diatribe can be sorted in either category, depending on whether you want to ignore the parallel distribution of Debian source packages (which include debian/rules) or claim that a single semi-private CVS server constitutes "equivalent access". I can't give up a fight I am not participating in. As long as you consider everybody reporting and explaining a problem (whether legal or technical) an enemy, you'll never run out of either untackled problems or enemies. And if your friends fail to tell you when you are wrong and help you address a problem, that lot remains with the enemies. I don't care which camp you want to group me with. What I do care about is that problems get addressed. And not by badmouthing the messenger and misrepresenting the message. As long as you keep doing that here with regard to reports of mine, expect that I keep correcting you. You don't have a monopoly on boneheadedness. -- 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

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: XEmacs.rules (for example) is not part of the package builder source, but is rather a control file specific for each particular package. It is a required part for building the package in the preferred way, and it is not provided as source accompanying the package according to any of the GPL's provisions. The subtle point is that you have no leg to stand on. Whatever training you have received for dancing around this (probably the ancient Japanese art of "saving face") does not appear to confer much of an advantage over an unlearnt unsubtle village idiot like me. Since the package-specific control files required for building a package are rather small, it is not obvious to me why you prefer smearing egg all over your face time and again over including them in the package. -- 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

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: Sigh. Yes, wrong example. I don't use XEmacs at all, so something wrong stuck. Taking a look at <URL:http://www.xemacs.org/Documentation/21.5/html/lispref_4.html#SEC23> we get 3.2.2 Control Files Each package source must contain a number of control files in the top-level directory. These files in general can be created and then ignored, except for a few variables that need to be updated when new versions are released. In most cases even adding, renaming, and removing library source files can be handled by generic rules. The package control files include `Makefile' Must set a few `make' variables used by the administrative utilities, and defines a couple of package-building targets to depend on appropriate targets defined generically in `XEmacs.rules'. It may also provide various variables and rules to transform the source tree structure into that expected by the run-time system. `package-info.in' Provides a template for package information to be provided to the administrative utilities. Static variables that are rarely changed (such as the package's name) are entered as literals. Some variables are generated by the build process (build dates and MD5 checksums) and are automatically filled in. Finally, some variables that change irregularly (dependences and even version numbers) are set as `make' variables in the `Makefile'. It is quite clear that you are talking here about "each package source" and about package specific control files. There are a few more mentioned, but ChangeLog is not part of the build procedure, and the others are autogenerated and thus need not be distributed. And so on. Come on, you recognized "wrong example" right at the start, and you still go on making an argument? Which means that the standalone XEmacs package don't come with source, since essential files are missing. If you remove a particular package from CVS, the binary package distribution is not sufficient for putting that package into a private build tree and rebuilding. So you need a source distribution path meeting the GPL conditions. No, the package-specific part of the source tree that can't be readily autogenerated from the final package. Surprise, surprise, that is what everybody else does. That's what source RPMs, source debs and so on do. Nobody (in particular the GPL) is bothered about the non-package-specific parts of the tree. Various Emacs Lisp applications are distributed without Emacs (without which they don't make sense). I think we established already that XEmacs.rules was the wrong example. -- 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

David> b) The GPL language of David> d) Convey the object code by offering access from a designated David> place [...] David> somehow implies that sticking the files on some CVS server David> without public access and without announcement in packages or David> elsewhere is supposed to constitute "equivalent access" to David> packages widely distributed via different channels: ftp, disks, David> Linux distributions, XEmacs mirrors and so on. There's a README.SOURCES at http://ftp.xemacs.org/pub/xemacs/packages/ and in some of the mirrors (e.g., http://ftp.freenet.de/pub/ftp.xemacs.org/tux/xemacs/packages/ has it, but http://mirror.aarnet.edu.au/pub/xemacs/packages/ does not). There are some problems with the current text (see http://tracker.xemacs.org/XEmacs/its/issue403), but if those are fixed, how far would that go towards addressing the problem that you see? People who get packages by downloading them from xemacs.org will presumably see the notice. Wouldn't distro providers, not XEmacs developers, be responsible for providing the equivalent information in their distros? mike _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Hans de Graaff writes: Excuse me, but by design the released package *is* the versioned source. That was an absolute design requirement of the whole package system: you had to be able to modify and rebuild the package (as installed, not the tarball), either in-place or in a separate tree. The CVS tree is a version with different meta-content, with the purpose of facilitating contributions to the XEmacs project. However, if you want to contribute changes made in-place, of course we accept patches against the original installed files rather than against CVS. This is way less than ideal, actually, since the user may not have the same versions of packages installed as the sources expect. So now you have completely lost control over the content of the installed .elcs. This is a design problem with Emacs Lisp macros. Even with GNU Emacs with its monolithic distribution of all Elisp they care about, if the user has anything like a CVS version of APEL in their environment, you will lose, because those guys monkey-patch the core. I'm not saying rebuilding in the user's environment is a bad idea; often it's a great idea. But there are potential problems with it, it's not *ideal*. I don't understand what you mean by "properly install". Just cp -a the contents of an unpacked -pkg.tar.gz, after any modifications you like, and recompiling. Or tar it up. That is an "XEmacs package", in the sense that it will work in any installed XEmacs package system without screwing up the installations of other packages.[1] I'm not sure if the same applies to the TeX and Java code in packages like AUCTeX and JDE, but I don't see why it wouldn't. The only problem would be build-time detection of external executables, libraries, and the like, but AFAIK both AUCTeX and JDE have solved those problems so that prebuilt, working packages can be untarred into the package tree and Just Work. What exactly do you want to "get working"? Compiling in the user's environment is trivial, but versioning any compiled Elisp is really, really hard; we've never been able to get a complete handle on dependencies (darn autoloads ...). Footnotes: [1] Of course it's not an official XEmacs package, in the sense that we will refuse to distribute it. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Fri, 2008-10-17 at 15:36 +0900, Stephen J. Turnbull wrote: We can handle the versioning in the Gentoo ebuilds, so we do know which packages are installed. We already do this now for the pre-compiled packages as well. Unfortunately this information (against which version of other packages this package should be compiled) is not available in the package file itself. My understanding is that if I compile the package against xemacs 21.5 instead of xemacs 21.4, I get better results since I may not need to use compatibility code in 21.4 that is supported in 21.5. Perhaps that assumption is incorrect? The "recompiling" part is what makes this interesting. In CVS there is an infrastructure to handle this using Makefiles, but that is not available in the distributed packages. So I should just byte-compile all the files again and hope that nothing special is done in these Makefiles that I might be forgetting to apply? Compiling in the user's environment is nice to have since it keeps in line with Gentoo's philosophy. The ability to patch the elisp code is also very useful since that enables fix problems (security issues come to mind) that might crop up without having to wait for official packages. Kind regards, Hans _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

David Kastrup wrote: David Kastrup wrote: Can't XEmacs have something like a link to the CVS/mercury server that hosts the xemacs package lisp source code? That should be simple enough for all the people who are demanding the source code. And I agree with Stephen, it is _not_ required to include XEmacs source within the binary packages. Thanks Wei _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

David Kastrup writes: My sole contention all along has been that the package tarball is not the derived work described by the GPL, and that the executable libraries and data require only common OS utilities and XEmacs to work on them, in a standard way (cp the data, M-x byte-compile-file for the libraries). It's that simple. There is no problem, except convincing you that you are wrong. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Hello Frankly I am confused after having read all the thread. The original question was, how to synchronize pkgs which are under GPLv3+, such as reftex and auctex 11.85 (Mats and I were working with auctex 211.84 which is under GPLv2+) with our system. So do I understand correctly that in order to make pkgs with GPLv3+ compatible with the Xemacs pkg system, we would have to change all files with GPLv2--> GPLv2+????? As I understand correctly there are scripts trying to do this but it is not clear whether they have succeeded. Couldn't we just take a very pragmatic point? We release reftex and auctex (11.85) under GPLv3+ and if somebody comes up with a contradiction, that is files under GPLv2, we say oooops and change the relevant piece. Uwe Brauer _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Fri, Sep 19, 2008 at 12:31 AM, Stephen J. Turnbull <stephen(a)xemacs.org&gt; wrote: Didn't I make that list a few months ago? Also, is it really necessary to change the GPLv2-or-later notices in individual files; i.e., wouldn't those be okay within a GPLv3-or-later distribution? -- Jerry James http://loganjerry.googlepages.com/ _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Stephen> Basically we need to put GPLv3-or-later notices in all the Stephen> files that currently have "standard" GPLv2-or-later notices, Stephen> and get a list of files that Stephen> (a) don't have a notice, (b) have GPLv2-only notices, (c) have some Stephen> other kind of notice, and decide what to do about each type (a), (b), Stephen> and (c). You can find the output from the findgplv2 script used on the packages here: "http://lidell.homelinux.net/~matsl/xemacs/nogplpackages/noGPLv2found" This list contains the files that does not contain a gplv2 or later notice, at least according to the script. So these files needs some further investigation. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta