On Sat, 20 Apr 2002, Craig R Hughes wrote: > Bart Schaefer wrote: > > BS> The GPL cuts both ways: If I take my local.cf file and declare it to > BS> be GPL'd, then I'm not allowed to add it to SA and distribute the > BS> whole thing as a new "work", because SA is not GPL'd and I do not > BS> own the copyright to SA. I can distribute my local.cf file > BS> separately, but I can't claim it to part of the same "work" as SA > BS> unless I lift the GPL restrictions. > > Actually, you can do exactly that -- the Artistic license specifically > allows you to use the GPL if you want to.
That doesn't matter. The *GPL* says that I can't include my GPL'd code in any other work that is not GPL'd. Even if SA's license says it's OK, I'm contradicting my own license if I do so. > BS> Tangential opinion: > BS> It's code if the compiler or interpreter (perl in this case) is > BS> unable to process some other part of the code without it; e.g., in > BS> the case of Perl programs, if it's read with a "use" or "require" > BS> statement, it's code, if it's read with a 'do' statement or by an > BS> explicit 'open' it's a config file. > > What about if it's read into a string and then eval'd? That's no different than reading it with 'do', is it? Once again: If the file is not being distributed, then the licensing doesn't matter. A local file that is never distributed is not affected by the license, no matter how it makes its way into the program at run time. There's no point in continuing to argue the semantics of "code" vs "config" in this context. > So I could take the emacs source, link it into some non-GPL code, and > release the whole thing, but only make the emacs sources themselves > available, but not my own extensions? No, you can't do that, but you can't do that because the GPL expressly prohibits it. However, you could write a program in elisp that requires emacs to run, and release *that* under a non-GPL license, provided that you included the sources to emacs. Of course you'd have to avoid using any part of elisp that isn't implemented in the emacs C code, because the elisp libraries are themselves GPL'd so any dependence on them will catch you out. > I think that's somewhat short of what the GPL requires. The intention > as I understand it is to ensure that modifications and extensions must > also be released. Quoth the GPL: "... it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program." Note in particular: "control," not "ensure." > There seem to be frequent instances on Slashdot and other forums of > people who resent extensions to GPLd code *not* being released. The resentment of third parties does not affect the terms of the license. > So we cannot include the languages analysis library as a plugin to SA > without placing under the GPL. This sounds like you agree with the > basic problem I think I have with such an inclusion. It's entirely likely that you can't include the library as part of SA without placing SA under the GPL. It's also likely that the plugin can't even be distributed separately from SA by a third party unless SA is under the GPL, because the library is GPL'd not LGPL'd. The question I've been addressing is whether GPL'ng SA would cause any trouble for anyone who has modified their local configuration. I think that it would not. That doesn't mean I think we should GPL it. (Note that SA *could* be distributed under *two* licenses, both the GPL and the Artistic, with a compile-time option to neither use nor install the language library if the licensee does not agree to be bound by the GPL.) _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
