[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 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 ?

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.
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.

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.

> (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.

> > 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.

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

Friendly,

Sven Luther




Reply to: