Re: libreadline
On Sat, May 04, 2002 at 07:40:59PM +0200, Gregor Hoffleit wrote: Therefore, as long a user doesn't import the socket module in an interactive session, it never happens that both the readline library and the OpenSSL library are linked into the same program. A switch to editline (if it was feasible technically) is no solution, since it is well possible that there are/will be other Python extension modules in Debian which link with other GPL libraries. This is a fundamental problem. Again, I see that there's a potential problem, but where exactly is the borderline (I guess that means where do we want to draw a borderline ?). A few questions: (1) How about this: I ship two versions of _socket.so in the python2.1 package: One is linked with OpenSSL, the other doesn't include the SSL support. Upon loading, socket.py decides whether the interpreter is already linked with libreadline, and if that's the case, it imports the SSL-less _socket.so. Vice-versa with the readline module: It checks whether the interpreter is linked with the libssl, and if that's the case, it fails to import. This would legally and morally satisfy the GPL, right ? (2) If we shipped python2.1 with an SSL-less _socket.so, and alternatively distributed a python2.1-ssl package, which provides a SSL-enabled _socket.so, would that change anything ? (2b) If the python2.1-ssl package included a note of warning, and perhaps a description how to optionally (!) disable the readline module, would that be better than (2) ? (2c) If the installation of python2.1-ssl would remove the readline module, that should definitely satisfy the GPL, correct ? (3) Link _socket.so with GnuTLS instead of OpenSSl. I don't know how feasible this is. Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED] pgp8Y3ORcdsxk.pgp Description: PGP signature
Re: libreadline
On Sun, May 05, 2002 at 10:04:31PM +0200, Gregor Hoffleit wrote: * Jeroen Dekkers [EMAIL PROTECTED] [020505 20:33]: On Sat, May 04, 2002 at 07:40:59PM +0200, Gregor Hoffleit wrote: A few questions: (1) How about this: I ship two versions of _socket.so in the python2.1 package: One is linked with OpenSSL, the other doesn't include the SSL support. Upon loading, socket.py decides whether the interpreter is already linked with libreadline, and if that's the case, it imports the SSL-less _socket.so. Vice-versa with the readline module: It checks whether the interpreter is linked with the libssl, and if that's the case, it fails to import. This would legally and morally satisfy the GPL, right ? (2) If we shipped python2.1 with an SSL-less _socket.so, and alternatively distributed a python2.1-ssl package, which provides a SSL-enabled _socket.so, would that change anything ? (2b) If the python2.1-ssl package included a note of warning, and perhaps a description how to optionally (!) disable the readline module, would that be better than (2) ? (2c) If the installation of python2.1-ssl would remove the readline module, that should definitely satisfy the GPL, correct ? (3) Link _socket.so with GnuTLS instead of OpenSSl. I don't know how feasible this is. From a first look, GNU TLS has a very different API. The current code in the socket module won't work with GNU TLS. This is indeed a problem. Furthermore, replacing OpenSSL with GNU TLS won't resolve the fundamental dilemma. We would face the same situation for any other package that includes a Python extension module with a GPL-incompatible, but DFSG-free license. If this is the last word, then Debian could only ship GPL-compatible Python modules (and the same was true for all derived distributions). This seems to be in conflict with the Social Contract. I don't think there is one solution for this, we should look at each module seperately to see how to solve the problem. IMHO free, GPL incompatible licenses are only annoying. Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED] pgpX13BJIOB7t.pgp Description: PGP signature
Re: linux gpl question
On Fri, Apr 26, 2002 at 11:41:11PM -0400, Glenn Maynard wrote: On Fri, Apr 26, 2002 at 06:40:41PM -0500, David Starner wrote: Not by my understanding. A patch will include generally include pieces of the kernel source, and only make sense in the context of the kernel. That makes it a derivative work of the kernel. In theory, one could design a patch format that doesn't include any context data; it wouldn't be very useful or robust, but it could be done. Would the patch still be considered a DW? The patch is still representing a DW of the kernel source. At least by applying the patch you make derivative work. IANAL, but by modifying Linux (to make the patch) you agree with the GPL. I'm not sure it's legal to distribute patches which aren't under de GPL. I can't find the exact details on the web anymore, but I remember that NeXTStep distributed only the object files which should be linked with gcc by the user to make the Objective-C compiler. IIRC that wasn't legal and they GPL'd the source to comply with the GPL. This is only from my vague memory, so there is a change that this isn't totally correct. :) Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED] pgpWhXDsT7WHg.pgp Description: PGP signature
Re: openssl and GPL
On Tue, Apr 23, 2002 at 09:45:32AM +1000, Brian May wrote: Thanks for everyones responses. On Mon, Apr 22, 2002 at 11:09:21AM -0500, Steve Langasek wrote: It is OK to create GPL binaries linked against OpenSSL and compiled for Debian platforms, and distribute them outside of Debian. But the wording of the GPL indicates you could never distribute those binaries with Debian -- not even selling them on different CDs in a multi-CD set, I think. What if a program (lets say it has a new bsd license) is linked against both libreadline and openssl. Would this be ok? This would link libreadline with openssl and that isn't ok. Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED] pgpqHdkV1cOuZ.pgp Description: PGP signature
Re: Crypto++ licencing
On Sun, Apr 21, 2002 at 11:52:58AM +0200, Arnoud Galactus Engelfriet wrote: Stephen Zander wrote: I don't believe the US will ever stop supporting softare patents; there's too much money at stake. By the same reasoning, the EC member states should also all support software patents. The European industry also has a lot of money at stake in software-related RD (all the software in DVD players and mobile phones, for example). Software patents is the biggest threat for free software and we should *never* support them. Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED] pgpreQc2kI9aj.pgp Description: PGP signature
Re: Crypto++ licencing
On Sun, Apr 21, 2002 at 01:57:21PM +0200, Arnoud Galactus Engelfriet wrote: Jeroen Dekkers wrote: On Sun, Apr 21, 2002 at 11:52:58AM +0200, Arnoud Galactus Engelfriet wrote: Stephen Zander wrote: I don't believe the US will ever stop supporting softare patents; there's too much money at stake. By the same reasoning, the EC member states should also all support software patents. The European industry also has a lot of money at stake in software-related RD (all the software in DVD players and mobile phones, for example). Software patents is the biggest threat for free software and we should *never* support them. Keep in mind that I was responding to Stephen's comment that the US wouldn't get rid of software patents because of their economic importance. The exact same argument can be made for the European countries. I'm not saying the argument is right. I have the idea that Europe is less braindamaged then the USA. I hope I don't get proved wrong... Nevertheless, I'm not sure this is the right place to debate patent policy. I don't think Debian should worry too much, unless they receive notification from a patent holder identifying a patent and a program that infringes. The problem is that it's already too late when we receive a notification. I agree that it isn't the right list, if you want to discuss software patents in Europe, I think the discussion mailinglist of the FSFE is a good place. But the outcome of the discussions about software patents there is already that they are all bad etc. ;-) Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED] pgpTuzkfcvxt3.pgp Description: PGP signature
Re: Crypto++ licencing
On Fri, Apr 19, 2002 at 06:34:30PM -0700, Stephen Zander wrote: Walter == Walter Landry [EMAIL PROTECTED] writes: Walter DSS and IDEA are both patented in Europe, so putting it in Walter non-us won't help. There is also the minor problem that Walter non-us is going the away. I personally don't believe non-US is going away until the entire world suports software patents. I hope you mean when the US doesn't support software pantents anymore here. Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED] pgpPfZ2Awg4HN.pgp Description: PGP signature
Re: Crypto++ licencing
On Fri, Apr 19, 2002 at 06:06:59PM -0700, Walter Landry wrote: Stephen Zander [EMAIL PROTECTED] wrote: Walter == Walter Landry [EMAIL PROTECTED] writes: Walter The patent issue is not a problem specific to the license. Walter Rather, it depends on what algorithms are implemented. Walter What algorithms are used? A usual suspect is IDEA, which Walter is patented in many countries. According to URL:http://www.eskimo.com/~weidai/algorithms.html, the potentially patented algorithms are: * DSS * LUC * IDEA DSS and IDEA are both patented in Europe, so putting it in non-us won't help. If I'm right, patents on software aren't legal in Europe. Current European law (European Patent Convention article 52) says you can't patent programs for computers. The problem is the EPO (European Patent Office) does not obey that law. They exists however, and nobody knows how threating they are until you come back from court. There is also the minor problem that non-us is going the away. This won't happen, non-US has more than crypto. It sounds like the patent holders are charging to use DSS. Since it isn't very good anyway, I would recommend just removing it. IDEA, on the other hand, is a good algorithm, but only free for non-commercial uses. You could split that out and put that library in non-free. The rest goes in main. Speak-freely is in non-free for the same reason. I don't see why it fails the DFSG. Patens are only legal in the US, why can't it go into non-US/main? Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED] pgpDiDpBPOmlF.pgp Description: PGP signature
Re: Crypto++ licencing
On Sun, Apr 21, 2002 at 12:52:53AM +0200, Arnoud Galactus Engelfriet wrote: Jeroen Dekkers wrote: On Fri, Apr 19, 2002 at 06:06:59PM -0700, Walter Landry wrote: DSS and IDEA are both patented in Europe, so putting it in non-us won't help. If I'm right, patents on software aren't legal in Europe. Current That's not entirely accurate. First of all, there is no uniform European patent law. Every European country has its own national patent law, and has its own interpretations and case law regarding software-related inventions. Second, Europe in this case should be read as member states to the European patent convention or as countries in the continent of Europe. The EC has yet to regulate patent law in this regard. The upcoming directive will establish a common law - explicitly legalizing the current EPO's interpretation of article 52 EPC. I meant members of the Europen Union. Not all I hope the upcoming directive will be stopped, at least France is against software patents. It sounds like the patent holders are charging to use DSS. Since it isn't very good anyway, I would recommend just removing it. IDEA, on the other hand, is a good algorithm, but only free for non-commercial uses. You could split that out and put that library in non-free. The rest goes in main. Speak-freely is in non-free for the same reason. I don't see why it fails the DFSG. Patens are only legal in the US, why can't it go into non-US/main? IDEA is also covered by a European patent (since it was invented by a Swiss company). It's even worse as I thought. :((( Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED] pgpM6xJclaNRQ.pgp Description: PGP signature
Re: Crypto++ licencing
On Sat, Apr 20, 2002 at 07:18:15PM -0700, Stephen Zander wrote: Jeroen == Jeroen Dekkers [EMAIL PROTECTED] writes: Jeroen I hope you mean when the US doesn't support software Jeroen pantents anymore here. No, I meant what I said. While at least one country in the world refuses to recognise software patents, there will be a safe place for that which we currently call non-US to exist (the fact that it's currently called non-US rather than non-encumbered or something else is irrelevant to me). If every nation in the world supports software patents, then Debian will no longer be able to package potentially patent infringing code because it will be illegal to do so everywhere (yes, that last staement is a tautology). I don't believe the US will ever stop supporting softare patents; there's too much money at stake. I don't believe the rest of the world will ever support software patents. Probably the European directive can already be stopped. Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED] pgpEIX4fpNsfl.pgp Description: PGP signature
Re: distributable but non-free documents
On Tue, Mar 05, 2002 at 07:41:51PM +0100, Marcus Brinkmann wrote: I would like to do the same with C99, POSIX, and other standards. I agree. I've whished more than once that I could just do C-h i m posix. And I also agree that those standards should be free. But when is it free? :) You don't really want to drag me into a discussion about what freedom means for software and related technical, generally useful documentation? I never thought that discussion with you were unpleasant. But I don't the rest of Debian wants such a discussion. :) To quote the RFC copyright notice from RFC 2026 Internet Standards Process: This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English This license is really horrible. It is neither precise nor consistent. It is definitely non-free. For example, I am not allowed to work in parts of it into a game documentation that does not implement, explain or comment on the standard. Although it is a honest attempt at doing the right thing, it is too restrictive, as it does only foresee some of the possible uses of the text, and not all. It is in so far unusable even for the areas where it does allow usage of parts of the text and creating derivative works, as it is incompatible with the GPL and the GFDL, so it is unusable for GNU projects documentation and source code (comments!) except for reference or quoting (fair use). I agree, but at least they attempt to do the right thing. Now only somebody should tell them what the right thing is and they might do that. :) I agree with you that POSIX is non-free (and that should change!), but the original dicussion was about the RFC copyright. I still don't see how this license really restricts the user, the things you were talking are allowed. Enlighten me if I'm wrong. It restricts you in a similar way as a license for Mozilla would restrict you if it would say: You are only allowed to reuse part of this source code if you implement software directly related to the world wide web. You can probably always try to stretch the definition to include whatever you want. But that doesn't change that it is horrible in the first place. True, including the thing you don't want for good reasons is better IMHO. (Think about linking with proprietary software, relicensing, etc) The problem is that the Debian Free Documentation Guidelines don't exist and that documentation is really different from software. It is? Well, I clearly see the difference between a computer program and a book, but I don't think that the differences are in a way that matters to the DFSG. The problem is that the DFSG talks about programs, source code, that is should not contaminate other software, etc. The idea behind the DFSG doesn't differ for books, but the current implementation does only talk about software. Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED] pgpbHor83yG7W.pgp Description: PGP signature
Re: distributable but non-free documents
On Tue, Mar 05, 2002 at 07:02:15PM +0100, Henning Makholm wrote: To quote the RFC copyright notice from RFC 2026 Internet Standards Process: Just for the record, I don't think RFC 2026 is technical documentation. It documents a social process, not a technical one. But the same copyright notice is found in newer technical RFCs. It documents the process of how to make an RFC. It also says which copyright all RFCs should have, that was why I was referring to it. the original dicussion was about the RFC copyright. I still don't see how this license really restricts the user, the things you were talking are allowed. Enlighten me if I'm wrong. It says that modification is not allowed except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed. That means that if I and a group of like-minded people want to experiment with an email transport system where the mail agents demand micropayments prior to accepting a mail for delivery (to effectively eliminate spamming), we are not allowed to document our experimental special-purpose delivery protocol simply by distributing a document based on the text from RFC 2821, but with appropriate changes - unless we decide to wait and put up with whatever bureaucracy the Internet Standards process entails. Of course, we will be allowed to distribute a document that describes the *differences* between SMTP and our new protocol, which in a sense is akin to distributing software changes as patches. That means that *perhaps*, by analogy, we should consider the RFC's free - but the patch clause in the DFSG was always a compromise, and I don't think it will do anybody any good to extend it to documentation, now that the trend seems to be towards a stricter application of the DFSG to software that we've had some years ago. I think you're right. I don't know what reasons the IETF has for the copyright policy, maybe we should move the discussion to them. I guess that they just want to be sure that nobody makes small changes to an RFC and distribute it as the official document. I agree that such things should not be allowed. However, I am convinced that it's useful to allow modification and redistribution of the documents. When I look at the way the RFCs are developed, it should be possible to convince them to make the RFCs free. But I don't have enough time to do that. Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED] pgpkD2DGbnubw.pgp Description: PGP signature
Re: distributable but non-free documents
On Tue, Mar 05, 2002 at 12:57:40AM +0100, Marcus Brinkmann wrote: On Mon, Mar 04, 2002 at 11:31:58PM +0100, Jeroen Dekkers wrote: However, I don't see why that should give much problems. You don't want to change to standards anyhow. I would. For example, I would take some of the RFC's, cp from them, add texinfo markup and include bits of them in documentation of GNU software. IANAL, I don't know if adding texinfo markup to them is considered making a derivative work or just distributing, you don't change the text itself. Adding texinfo markup just changes how the text is displayed, which is already different if you read it with less, emacs, mozilla or just use a printer to make a hardcopy. I would like to do the same with C99, POSIX, and other standards. I agree. I've whished more than once that I could just do C-h i m posix. And I also agree that those standards should be free. But when is it free? :) I can't. When I find a bug in the glibc manual, and read up POSIX to find out what it should be, I have to close my eyes for a minute and try to forget what I just read before writing a bug report. It would be easier to move the mouse, cp the missing sentence and paste it into the glibc manual. But I am not allowed to do that, by copyright. To quote the RFC copyright notice from RFC 2026 Internet Standards Process: This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English I think the glibc manual is a derivative work that comment on or otherwise explain it or assist in its implementation (Note that RFC 2026 has a typo :-)). If adding textinfo markup is considered a derivative work, then it's allowed under this license if I'm right, but IANAL. I agree with you that POSIX is non-free (and that should change!), but the original dicussion was about the RFC copyright. I still don't see how this license really restricts the user, the things you were talking are allowed. Enlighten me if I'm wrong. The problem is that the Debian Free Documentation Guidelines don't exist and that documentation is really different from software. But other than that, I don't see how it restricts the user. Just because you don't see it, it doesn't mean that it isn't there (many politicians probably don't see how software patents restrict free software developers either ;) I think they will probably see that it restrict free software developers if you tell them. The problem is that they should also care about that (and probably know about free software in the first place!). Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED] pgpKxLlG6MPNf.pgp Description: PGP signature
Re: distributable but non-free documents
On Mon, Mar 04, 2002 at 04:22:10PM -0500, Branden Robinson wrote: No, I am an unimpressed with the argument that standards documents must be regarded as sacred, unalterable texts, lest the universe collapse into primeval chaos. However, I don't see why that should give much problems. You don't want to change to standards anyhow. Changing the document to develop internet standards is allowed. Translating is allowed. I'm not sure chaning the format is allowed, but that would be useful too. But other than that, I don't see how it restricts the user. And probably I forget if the case that is useful to be able to modify the document. If there is such a case that would change my opinion, but I don't see it at the moment. Jeroen Dekkers -- Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] Debian GNU supporter - http://www.debian.org http://www.gnu.org IRC: [EMAIL PROTECTED] pgpziONRpbMnB.pgp Description: PGP signature
