Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?
On Jan 12, 2004, at 13:34, Sven Luther wrote:
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.
That is the same-old dynamic linking thing. Look at the archives of
-legal regarding, e.g., OpenSSL.
And nothing is stopping us to distribute
binaries of the .el compiled by a non-GPL lisp compiler or something.
[ I know nothing of emacs or lisp. Please pardon the ignorance. ]
Do these binaries not depend on emacs at all? If that is the case, then
they are not covered by the GPL; even RMS's message said that.
The problem arises if use material, like a non-trivial API, from emacs
which may be copyrightable.
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.
Actually, we do distribute something: emacs. I assume the package
configures emacs to use these .elc files by default?
Would a court see dynamic linking / linking at runtime / whatever as
just a technical difference from static linking, and consider that
technical difference irrelevant for finding copyright infringement? I
don't know, and I don't know of any caselaw that answers that.
Opinions on the issue are varied, and since Debian can't afford to
fight it, and we would be doing our users a grave disservice if we made
it their problem to fight it, we take the cautious (some would say
paranoid) approach and assume the worst.
Of course, i may be wrong, or misunderstand the way emacs and its lisp
compilers work, but if so, please provide explanation to me.
I have no idea how it works.
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 is, but as apparently no one on -legal is really familiar with emacs
internals, licensing@gnu.org may be able to provide better answers.
After all, several prominent members of the -legal community, myself
included, are devout vim users :-)
Reply to: