Re: BSD-like licensed files in XEmacs Packages?

Štěpán Němec writes: Sorry, that would be a lie. :-/ The source is a private communication from His High Gnuisance himself. There's also this: http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL Evidently, if you `require' any GPL-ed libraries, you're done for. Even if you don't, Richard told me that use of Emacs-specific "facilities" like buffers is what is meant by "'bindings' to other facilities (often, but not necessarily, libraries)" in that FAQ. Well, they and you are at some risk, then. I doubt it's very much, as the FAQ is rather ambiguous, the Emacs Lisp manual *does* describe buffers etc as part of the language, and as long as you only distribute your code and not Emacs itself the FSF is at much greater risk, as many competent lawyers believe that copyright law does *not* imply that dynamic linking is derivation unless you distribute the original work "with" your own code. If you decided to challenge their claim, they'd be in very big trouble if you won -- the whole GPL vs. LGPL distinction vanishes into thin air (although it would be very expensive for anyone to fight them in court, and they have a long history of using that to intimidate people). So the FSF is unlikely to go after individuals or non-Emacs projects IMO. XEmacs, however, is a much fatter target for them as they can go after us on the grounds that XEmacs + the packages constitute a single product, and the whole thing is a derivative work of GNU Emacs. If they lose that, they just say, oh, we're sorry, and nobody will ever mention the dynamic linking aspect. That's a very big project if you don't think the other programs you mentioned are good enough. Mike (Sperber)'s student did some work on implementing Emacs Lisp in Scheme48, which would get us partway there.[1] But then we'd have a huge amount of effort, which nobody involved in (SX|X)?Emacs development could safely be involved in, to create the compatible API to things like buffers and strings. I don't think such a thing is likely to happen soon, so the most plausible route would be a Schemacs core engine, based on a libre-licensed Scheme, combined with UI and API derived from (SX|X)?Emacs, with the whole work licensed under GPL. It would be somewhat easier to drop Emacs (and XEmacs) compatibility, but as I say, if the programs you mention aren't good enough, then we're a very long way from accomplishing that. Footnotes: [1] The specific result was that an Elisp interpreter with appropriate semantics for variables etc written in Scheme48 got within spitting distance of native Elisp performance. But this was only for Lisp-y constructs, not for things like buffers and UI. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta