[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?

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

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.

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.

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.

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?

(Of course, this is not to be confused with the policy of ignoring
patent issues until we have reason to believe they're being enforced.
That's a completely different issue.)

Oh, so we will chip a DRI version which include the nice enable S3TC
compression if the card support it ? After all, the graphic hardware
manufacturer already paid for a licence, and i doubt you can patent a
pair of bits to set in a graphic card register or so, still the DRI
project is being cautious, while waiting for over 6 month now that
S3/via respond to their inquiries.

You are not making a clear comparison here.

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.


Now, if nobody here knows about this, then please tell me so, and i will
ask the FSF.


Sven Luther

Brian Sniffen                                       bts@alum.mit.edu

Reply to: