Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?
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.
> >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.
> >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 ?
> >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.
> >>(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.
Nope, just hoping that your comment about patents mean that indeed
debian will distribute such a patch :))
> >>>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.
Friendly,
Sven Luther
Reply to: