Re: Comments regarding tegaki-zinnia-japanese_0.1-1_amd64.changes
On Tue, May 26, 2009 at 21:34, Mathieu Blondel math...@mblondel.org wrote: Hi, What is the best mailing-list on Debian to discuss legal questions? I'm still confused about a few things so I would like to expose the nature of the problem more precisely and take this as an opportunity to ask the opinion of more people. debian-legal@lists.debian.org -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#522311: qbittorrent: Linked with OpenSSL, seems to be a GPL violation
On Sat, Apr 4, 2009 at 17:43, Cristian Greco cristian.deb...@gmail.com wrote: On Sat, Apr 04, 2009 at 12:00:56PM +0800, LI Daobing wrote: On Sat, Apr 4, 2009 at 05:06, Cristian Greco cristian.deb...@gmail.com wrote: [ CCing debian-legal for comments ] On Fri, Apr 03, 2009 at 10:37:49PM +0300, Adrian Bunk wrote: The libcurl case might be easy to resolve, but I don't know anything about the libtorrent-rasterbar. It might be required that you get all copyright holders to agree on a licence exception. The point is that qbittorrent doesn't directly link against libssl and the source code doesn't really use that library. Is it really necessary to add the exception? I'm not sure if the executable linking is caused by libtorrent-rasterbar (BSD code linked against libssl) or some other required libraries/headers. In the former case, if linking is caused by the torrent library, all of its clients should add such exception. My thought is that qbittorrent shouldn't be affected by this problem because it doesn't really link against libssl. And BTW, the source code includes licenses such as LGPL, BSD and MIT, so it shouldn't need the exception anyway. I think it need an exception. GPL licensed code and OpenSSL licensed code should not run in the same process. I can confirm that linking against libssl is caused by libtorrent-rasterbar, which is compiled with encryption support and causes inclusion of some OpenSSL headers. I'm wondering: 1) What to do in this case? Should all clients based on libtorrent-rasterbar and licensed under the GPL add an exception even if they don't directly use the OpenSSL library? libtorrent-rasterbar should provide two packages, one is libtorrent-rasterbar-openssl (with openssl enabled), another is libtorrent-rasterbar (with openssl disabled), just like libcurl3 and libcurl3-gnutls. 2) Why doesn't lintian complain about the exception if the source code contains GPL + another different license (this is the case with qbittorrent)? I don't know. -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#522311: qbittorrent: Linked with OpenSSL, seems to be a GPL violation
On Sat, Apr 4, 2009 at 22:25, Cristian Greco cristian.deb...@gmail.com wrote: On Sat, Apr 4, 2009 at 17:43, Cristian Greco cristian.deb...@gmail.com wrote: 1) What to do in this case? Should all clients based on libtorrent-rasterbar and licensed under the GPL add an exception even if they don't directly use the OpenSSL library? libtorrent-rasterbar should provide two packages, one is libtorrent-rasterbar-openssl (with openssl enabled), another is libtorrent-rasterbar (with openssl disabled), just like libcurl3 and libcurl3-gnutls. This is not what I was looking for (and this solution wouldn't be useful, as all existing clients actually require encryption to be enabled). My question is if it is really needed for all clients licensed under the GPL to add an exception even if they don't directly use the OpenSSL library. This could be a problem, eventually. yes, it is really needed, if you want to run OpenSSL and GPL code in the same process. -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#522311: qbittorrent: Linked with OpenSSL, seems to be a GPL violation
On Sat, Apr 4, 2009 at 05:06, Cristian Greco cristian.deb...@gmail.com wrote: [ CCing debian-legal for comments ] On Fri, Apr 03, 2009 at 10:37:49PM +0300, Adrian Bunk wrote: On Fri, Apr 03, 2009 at 01:35:30AM +0200, Cristian Greco wrote: On Thu, Apr 02, 2009 at 08:27:19PM +0300, Adrian Bunk wrote: $ ldd /usr/bin/qbittorrent | grep ssl libssl.so.0.9.8 = /usr/lib/libssl.so.0.9.8 (0x7fd73085a000) $ /usr/share/doc/qbittorrent/copyright states that much of the code is GPL-licenced. I didn't find any statement that all copyright holders of GPL'ed code in tracker have given extra permission to link with OpenSSL. See also question 28 at http://people.debian.org/~bap/dfsg-faq Hi Adrian, first of all thanks for your report. qbittorrent does not use directly the OpenSSL library, as you can see looking at the source code and the symbols table of the (unstripped) executable file. It is linked against two libraries using libssl (libtorrent-rasterbar and libcurl), and there are some symbols from boost::asio related to 'ssl'. And by the way, even if the majority of the C++ code in qbittorrent is released under the GPL, the debian/copyright file includes a mix of files with different licenses (LGPL, BSD, MIT), so that lintian does not complain about linking against libssl. Any suggestion? The libcurl case might be easy to resolve, but I don't know anything about the libtorrent-rasterbar. It might be required that you get all copyright holders to agree on a licence exception. The point is that qbittorrent doesn't directly link against libssl and the source code doesn't really use that library. Is it really necessary to add the exception? I'm not sure if the executable linking is caused by libtorrent-rasterbar (BSD code linked against libssl) or some other required libraries/headers. In the former case, if linking is caused by the torrent library, all of its clients should add such exception. My thought is that qbittorrent shouldn't be affected by this problem because it doesn't really link against libssl. And BTW, the source code includes licenses such as LGPL, BSD and MIT, so it shouldn't need the exception anyway. I think it need an exception. GPL licensed code and OpenSSL licensed code should not run in the same process. -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-legal-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Doxygen Documentation from LGPL source under CC-BY-SA-2.5
Hello, On Tue, Jun 10, 2008 at 4:31 AM, Andres Mejia [EMAIL PROTECTED] wrote: Hello, I know the CC-BY-SA-2.5 license is considered non-free. The api documentation in the ogre-doc package is under this license. Suppose upstream decided to use CC-BY-SA-3.0 instead. Would this still be allowed if the documentation is generated from LGPL source files? I think you can regenerate it again, so it can be under LGPL license -- Best Regards, LI Daobing -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
please help check fqterm's license
Hello, fqterm is a BBS client program, I want to package it and I want to know whether its license is proper. fqterm is linked with openssl, and it's license is GPLv2 with an openssl exception, you can download it by [1] [1] svn checkout http://fqterm.googlecode.com/svn/trunk 1. whether the license is proper? [2] http://code.google.com/p/fqterm/source/browse/trunk/LICENSE?r=549 2. many files have a GPL-2+ header, should all of them be changed, or only the files include openssl header should be changed? any template for the new header? an example file in [3] [3] http://code.google.com/p/fqterm/source/browse/trunk/src/fqterm/fqterm_frame.cpp?r=549 3. fqterm currently depends on following libraries: libc6 (= 2.7-1), libfontconfig1 (= 2.4.0), libfreetype6 (= 2.3.5), libgcc1 (= 1:4.1.1-21), libglib2.0-0 (= 2.12.0), libice6 (= 1:1.0.0), libpng12-0 (= 1.2.13-4), libqt4-network (= 4.4.0), libqt4-script (= 4.4.0), libqtcore4 (= 4.4.0), libqtgui4 (= 4.4.0), libsm6, libssl0.9.8 (= 0.9.8f-5), libstdc++6 (= 4.1.1-21), libx11-6, libxext6, libxi6, libxrandr2 (= 2:1.2.0), libxrender1, zlib1g (= 1:1.1.4), I think all of them fulfill the license (GPL with openssl exception), am I corret? Thanks. -- Best Regards, LI Daobing -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
license issuse in qterm
Hello, I am the maintainer of qterm and I am checking the license issue in qterm. qterm is release under GPL-2+ as a whole, and the source files are released under GPL-2+, LGPL-2.1+, BSD-2 and others. qterm/ssh/getput.h is released under following license[1]. And I don't know whether it's OK to distribute it as GPL-2+, or whether it fulfill DFSG, thanks. [1] $ cat qterm/ssh/getput.h | head -15 /* $OpenBSD: getput.h,v 1.8 2002/03/04 17:27:39 stevesk Exp $ */ /* * Author: Tatu Ylonen [EMAIL PROTECTED] * Copyright (c) 1995 Tatu Ylonen [EMAIL PROTECTED], Espoo, Finland *All rights reserved * Macros for storing and retrieving data in msb first and lsb first order. * * As far as I am concerned, the code I have written for this software * can be used freely for any purpose. Any derived versions of this * software must be clearly marked as such, and if the derived work is * incompatible with the protocol description in the RFC file, it must be * called by a name other than ssh or Secure Shell. */ -- Best Regards, LI Daobing -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
