Sven Luther wrote:
On Mon, Jan 12, 2004 at 02:12:13PM -0500, Brian T. Sniffen wrote:Sven Luther wrote:On Mon, Jan 12, 2004 at 01:00:54PM -0500, Jeremy Hankins wrote:Sven Luther <sven.luther@wanadoo.fr> writes:uncertain about whether you should disable the automatic generation of .elc files.Why ? We clearly are not violating the GPL by doing so, so where is the problem.If the situation is perfectly clear and uncontroversial to you, either you don't know what you're talking about, or everyone else is confused but you. I put my money on the former. Saying you disagree is one thing, saying any other perspective is clearly wrong is silly.Come on, we don't distribute binaries of it, so how could this break the GPL ?Simple: Debian distributes Emacs and this elisp file. Futher, it distributes a mechanism for combining them and causing them to interoperate. Thus, any Debian Distribution installation of both is a derived work of both Emacs and this elisp file. The components must be available under the terms of the GPL, so that individual component -- the elisp file -- must be available under the terms of the GPL.Yep, but whatever you say, the GPL is a licence which applies on distribution only, not use.
Indeed. And you are pointing out that we distribute Emacs and this elisp file together, more closely intermingled than "mere aggregation" would imply.
The DFSG issue might be a different story, but even there, i am not sure it is correct though, since the GPL cause problem at link time, not at binary distribution time. And nothing is stopping us to distribute binaries of the .el compiled by a non-GPL lisp compiler or something.Good luck finding a non-GPL'd compiler for a dynamically scoped Lisp with bindings similar to Elisp.Well, it should be easy to write one, at least one which would parse and use the incriminating files.
That creation after the fact does not change whether the elisp file was created as a derivative work of Emacs.
There .elc are, if we distribute them, not linked with any GPLed code, and we never ditribute anything that might link this code with GPLed code, since this linking is always performed at link time. Of course, i may be wrong, or misunderstand the way emacs and its lisp compilers work, but if so, please provide explanation to me. Upstream is not some random emacs .el author, but the ocaml author, who did his phd thesis on writing the ocaml virtual machine, so he will not be impressed by poor assertions about these issues. So i would rather have strong arguments than careless asserted assumptions.There are no lawyers providing legal advice here. You could ask licensing@gnu.org, which often is answered by a lawyer. Alternately, you could structure the request in terms of politeness, as it's been suggested here -- that the author of Emacs thinks all Elisp code should be GPL-compatible, that it's not entirely clear he could legally enforce this, but that it seems the polite thing to do.Ok, but then, there is also the matter of respect of the author of said.el files, no ?
Well, sure. We should confine our actions to the intersection of the wishes of the two authors.
Notice that when faced with similar issues about the ocaml-nums library, whose legal property did get lost in the Dec->Compaq->Hp migration, he promprly reimplemented the stuff in a free way.So I think talking to the upstream is a good idea.Sure, but on more serious ground than this. Notice that the bugreport claims that RMS thinks that ..., not that it is actually true.Ok. So, for the sake of argument, assume he's dead wrong, but thinks so nonetheless. We should still, imho, behave as if he's correct, given that he/FSF owns copyright on emacs. This is what we normally do: give the copyright holder generous (and sometimes unreasonable) benefit of the doubt in terms of what rights they have and can enforce. Deciding what to do here doesn't involve taking a position on whether RMS is right or wrong (thank god!).Well, sure, but this would not help me convince upstream.Do you really think the upstream authors are so rude?What has that to do with anything ? Look how silly this argument sounds ?Imagine me telling the upstream author that he should please change the licence of his files, because RMS may feel offended ? Be serious please. This is debian-legal, not debian-please-stay-polite.
I think it's taken for granted that Debian will try to be polite. Requests for change are much nicer than threats of legal action. We don't need a clear threat of a lawsuit to act -- a polite request is enough. Such is true of most polite people, isn't it?
I don't think it's silly to imagine that the upstream author of this elisp file would change the license under which he distributes it when the author of the elisp parser for which he wrote the file requests such.
He also thinks that GNU documentation is free, which we don't, so i clearly would like to have a more solid case before i go to upstream about this.If you want an argument to present to upstream you might try contacting the FSF for a position on the subject.Mmm. I might, but as it is debian packaging issues, i thought it was the natural place for this kind of discussion.It appears at least as much to be a general issue of GPL-compliance.Which only implies distribution, not use, restrictions.
Sure. But given that Debian is in the business of distributing software, it needs to worry. If the claim "Essentially all Elisp files are derivative of Emacs" is true, then sure, they need to be distributed under a GPL-compatible license, or not at all. It is polite to respect the wishes of the copyright holder for the source work, and I don't see why you think it's silly to suggest such to the upstream author.
What else would you like anyone here to say? Will you continue to raise objections until someone advocates the conclusion that you want? OK, here: "Distribute all the warez you like. If you can get it for free and can figure out how to put it in a tarball, upload away!"
-Brian -- Brian Sniffen bts@alum.mit.edu http://www.evenmere.org/~bts/