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 <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED], 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
