Re: Bug#218073: ITP: dvdrtools -- DVD writing program
On 30 Okt 2003 Glenn Maynard [EMAIL PROTECTED] wrote: On Thu, Oct 30, 2003 at 03:35:41PM +0100, Andreas Metzler wrote: * Begin restricted code for quality assurance. * * Warning: you are not allowed to modify or to remove the * Copyright and version printing code below! * * If you modify cdrecord you need to include additional version * printing code that: * * - Clearly states that the current version is an * inofficial (modified) version and thus may have bugs * that are not present in the original. * * - Print your e-mail address and tell people that you * will do complete support for this version of cdrecord. * * - Tell the users not to ask the original author for * help. I'm not sure at all this is GPL-compatible or DFSG-compliant. Does someone already look into that question? One thing is sure, it has nothing to do with GPL 2c. This is certainly not DFSG-free: requiring me to provide complete support for a release in order to distribute modified versions isn't free at all. (It's GPL-incompatible, too, but although the cdrecord and dvdrtools source packages contain several GPL components, none of them appear to actually be linked to the problematic code.) I don't know if requiring me to include my email address is DFSG-free. [...] Just for the archives: Both of these issues (requirement of support and providing an e-mail address) have been fixed in 2.01a21. cu andreas
Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?
Forgot to add debian-legal to CC, done now. On Mon, Jan 12, 2004 at 08:43:45AM +0100, luther wrote: On Sun, Jan 11, 2004 at 05:03:05PM +0200, Kalle Olavi Niemitalo wrote: Package: ocaml Version: 3.07.2a-2 Severity: serious While looking for the invalid `if' form in caml-types.el, I noticed that the Emacs Lisp files of OCaml are distributed under the terms of the Q Public License version 1.0. According to http://lists.debian.org/debian-legal/2002/debian-legal-200211/msg00217.html, RMS thinks that a program that uses Emacs facilities needs to be GPL-covered. O, bother. If RMS is right about this, then it would seem that these files cannot be distributed. if RMS is right, then i will ask upstream to modify their licence, after all i am in good enough relation with them that i have other means of solving this kind of issues than the threat to remove stuff. But let's first ask debian-legal about this. Debian-legal, can you give me advice about this issue, so i can go to upstream with informed opinions and legal theory ? I have some doubts about this, since th GPL is all about distribution, not use, and since we distribute the .el in source form and have them compiled on the users system, and the actual linking only occurs at use time, there is no way a GPL distribution restriction should apply. Naturally, i could severly misunderstand something, which is why i search for the wisdom of debian-legal. Friendly, Sven Luther
Re: [vorlon@netexpress.net: Re: Bug#181969: [mdadams@ece.uvic.ca: Re: JasPer licensing wrt Debian Linux]]
Dear Ben and Others: I have sent an email to Image Power to see if it would be possible to make a change in the JasPer license. I do not know what will come of this. It has been a week now, and I have yet to receive a response. Hopefully, I will hear something from the company soon. Sincerely, Michael Adams --- Michael Adams, Assistant Professor Dept. of Elec. and Comp. Engineering, University of Victoria P.O. Box 3055 STN CSC, Victoria, BC, V8W 3P6, CANADA E-mail: [EMAIL PROTECTED], Web: www.ece.uvic.ca/~mdadams
Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?
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. 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!). (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.) 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. -- Jeremy Hankins [EMAIL PROTECTED] PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?
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. 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. 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. 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? (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. 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. -Brian Now, if nobody here knows about this, then please tell me so, and i will ask the FSF. Friendly, Sven Luther -- Brian Sniffen [EMAIL PROTECTED] http://www.evenmere.org/~bts/
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 [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 ? 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
[Fwd: Re: Since you designed the Debian 'swirl' logo...]
This will be of interest to anyone wanting to follow up on unauthorized use of the Debian swirl logo. We have a statement from its creator that the swirl was created from scratch. Original Message From: - Mon Jan 05 17:23:25 2004 X-UIDL: 45903-1032856428 X-Mozilla-Status: 0011 X-Mozilla-Status2: Return-path: [EMAIL PROTECTED] Received: from ms-mta-02 (ms-mta-02-smtp [10.10.4.6]) by ms-mss-02.nyroc.rr.com (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id [EMAIL PROTECTED] for [EMAIL PROTECTED]; Wed, 31 Dec 2003 16:27:03 -0500 (EST) Received: from nymx01.mgw.rr.com (nymx01.mgw.rr.com [24.92.226.31]) by ms-mta-02.nyroc.rr.com (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id [EMAIL PROTECTED] for [EMAIL PROTECTED] (ORCPT [EMAIL PROTECTED]); Wed, 31 Dec 2003 16:27:03 -0500 (EST) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by nymx01.mgw.rr.com (8.12.10/8.12.8) with ESMTP id hBVLR0oe018003 for [EMAIL PROTECTED]; Wed, 31 Dec 2003 16:27:01 -0500 (EST) Received: from [192.168.0.155] (c-24-12-178-188.client.comcast.net[24.12.178.188]) by comcast.net (rwcrmhc12) with SMTP id 20031231212700014007plole; Wed, 31 Dec 2003 21:27:00 + Date: Wed, 31 Dec 2003 15:26:59 -0600 From: Raul Silva [EMAIL PROTECTED] Subject: Re: Since you designed the Debian 'swirl' logo... In-reply-to: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Message-id: [EMAIL PROTECTED] MIME-version: 1.0 (Apple Message framework v609) X-Mailer: Apple Mail (2.609) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine References: [EMAIL PROTECTED] Original-recipient: rfc822;[EMAIL PROTECTED] The Debian logo was created completely from scratch using Adobe Illustrator on a Mac. The logo uses a modified version of Adobe's Poppl-Laudatio font, that is as close as it comes to using someone else's art (font faces are not copyrightable only the PostScript font file used to generate them) Hope this helps. Raul Silva On Dec 31, 2003, at 3:16 PM, Nathanael Nerode wrote: debian-legal wanted to check with you whether it was drawn entirely from scratch, or whether it made use of any pre-existing clip art in the 'swirl' design. If it was drawn from scratch, whether you'd ever licensed anyone else to use it other than Debian. And if it wasn't all from scratch, if you could possibly remember what sources you used. This is in order to clear up some potential legal issues relating to use of the 'swirl'.
Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?
Sven Luther [EMAIL PROTECTED] wrote: Forgot to add debian-legal to CC, done now. On Mon, Jan 12, 2004 at 08:43:45AM +0100, luther wrote: On Sun, Jan 11, 2004 at 05:03:05PM +0200, Kalle Olavi Niemitalo wrote: Package: ocaml Version: 3.07.2a-2 Severity: serious While looking for the invalid `if' form in caml-types.el, I noticed that the Emacs Lisp files of OCaml are distributed under the terms of the Q Public License version 1.0. According to http://lists.debian.org/debian-legal/2002/debian-legal-200211/msg00217.html, RMS thinks that a program that uses Emacs facilities needs to be GPL-covered. O, bother. If RMS is right about this, then it would seem that these files cannot be distributed. if RMS is right, then i will ask upstream to modify their licence, after all i am in good enough relation with them that i have other means of solving this kind of issues than the threat to remove stuff. But let's first ask debian-legal about this. Debian-legal, can you give me advice about this issue, so i can go to upstream with informed opinions and legal theory ? I have some doubts about this, since th GPL is all about distribution, not use, and since we distribute the .el in source form and have them compiled on the users system, and the actual linking only occurs at use time, there is no way a GPL distribution restriction should apply. DFSG #2: The program must include source code, and must allow distribution in source code as well as compiled form. It sounds like we can't distribute compiled forms. You could put this in non-free, since we can distribute the source. In that case, I am uncertain about whether you should disable the automatic generation of .elc files. So I think talking to the upstream is a good idea. Regards, Walter Landry [EMAIL PROTECTED]
Re: Distribution agreement for ATI FireGL drivers
On Sat, Jan 10, 2004 at 09:44:15PM +0100, Steinar H. Gunderson wrote: [I am not subscribed to debian-legal; please Cc any followups to me.] Hi, I've been trying to get ATIs FireGL drivers into non-free for a while (see the ITP at bug #218369), but there doesn't seem to be a proper license for it. I talked to ATI (who in general have been very helpful about this and other Linux issues) about this, and their legal department sent the following distribution agreement and requested that I sign it (I have of course not done so yet): This violates policy 2.3. We reserve the right to restrict files from being included anywhere in our archives if * their use or distribution would break a law, * there is an ethical conflict in their distribution or use, * we would have to sign a license for them, or * their distribution would conflict with other project policies. Sorry. -- Brian M. Carlson [EMAIL PROTECTED] 0x560553e7 signature.asc Description: Digital signature
Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?
Sven Luther wrote: 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. Indeed. And you are pointing out that we distribute Emacs and this elisp file together, more closely intermingled than mere aggregation would imply. 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. That creation after the fact does not change whether the elisp file was created as a derivative work of Emacs. 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 ? Well, sure. We should confine our actions to the intersection of the wishes of the two authors. 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. I think it's taken for granted that Debian will try to be polite. Requests for change are much nicer than threats of legal action. We don't need a clear threat of a lawsuit to act -- a polite request is enough. Such is true of most polite people, isn't it? I don't think it's silly to imagine that the upstream author of this elisp file would change the license under which he distributes it when the author of the elisp parser for which he wrote the file requests such. He also thinks that GNU documentation is free, which we
Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?
On Mon, Jan 12, 2004 at 08:53:42AM -0500, Walter Landry wrote: Sven Luther [EMAIL PROTECTED] wrote: Forgot to add debian-legal to CC, done now. On Mon, Jan 12, 2004 at 08:43:45AM +0100, luther wrote: On Sun, Jan 11, 2004 at 05:03:05PM +0200, Kalle Olavi Niemitalo wrote: Package: ocaml Version: 3.07.2a-2 Severity: serious While looking for the invalid `if' form in caml-types.el, I noticed that the Emacs Lisp files of OCaml are distributed under the terms of the Q Public License version 1.0. According to http://lists.debian.org/debian-legal/2002/debian-legal-200211/msg00217.html, RMS thinks that a program that uses Emacs facilities needs to be GPL-covered. O, bother. If RMS is right about this, then it would seem that these files cannot be distributed. if RMS is right, then i will ask upstream to modify their licence, after all i am in good enough relation with them that i have other means of solving this kind of issues than the threat to remove stuff. But let's first ask debian-legal about this. Debian-legal, can you give me advice about this issue, so i can go to upstream with informed opinions and legal theory ? I have some doubts about this, since th GPL is all about distribution, not use, and since we distribute the .el in source form and have them compiled on the users system, and the actual linking only occurs at use time, there is no way a GPL distribution restriction should apply. DFSG #2: The program must include source code, and must allow distribution in source code as well as compiled form. But we don't do distribute compiled forms, and it doesn't really make sense to do so. It sounds like we can't distribute compiled forms. You could put this in non-free, since we can distribute the source. In that case, I am Ah, but we are going to remove non-free anyway, so i clearly won't do that. 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. 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. 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. Friendly, Sven Luther
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 [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
Re: Bug#227159: ocaml: license conflict in Emacs Lisp support?
Sven Luther [EMAIL PROTECTED] wrote: On Mon, Jan 12, 2004 at 08:53:42AM -0500, Walter Landry wrote: DFSG #2: The program must include source code, and must allow distribution in source code as well as compiled form. But we don't do distribute compiled forms, and it doesn't really make sense to do so. Note that DFSG #2 says must allow distribution. Debian is not allowed to distribute binaries, regardless of whether it would like to. It sounds like we can't distribute compiled forms. You could put this in non-free, since we can distribute the source. In that case, I am Ah, but we are going to remove non-free anyway, so i clearly won't do that. 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 Debian sets up everything so that the user automatically makes the link in the postinst, a judge might see that as legally equivalent to distributing the compiled form. Especially since Debian distributes Emacs as well. It gets rather murky, and starts getting into what people's intent is. It might be fine, but I am uncertain. 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. Regardless of what RMS thinks, do you think that the compiled forms are legally distributable? I am far from an expert on lisp compilers, but I would think that the lisp compiler mingled itself with the code just as much as a C compiler. Regards, Walter Landry [EMAIL PROTECTED]
