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

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.


Sven Luther

Reply to: