Hrvoje> James LewisMoss <jimdres(a)mindspring.com&gt; writes: Hrvoje> What's wrong with the good old `M-x byte-recompile-directory' Hrvoje> once you fix the bug or make the change? Well in terms of debian packaging that doesn't work, but that's not the issue. Technically nothing, but the bit of the GPL that says the dist must include the scripts used to compile the source is what I was mentioning. I think it'd be perfectly reasonable for the xemacs developers to reject this as not a violation of the GPL. I can see both sides, but I wanted to bring it up in case people did find it a violation it could be corrected. Another person brought up that there are source packages available. Correct me if I'm wrong, but the only available "source form" is cvs. Is this not correct? Jim -- ＠James LewisMoss <dres(a)debian.org&gt; | Blessed Be! ＠ http://jimdres.home.mindspring.com | Linux is kewl! ＠"Argue for your limitations and sure enough, they're yours." Bach

Dres> OK. I hate to bring this up, but looking at it the person Dres> who reported this bug to me looks to have a point. I don't see one, just a hyperactive imagination. All .debs suffer from the same "bug." None of them have debian/rules in them, but many have scripts which are surely source code. The GPL doesn't say that just because you provide some sources in a particular medium you have to provide them all that way. Nor does it say anything about replicating the binary you have, only about access to the sources used to build the binary. Debian doesn't keep even one past copy of .diff.gz on its servers, let alone all of them for three years!! Do you have a global CVS repository? If not, you guys are all in big trouble by that argument.... 1. We're basically covered in spirit under GPL 3(b); every XEmacs installation that handles packages (>=20.4) should have instructions for how to get to cvs.xemacs.org. So maybe we have to add a README to every package. 2. In the case of .el -> .elc, emacs itself is the Makefile! For an individual .el, M-x byte-compile-file is all that's necessary in most cases. M-x byte-recompile-directory for whole packages. Where something more complex is needed, as with VM and I believe Gnus, we do supply the upstream Makefile. If we don't it's a bug, but only in the particular package. The scripts and so on that exist in the xemacs-packages hierarchy are mostly concerned with building the distribution, not with .el -> .elc compilation. AFAIK, the GPL does not require that you provide the tools to recreate the distribution tarballs, merely the software. To the extent that the clean environment affects the build, the user would have to check out the same version of XEmacs, build it the same way, and check out all the packages (in compilation, a (require ...) basically includes the macros in the required file, and they get inlined). Nobody in free software provides that level of replicability, I don't see why we should be burdened with it. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

Stephen> All .debs suffer from the same "bug." None of them have Stephen> debian/rules in them, but many have scripts which are Stephen> surely source code. The GPL doesn't say that just Stephen> because you provide some sources in a particular medium Stephen> you have to provide them all that way. Dres> I'm not sure what you are saying here. There's no requirement in the GPL v2 that sources must be distributed the same way as binaries, just that they be available on a "medium commonly used for distributing software". In our case, that's CVS. We happen to deliver some of the sources that are especially useful with the "binary" package, but not the distro building scaffolding. As I read the GPL we're technically "over and above" the requirement, since CVS covers us under 3(b) as long as we have an appropriate README, we don't even need to distribute .els. The comments about Debian are just an analogy. My point is that Debian is as anal about legalities as anybody; if Debian does it, it's probably pretty close to compliance (although you won't know until somebody sues). As I read the GPL, it is not an attempt to prescribe that developers must make it _easy_ for the braindead to use redistributed software sources. It is intended to proscribe them from making it _hard_ for people of very moderate competence to use redistributed sources. The prescriptive clause 3 is intended to provide a minimum standard. Note that the comments about scripts and stuff are not part of the GPL as a contract; they are a descriptive gloss intended to help a court interpret the intentions of the contracting parties. In the case of XEmacs packages, lack of a Makefile doesn't make it hard (in an absolute sense) or errorprone to use .els (except in cases like VM, where we do provide the Makefile). OTOH, the Debian project with their debhelper, kernel-package, etc, and even Red Hat with the SRPMs are to be commended for providing the value-added service of making it easy (relatively) to rebuild packages from source. Stephen> To the extent that the clean environment affects the Stephen> build, the user would have to check out the same version Stephen> of XEmacs, build it the same way, and check out all the Stephen> packages (in compilation, a (require ...) basically Stephen> includes the macros in the required file, and they get Stephen> inlined). Nobody in free software provides that level of Stephen> replicability, I don't see why we should be burdened with Stephen> it. Dres> No one ever argued this. Bringing it up is a waste of time. The post you included didn't complain about inability to build a working .elc, it complained about being unable to get all the command lines etc right. Either the person is nearly completely ignorant of how Emacs Lisp development is done (which is no sin, but then their problems with rebuilding are not GPL problems, they are documentation bugs), or they are demanding a rather fine degree of replicability, or ...? What is your interpretation? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

Justin> At 3:47 AM +0900 2/24/01, Stephen J. Turnbull wrote: Justin> The same argument could be applied to binary packages of Justin> GPL software. For most of the rpms that I install, I only Justin> have binary code. There is no source code, or Makefiles, Justin> or anything. I do not see that as a violation of the GPL. Justin> You don't need to package gcc with xemacs, just say that Justin> you need a compiler. You're missing the point I was trying to make. Of course the basic answer is "if you can run the Lisp, you have XEmacs, and you can build the package with byte-compile-file." As I read the post attached to Jim's message, however, the poster wanted the apparatus we use to build packages to make sure that the locally built package was identical in functionality to the distributed one. The GPL _does_ require that you make any patches available for three years. Now, much of the code in a .elc is actually inline-expanded by the byte compiler. Recently there was a bug fix to the byte compiler which changed the inline code, requiring a rebuild of every package. We have no way of tracking that, but the letter of the GPL probably requires us to do so if we distribute .elcs. (This doesn't apply to GCC on Linux, because it's part of the system.) And it certainly requires Debian to keep its .diff.gzs if they change the upstream code. (I'm pretty sure the contents of the debian/ directory are "merely aggregated.") [Aside: I find the GPL very problematic as a foundation for Linux- style distribution. It is extremely vague on the subject of binary distribution. It is much better suited to BSD-style "ports" or "packages" distribution.] -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

Valdis> On Mon, 05 Mar 2001 14:02:03 +0900, "Stephen J. Turnbull" Valdis> <turnbull(a)sk.tsukuba.ac.jp&gt; said: Valdis> Umm.. how is this any different than the "RedHat Valdis> distributed a GCC 2.96 snapshot that won't compile the Valdis> kernel correctly" problem? System software has an explicit exception in the GPL. XEmacs doesn't qualify. Valdis> Does this mean that Linus has to put gcc patches into the Valdis> kernel distro, under the theory that "you need gcc Valdis> 2.96+patches to build it"? No. But Red Hat must (IMO) provide a compiler capable of building the kernels the distribute if they distribute kernels, and quite possibly they must provide the one they actually used to produce the kernel binaries. Valdis> I don't see why the Linux kernel gets away with just Valdis> saying "you need gcc such-and-such, modultils Valdis> such-and-such, PPP such-and-such" - if that's OK, we Valdis> certainly should be able to just say "You need XEmacs Valdis> 21.2.<mumble> or later so you have a non-buggy byte Valdis> compiler". The issue is not providing the user with a non-buggy byte-compiled .elc. It is providing the user with a buggy byte-compiler for their amusement and documentation. Maybe they _want_ the bug. I consider that we satisfy provision of the byte compiler via CVS and GPL clause 3. What we don't have is an accurate way to match up the .elc with the version of the byte compiler that produced it. Valdis> 1) XEmacs base code .elcs that went out with a buggy Valdis> byte-compiler. Hey, we didn't know, there isn't much we Valdis> can do about them. We can provide the byte compiler for downstream analysis. Valdis> 2) XEmacs base code .elcs that has the patch. It's got Valdis> the patch in the source tree that we distribute with the Valdis> .elcs, that patch will stay in the source that gets Valdis> distributed for 3 years. We're done. Wrt to the patch, if it stays that way and Martin doesn't fiddle with it in the meantime. However, we still have an obligation to provide the source to the buggy byte-compiler on demand for three years. What is not clear is whether (in the extreme) the user can present us with a .elc and say "I want the byte compiler that produced this .elc". I think that the GPL comes close to that. Valdis> I'm obviously not being anal-retentive enough about the Valdis> GPL's intent. What am I missing here? That the spirit of the GPL clearly requires that the user be able to get the source to the binary he has in hand for three years after it was last distributed by the modifying party. I consider this to be an ambiguous mess. But then, this _is_ the GPL.... -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

Matt> -- "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; spake Matt> thusly: Matt> What, you mean to say that Emacs isn't an OS? ;-) Never! However, since we distribute both XEmacs and the packages, we don't qualify for the exception as written in the GPL. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

Valdis.Kletnieks(a)vt.edu wrote: Hmm. The GPL says: : 3. You may copy and distribute the Program (or a work based on it, : under Section 2) in object code or executable form under the terms of : Sections 1 and 2 above provided that you also do one of the following: [snipped] : b) Accompany it with a written offer, valid for at least three : years, to give any third party, for a charge no more than your : cost of physically performing source distribution, a complete : machine-readable copy of the corresponding source code, to be : distributed under the terms of Sections 1 and 2 above on a medium : customarily used for software interchange; or, AFAICT, we don't actually have to provide source, just offer to provide it upon request. Unless such a request is almost certain to be made, there doesn't seem much point in expending effort before the fact. And furthermore: : 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. I don't see any mention of the actual compiler in there. The term "scripts used to control compilation" seems (to me) to refer specifically to things other than the actual compilation tools. I'm sure that I recall someone arguing that this was a loophole in the GPL. -- Glynn Clements <glynn(a)sensei.co.uk&gt;