Re: Bacula and OpenSSL
Le dimanche 30 septembre 2007 à 20:24 +0200, Kern Sibbald a écrit : However, the concept of deleting parts of the license don't appeal to me. I prefer the following which is a modification of my prior license that was accepted by Debian. The modification makes my prior license a bit more specific -- i.e. it restricts it to OSI licensed libraries. Well, any exception that you add to the GPL can be removed, this is by design of the GPL. This is also true of the other wording you suggested. It isn't really important, but I'd be surprised if that is true as it the author of the code can decide anything he/she wants by modifying the GPL. Yes, it is possible, but in this case I don't think the resulting license is compatible with the GPL; if these new terms must me supplemented for all derived versions, that makes them further restrictions. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bacula and OpenSSL
On Wednesday 26 September 2007 16:03, MJ Ray wrote: Shane Martin Coughlan [EMAIL PROTECTED] wrote: Kern Sibbald wrote: Exception to the GPL: Linking: Bacula may be linked and distributed with any libraries permitted=20 under the GPL, or with any non-GPLed libraries, including OpenSSL, that= are required for its proper functioning, providing the license and hence so= urce=20 code of those non-GPLed libraries comply with the Open Source Definitio= n as=20 defined by the Open Source Initiative (www.opensource.org). That seems like a copyleft-busting hole you can drive a truck through. I'd strongly suggest using the GNU-wget-style exception cited below. I'm not really too interested in copyleft. I was originally going to Bacula in the public domain, but chose the GPL primarily because I believed at the time that people who made changes were obligated to give them back to the project. As it turns out this is not at all the case, apparently only the people to whom you directly give the code have the right to the source code changes. Regards, Kern Original: http://packages.debian.org/changelogs/pool/main/w/wget/wget_1.10.2-2/wget.c opyright (This seems not to be mentioned in the Wget manual online just now.) The list of licences accepted by OSI as Open Source is more or less the same as the list of licences accepted by the FSF as Free Software. That's simply not true today. FSF have rejected one that OSI approved, and FSF's list reflects real hacker enquiries, while OSI's list reflects mainly which licences have lawyer-advocates. For differences, see the survey at http://www.asheesh.org/note/software/osi-vs-fsf.html Tip: http://freeculture.org/pipermail/discuss/2007-September/001570.html [...] In addition, as a special exception, the Bacula Project gives permission to link the code of its release of Bacula with the OpenSSL project's OpenSSL library (or with modified versions of it that use the same license as the OpenSSL library), and distribute the linked executables. You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify this file, you may extend this exception to your version of the file, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. Seems good to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
On Tuesday 25 September 2007 23:22, Josselin Mouette wrote: Le mardi 25 septembre 2007 à 15:14 +0200, Kern Sibbald a écrit : Thanks for looking up the above -- very interesting. However, the concept of deleting parts of the license don't appeal to me. I prefer the following which is a modification of my prior license that was accepted by Debian. The modification makes my prior license a bit more specific -- i.e. it restricts it to OSI licensed libraries. Well, any exception that you add to the GPL can be removed, this is by design of the GPL. This is also true of the other wording you suggested. It isn't really important, but I'd be surprised if that is true as it the author of the code can decide anything he/she wants by modifying the GPL. Cheers,
Re: Bacula and OpenSSL
On Tuesday 25 September 2007 17:43, Shane Martin Coughlan wrote: Hi Kern Kern Sibbald wrote: = Exception to the GPL: Linking: Bacula may be linked and distributed with any libraries permitted under the GPL, or with any non-GPLed libraries, including OpenSSL, that are required for its proper functioning, providing the license and hence source code of those non-GPLed libraries comply with the Open Source Definition as defined by the Open Source Initiative (www.opensource.org). === The list of licences accepted by OSI as Open Source is more or less the same as the list of licences accepted by the FSF as Free Software. Both include quite a few licences that are not compatible with each other (in much the same way as OpenSSL was not compatible with the GNU GPL). By allowing people to link to all of them, potential problems could arise. I'd suggest a slightly more conservative approach of explicitly granting an OpenSSL exception and - if necessary in the future - to grant other exceptions explicitly too. That way unforeseen problems can be avoided (like someone linking OpenSSL to GPLv2 to Apache to CDDL via Bacula, and third party copyright holders getting annoyed). There is a precedent for this in the language used in GNU WGET, which does have a special exception for linking to OpenSSL. I made a version of it below that refers to Bacula. = In addition, as a special exception, the Bacula Project gives permission to link the code of its release of Bacula with the OpenSSL project's OpenSSL library (or with modified versions of it that use the same license as the OpenSSL library), and distribute the linked executables. You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify this file, you may extend this exception to your version of the file, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. = Note that the final two lines are intended to allow the code to be recombined with vanilla (no exception) GPL code later. This would apply if someone made a derived work without needing OpenSSL but needing to include someone else's GNU GPL code. I hope this is useful. Yes, very much so. Thanks particularly for the explanation of the final two lines which were not really clear to me. After having thought about it, I will go with the above, since it accomplishes what I want in the most conservative way -- though I will have to modify it, because unlike most Open Source projects, Bacula uses a single LICENSE file for describing the license details rather than adding them to each file. Before making the final changes, I want to read the Software Freedom Law Center's guidelines on this subject one or two more times, then I will modify the file headers and the LICENSE file and send them to you for final review. By the way, so that there is no confusion, I am planning to number the first release with this licensing change as version 3.0.0. The GPL license exception will be in the trunk long before 3.0.0 is released, but there will probably be at least one or more release of version 2.2.x under the pure GPLv2 OpenSSL incompatible license before 3.0.0 is ready. Best regards, Kern PS: thanks to the others who made comments. Though I may share the same views, those comments helped me see the situation clearer and reach a decision. Regards Shane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Shane Martin Coughlan [EMAIL PROTECTED] wrote: Kern Sibbald wrote: Exception to the GPL: Linking: Bacula may be linked and distributed with any libraries permitted=20 under the GPL, or with any non-GPLed libraries, including OpenSSL, that= are required for its proper functioning, providing the license and hence so= urce=20 code of those non-GPLed libraries comply with the Open Source Definitio= n as=20 defined by the Open Source Initiative (www.opensource.org). That seems like a copyleft-busting hole you can drive a truck through. I'd strongly suggest using the GNU-wget-style exception cited below. Original: http://packages.debian.org/changelogs/pool/main/w/wget/wget_1.10.2-2/wget.copyright (This seems not to be mentioned in the Wget manual online just now.) The list of licences accepted by OSI as Open Source is more or less the same as the list of licences accepted by the FSF as Free Software. That's simply not true today. FSF have rejected one that OSI approved, and FSF's list reflects real hacker enquiries, while OSI's list reflects mainly which licences have lawyer-advocates. For differences, see the survey at http://www.asheesh.org/note/software/osi-vs-fsf.html Tip: http://freeculture.org/pipermail/discuss/2007-September/001570.html [...] In addition, as a special exception, the Bacula Project gives permission to link the code of its release of Bacula with the OpenSSL project's OpenSSL library (or with modified versions of it that use the same license as the OpenSSL library), and distribute the linked executables. You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify this file, you may extend this exception to your version of the file, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. Seems good to me. -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Hello Shane, On Monday 24 September 2007 18:08, Shane Martin Coughlan wrote: Hi Kern Kern Sibbald wrote: As far as I can see, the project has the following ways to proceed: 1. Add a modification to our existing license that permits linking with OpenSSL. I think this is the simplest clause, and it keeps well within the precedent already accepted by the Bacula developers. I saw that there is an OpenSSL exception already proposed by the Debian-legal list: In addition, as a special exception, the copyright holders give permission to link the code of portions of this program with the OpenSSL library under certain conditions as described in each individual source file, and distribute linked combinations including the two. You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify file(s) with this exception, you may extend this exception to your version of the file(s), but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. If you delete this exception statement from all source files in the program, then also delete it here. http://lists.debian.org/debian-legal/2004/05/msg00595.html This seems like a quick and neat solution. Thanks for looking up the above -- very interesting. However, the concept of deleting parts of the license don't appeal to me. I prefer the following which is a modification of my prior license that was accepted by Debian. The modification makes my prior license a bit more specific -- i.e. it restricts it to OSI licensed libraries. = Exception to the GPL: Linking: Bacula may be linked and distributed with any libraries permitted under the GPL, or with any non-GPLed libraries, including OpenSSL, that are required for its proper functioning, providing the license and hence source code of those non-GPLed libraries comply with the Open Source Definition as defined by the Open Source Initiative (www.opensource.org). === I think this is much clearer than my original license, no less restrictive, avoids allowing someone to modify the license, but is a bit broader than the OpenSSL exception listed above, but corresponds to what I believed the GPL permitted when I originally chose the license for releasing the code. Does anyone have any objections to this? Regards, Kern Debian guys, anything to add? Regards Shane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Kern Sibbald [EMAIL PROTECTED] writes: = Exception to the GPL: Linking: Bacula may be linked and distributed with any libraries permitted under the GPL, or with any non-GPLed libraries, including OpenSSL, that are required for its proper functioning, providing the license and hence source code of those non-GPLed libraries comply with the Open Source Definition as defined by the Open Source Initiative (www.opensource.org). === I think this is much clearer than my original license I see several areas that are unclear. any libraries permitted under the GPL — the GPL doesn't permit libraries, the GPL permits actions normally reserved under copyright law. As for which license terms the GPL allows for distributed derived works, that's the terms of this license i.e. the GPL itself. or with any non-GPLed libraries ... that are required for its proper functioning — anyone could modify the work so that it depends on some library and then claim that library is required for its proper functioning, so this clause is effectively null. the Open Source Definition as defined by the Open Source Initiative — at what point in time? At the time this clause was written? At the time I received the work? At any time someone reads this text? It's far clearer to simply give the exact set of extra terms you consider acceptable, rather than delegating it to a website subject to change after you write this clause. avoids allowing someone to modify the license All they need to do is convince the OSI to certify their license terms (which is far from a guarantee the license terms are free), and then those license terms are retroactively allowed under this clause. but is a bit broader than the OpenSSL exception listed above I'd argue, based on the above, it's rather overbroad. but corresponds to what I believed the GPL permitted when I originally chose the license for releasing the code. I don't see how you draw this conclusion. The GPL makes clear what terms are permitted for derived works: the terms of this license. -- \The World is not dangerous because of those who do harm but | `\ because of those who look at it without doing anything. | _o__) —Albert Einstein | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Hi Kern Kern Sibbald wrote: = Exception to the GPL: Linking: Bacula may be linked and distributed with any libraries permitted under the GPL, or with any non-GPLed libraries, including OpenSSL, that are required for its proper functioning, providing the license and hence source code of those non-GPLed libraries comply with the Open Source Definition as defined by the Open Source Initiative (www.opensource.org). === The list of licences accepted by OSI as Open Source is more or less the same as the list of licences accepted by the FSF as Free Software. Both include quite a few licences that are not compatible with each other (in much the same way as OpenSSL was not compatible with the GNU GPL). By allowing people to link to all of them, potential problems could arise. I'd suggest a slightly more conservative approach of explicitly granting an OpenSSL exception and - if necessary in the future - to grant other exceptions explicitly too. That way unforeseen problems can be avoided (like someone linking OpenSSL to GPLv2 to Apache to CDDL via Bacula, and third party copyright holders getting annoyed). There is a precedent for this in the language used in GNU WGET, which does have a special exception for linking to OpenSSL. I made a version of it below that refers to Bacula. = In addition, as a special exception, the Bacula Project gives permission to link the code of its release of Bacula with the OpenSSL project's OpenSSL library (or with modified versions of it that use the same license as the OpenSSL library), and distribute the linked executables. You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify this file, you may extend this exception to your version of the file, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. = Note that the final two lines are intended to allow the code to be recombined with vanilla (no exception) GPL code later. This would apply if someone made a derived work without needing OpenSSL but needing to include someone else's GNU GPL code. I hope this is useful. Regards Shane -- Shane Coughlan FTF Coordinator Free Software Foundation Europe Office: +41435000366 ext 408 / Mobile: +41792633406 [EMAIL PROTECTED] Support Free Software http://fsfe.org signature.asc Description: OpenPGP digital signature
Re: Bacula and OpenSSL
Le mardi 25 septembre 2007 à 15:14 +0200, Kern Sibbald a écrit : Thanks for looking up the above -- very interesting. However, the concept of deleting parts of the license don't appeal to me. I prefer the following which is a modification of my prior license that was accepted by Debian. The modification makes my prior license a bit more specific -- i.e. it restricts it to OSI licensed libraries. Well, any exception that you add to the GPL can be removed, this is by design of the GPL. This is also true of the other wording you suggested. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bacula and OpenSSL
Hello, To follow up on this: as of 5 September, Bacula source code is free of third party copyrighted code that is GPLed. Doing so, did unfortunately create a good deal of instability, which we are dealing with. However, for the future (probably version 3.0.0), we will be able to use OpenSSL code without any license infringements. As far as I can see, the project has the following ways to proceed: 1. Add a modification to our existing license that permits linking with OpenSSL. 2. Add a modification to our existing license that permits linking with any OSI software. 3. Dual licensing Bacula with GPLv2 and some other license that permits linking with OpenSSL. 4. Switching from GPLv2 to some other license that permits linking with OpenSSL. I would be interested in your opinions on which way we should go, and if anyone has any suggestions for the wording for item #1 above, it certainly seems to me to be the minimalist way of proceeding for at least the moment. The old text that I had some time ago, which probably goes under possibility #2 was: Linking: Bacula may be linked with any libraries permitted under the GPL, or with any non-GPLed libraries, including OpenSSL, that are required for its proper functioning, providing the source code of those non-GPLed libraries is non-proprietary and freely available to the public. Best regards, Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Hi Kern Kern Sibbald wrote: As far as I can see, the project has the following ways to proceed: 1. Add a modification to our existing license that permits linking with OpenSSL. I think this is the simplest clause, and it keeps well within the precedent already accepted by the Bacula developers. I saw that there is an OpenSSL exception already proposed by the Debian-legal list: In addition, as a special exception, the copyright holders give permission to link the code of portions of this program with the OpenSSL library under certain conditions as described in each individual source file, and distribute linked combinations including the two. You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify file(s) with this exception, you may extend this exception to your version of the file(s), but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. If you delete this exception statement from all source files in the program, then also delete it here. http://lists.debian.org/debian-legal/2004/05/msg00595.html This seems like a quick and neat solution. Debian guys, anything to add? Regards Shane -- Shane Coughlan FTF Coordinator Free Software Foundation Europe Office: +41435000366 ext 408 / Mobile: +41792633406 [EMAIL PROTECTED] Support Free Software http://fsfe.org signature.asc Description: OpenPGP digital signature
Re: Bacula and OpenSSL
This one time, at band camp, Shane Martin Coughlan said: Hi Kern Kern Sibbald wrote: As far as I can see, the project has the following ways to proceed: 1. Add a modification to our existing license that permits linking with OpenSSL. I think this is the simplest clause, and it keeps well within the precedent already accepted by the Bacula developers. I saw that there is an OpenSSL exception already proposed by the Debian-legal list: In addition, as a special exception, the copyright holders give permission to link the code of portions of this program with the OpenSSL library under certain conditions as described in each individual source file, and distribute linked combinations including the two. You must obey the GNU General Public License in all respects for all of the code used other than OpenSSL. If you modify file(s) with this exception, you may extend this exception to your version of the file(s), but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version. If you delete this exception statement from all source files in the program, then also delete it here. http://lists.debian.org/debian-legal/2004/05/msg00595.html This seems like a quick and neat solution. Debian guys, anything to add? It looks fine to me. It might be simplest to get rid of the 'under certain conditions as described in each individual source file' subclause, as that could become tedious to maintain. Take care, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bacula and OpenSSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Michael, Anthony I just wanted to let you know that I have forwarded your comments and feedback regarding GPLv3, OpenSSL and System Libraries to Brett Smith, licence engineer at FSF. :) Regards Shane - -- Shane Coughlan FTF Coordinator Free Software Foundation Europe Office: +41435000366 ext 408 / Mobile: +41792633406 [EMAIL PROTECTED] Support Free Software http://fsfe.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQCVAwUBRq26DNGa7CzA5hXyAQKc7gP8C9eBbRSOW4jdne9Qpzx3cfFi9WKEDqf8 IgUXvktnSEdSbKV2pfEVD5Y3YaVUkZfnXqTbqrpdB4qykoh2uODgS8eBiRgX2Lf3 8dxLVbjim/SdBeeLdGexd8R/4SwZGFPiNUE8CEkqGHFsCSCuxoxPjl+U9Ki7S1ia lJVzpjUOkqQ= =cUyh -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
On Wed, Jul 25, 2007 at 03:12:33PM +1000, Anthony Towns wrote: In particular, going by the GPLv3: ] The System Libraries of an executable work [...] So I've done the here's what the license says, let's parse it to see if we can extract any meaning thing, but I haven't done it the other way -- here's what's intended, let's see if that fits the case we're considering, and if that helps understand the wording. (Well, to be fair, I haven't seen a very clear statement of what the FSF intends by the clause -- beyond minimal changes to the GPLv2 to make OpenSolaris okay anyway) I figure the exception is to allow people to write GPL programs on non-GPL operating systems and use the standard OS features and compilers/interpretors without having to worry. _But_ that exception needs to be limited, so that when you add features to a GPLed program that would otherwise have to be freed, you can't avoid freeing them by carefully packaging and making use of some loophole in the exception. Some characteristics of legitimate uses of that exception seem to me to be: (1) they're readily available features that come standard with the system (whether that be operating system, windowing system, programming language, etc) (2) they're not designed specifically for the program being used (3) they're independent of the program being used (4) they're used by standard components of the system, other than your program (5) they're used by other programs than the ones included with the system and that are unrelated to your program (6) they implement standard interfaces, with altnerate implementations that you could rebuild your program against without much bother (7) they implement standard interfaces, with source or docs available, so you could create your own implementation and build your program against that (8) the implementation is widely available and is easily and practicably obtained by anyone, either commercially or freely So writing GPLed apps that use Solaris features like dtrace or similar seem reasonable, in that dtrace hits (1)-(5), and (7) and (8); and GPLed programs that use the Windows API hit (1)-(5) and (8), though probably not (6) or (7), and programs that use non-free .NET or Java APIs probably hit (1)-(8). Having the test be something like: (1) and (2) and (3) and ( (4) or (5) ) and ( (6) or (7) or (8) ) seems to allow the things we want, and restrict the things we don't -- eg, trying to implement an add-on to GCC or emacs would fail (2) and (3), even if specially packaged so they met (1), (4), (5) and (8), eg. The above could be applied to writing GPLed software that used libraries with special proprietary packages like Mathematica or similar too; YMMV. To be a bit more concrete; say you have some GPLv3 code -- an implementation of an interesting peer-to-peer IM protocol, say. Then: - if you're running Vista or OS X, you can integrate it into the environment, add a native GUI and add new features that will be a pain to port back to a free OS because they use libraries that haven't been reimplemented elsewhere yet; then send it to Apple or Microsoft and have it be included as a standard part of the OS. - if you're running Debian, you have openssl as a standard component, but you can't add openssl support to your p2p IM app without making use of the system library exception and can't distribute it in Debian. So if Debian wants to have the same features as the new versions of Vista or OS X do, we can't just use our existing libraries and the GPL app as Microsoft and Apple did, we either have to reimplement the app with an OpenSSL friendly license, or reimplement OpenSSL. That is: it's easier for non-free OSes to incorporate GPLed code than for free OSes. Maybe that is the result of the way the GPLv3's been drafted, and maybe it actually has to be that way for some reason -- but is there really any question that the above's a bad outcome? If we can agree it is a bad outcome, it seems worth exploring other interpretations of the new System Library exception to see if we can avoid them. Cheers, aj signature.asc Description: Digital signature
Re: Bacula and OpenSSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 RE: The FSF position regarding OpenSSL as a system library in Debian. === We do not believe that OpenSSL qualifies as a System Library in Debian. The System Library definition is meant to be read narrowly, including only code that accompanies genuinely fundamental components of the system. I don't see anything to suggest that that's the case for OpenSSL in Debian: the package only has important priority (as opposed to glibc's required), there are only about 350 packages depending on it (as opposed to glibc's 8500), and it isn't installed on a base system. To put it plainly, if OpenSSL actually were a System Library, I would expect it to look more like one. -- Brett Smith Licensing Compliance Engineer, Free Software Foundation === Steve, Kern and Anthony all made comments regarding the statement above. I just wanted to let you know that I've forwarded these comments to Brett Smith. :) Best regards Shane - -- Shane Coughlan FTF Coordinator Free Software Foundation Europe Office: +41435000366 ext 408 / Mobile: +41792633406 [EMAIL PROTECTED] Support Free Software http://fsfe.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQCVAwUBRqWzwdGa7CzA5hXyAQJqEwQApMLgHexbnbETjga1Vj3MJN8qMHnWX3uw mpo/8O73LHoBSgUTll+G9pidyy+xe8o39F7l3m4QbmN5u5IN6XcHI1nwynMyVcT1 FKL9cMf7woDYxBhKQv9kUK29Hq73SiFF5DMd2yPm0pO1tNHrS/XBvzeYetgB6YSm VuPARJ+FuC4= =Xk30 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all Following comments on FSF's position regarding OpenSSL as a System Library in Debian, Brett Smith at FSF sent the following message: === I apologize for my misunderstandings about OpenSSL's status in Debian, and appreciate the corrections. However, even given all this information, I still don't see how OpenSSL meets part (a) of the System Library definition. What is the Major Component that OpenSSL accompanies? Kernels always come with C libraries, and GCC always comes with libgcc. What package comes with OpenSSL? I understand that there are some pretty important applications that require OpenSSL, such as apt, but that's not the same thing as accompanying apt. Moreover, pretty important isn't the same thing as essential in the very narrow sense the license aims to define it in. === I hope this helps clarify things. :) Regards Shane - -- Shane Coughlan FTF Coordinator Free Software Foundation Europe Office: +41435000366 ext 408 / Mobile: +41792633406 [EMAIL PROTECTED] Support Free Software http://fsfe.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQCVAwUBRqYWZdGa7CzA5hXyAQJm9wP/eHCZAkZFQNR1+aliIzJqQ8o4CA2CMU87 MQ98NQubX/fd0Cai34Ue9hu4m8nqS2Eo0zbw9+1TYpHZ29N6HvQW5IwAv32FkBPI ah/aLgmjnlFlcBJAjTfQo2jswHyxUwmRI0CFnAK8J6E1AB2sriBceHgGZdrVs770 ux0SMFlnsqk= =kl+r -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Shane M. Coughlan writes: Dear all Following comments on FSF's position regarding OpenSSL as a System Library in Debian, Brett Smith at FSF sent the following message: === I apologize for my misunderstandings about OpenSSL's status in Debian, and appreciate the corrections. However, even given all this information, I still don't see how OpenSSL meets part (a) of the System Library definition. What is the Major Component that OpenSSL accompanies? Kernels always come with C libraries, and GCC always comes with libgcc. What package comes with OpenSSL? I understand that there are some pretty important applications that require OpenSSL, such as apt, but that's not the same thing as accompanying apt. Moreover, pretty important isn't the same thing as essential in the very narrow sense the license aims to define it in. === I hope this helps clarify things. :) I (as neither Debian Developer nor lawyer) think it makes things more arbitrary, in particular the distinction between come with and require. Which kernels come with C libraries in a different sense than they come with a large set of other binaries? When I download the Linux kernel, it does not include any C library; when I download or update the various free BSDs, they include the kernel, a C library, all of gcc, and a variety of other GPLed works that are not System Libraries. On the other hand, libgcc is distributed (by the FSF) with the rest of GCC -- but is that not because it is part of GCC? To pick an example, libgcc includes crtstuff.c from the main gcc directory. The copyright comment at the start of that file says This file is part of GCC. The libgcc directory includes a variety of linker scripts and build directives, but no separate source code. Distributors usually sever libgcc from the gcc binary, so that libgcc is distributed separately from the packages containing the gcc compilers. (Also: If, for a modern packaging system, a compiler is essential but the packaging system is not, the FSF needs to have its head re-examined.) Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
On Tue, Jul 24, 2007 at 05:10:32PM +0200, Shane M. Coughlan wrote: Following comments on FSF's position regarding OpenSSL as a System Library in Debian, Brett Smith at FSF sent the following message: === I apologize for my misunderstandings about OpenSSL's status in Debian, and appreciate the corrections. However, even given all this information, I still don't see how OpenSSL meets part (a) of the System Library definition. What is the Major Component that OpenSSL accompanies? Kernels always come with C libraries, [...] I don't think it's accurate to say that glibc is any more tightly bound to the Linux kernel than OpenSSL is -- you can certainly use different libc implementations to access the kernel, just as you could use different SSL implementations such as gnutls. In particular, going by the GPLv3: ] The System Libraries of an executable work include anything, other than ] the work as a whole, that (a) is included in the normal form of packaging ] a Major Component, but which is not part of that Major Component, and ] (b) serves only to enable use of the work with that Major Component, ] or to implement a Standard Interface for which an implementation is ] available to the public in source code form. then libc can't treat the kernel as its Major Component because it's not included in the normal form of packaging [that] Major Component. That's somewhat fundamental technically, in so far as the kernel provides the hardware abstraction to a fairly static userspace/kernel ABI, and libc provides an implementation of the C (or POSIX or GNU) API based on the kernel's ABI. Up to that point you can just call it enabling use of the kernel (by people who can only speak C and POSIX), but the problem then comes if, say, you choose to implement some C or POSIX API (such as POSIX threads) entirely in userspace rather than using the kernel's features, and to take things a step further, perhaps decide to package that separately. Your cases are then: - libc implements pthreads as a thin layer over the kernel - libc implements pthreads in userspace, with all pthreads looking like a single thread/process to the kernel - libpthreads implements pthreads in userspace, with all pthreads looking like a single thread/process to the kernel, with libpthreads being a standard component of the operating system - libpthreads implements pthreads in userspace, with all pthreads looking like a single thread/process to the kernel, with libpthreads being a optional and rarely installed component of the operating system - libpkthreads implements pthreads as a thin layer over the kernel threads, but is an experimental implementation looking to replace libpthreads, that's optional and (currently) rarely installed To me, the most natural line to draw when considering whether the pthreads implementation is a system library in the above is between the two libpthreads -- in the first three cases, how it's implemented is irrelevant, it's a standard library, implementing a standard API, that doesn't contaminate the GPLed software any more or less in any case, and is available to everyone who's going to use the GPLed software on the operating system in question. For the latter two cases, there's no reason to consider the pthreads implementations particularly important parts of the operating system, so they shouldn't be considered system libraries no matter how thin or heavy-weight they are compared to the kernel. If you're arguing that libc is only relevant in that it provides access to the kernel, I think you end up with the wrong answer in a few levels: - libc doesn't provide access to the kernel; it uses the kernel to provide a C API; printf() isn't a kernel call, eg, it's something native to libc - the clause becomes implementation dependent: if you implement something in the kernel, and provide it via libc it's can be used by GPLv3 programs, but if you implement it in libc, it's only accessible if it's an official standard - it becomes packaging dependent: if you implement an official standard in libc, that's okay, but if you implement it in a package of its own, that's not To take a more direct situation: under that interpretation, if you take glibc, implement a new, non-standard feature along the lines of obstacks, say, in glibc -- perhaps a rewrite of talloc -- and only make your new version of glibc available under the GPLv2. Then, even if that's included as a standard part of all Debian or Hurd or OpenSolaris installs, it's no longer possible to compile GPLv3 apps against that library, because the argument becomes: myglibc (prospective System Library) is included in the normal form of packaging the kernel (a Major Component), but is not part of the kernel, and
Re: Bacula and OpenSSL
I agree with AJ's statements and add only this: Apt is priority important. That is the same priority as openssl. Apt has relativly few revese dependencies (it appears to have less than openssl does). But libapt is without any doubt a system library under the GPLv3. It accompanies apt which is without doubt a genuinely fundamental component of the system. So I'm thinking the Brett's criteria are not quite ideal. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Thomas Dickey [EMAIL PROTECTED] writes: Simon Josefsson [EMAIL PROTECTED] wrote: Kern Sibbald [EMAIL PROTECTED] writes: GPL + OpenSSL exception would be enough to be sure. You may have more luck convincing copyright owners to grant an OpenSSL exception than to accept an entirely new license. I am told that FSF never grants exceptions so this is a hopeless path that I have already explored. That is incorrect. The FSF has granted OpenSSL license exceptions to some software that links to OpenSSL. For example, GNU wget. That's not an example (unless you're intending to show a case where FSF allows itself to do things that it forbids others ;-) I don't follow, what do you mean? GNU wget is distributed under the GPL with a license exception to permit linking with OpenSSL. As far as I know, the FSF doesn't forbid anyone to use GPL with an OpenSSL exception. /Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Hi Shane, On Thu, Jul 19, 2007 at 04:22:06PM +0200, Shane M. Coughlan wrote: Steve Langasek wrote: I agree that the GPLv3 is not compatible with the OpenSSL license, in the sense that code licensed under the OpenSSL license cannot be included in a GPLv3 work. However, the GPLv3 does include a broader (if no more easily understood) system exception clause, which seems to allow distributing GPLv3 binaries that are /dynamically linked/ against OpenSSL. Is this not the position of FSF/FSF Europe? I discussed this issue with Brett Smith of FSF, and as a result of this he wrote the following brief summary: === We do not believe that OpenSSL qualifies as a System Library in Debian. The System Library definition is meant to be read narrowly, including only code that accompanies genuinely fundamental components of the system. I don't see anything to suggest that that's the case for OpenSSL in Debian: the package only has important priority (as opposed to glibc's required), there are only about 350 packages depending on it (as opposed to glibc's 8500), and it isn't installed on a base system. To put it plainly, if OpenSSL actually were a System Library, I would expect it to look more like one. - -- Brett Smith Licensing Compliance Engineer, Free Software Foundation === IMHO that would be a rather unfortunate position for the FSF to take, as it would mean the changes to the system exception clause are *only* of benefit to distributors of proprietary operating systems, while GNU/Linux distributors are left with the same license compatibility problems as ever. But as AJ noted, the above analysis seems to get some facts wrong. In addition to the fact that OpenSSL is part of the base system, the count of reverse-dependencies seems to be off somewhat. There are 461 packages in etch that depend on libssl0.9.8, plus another 11 depending on the libssl0.9.7 that we aren't quite rid of. Of course that's nothing close to glibc's 8500, but if we were to look at some of the individual libraries within the libc6 package, like librt, libnsl, libm, or libdl, I would expect that openssl's usage within Debian is at least within an order of magnitude of some of these. Surely if libraries such as these qualify as System Libraries (and I should hope they do!), shouldn't libssl qualify too? Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Hello Shane, On Thursday 19 July 2007 16:22, Shane M. Coughlan wrote: Dear Steve Steve Langasek wrote: I agree that the GPLv3 is not compatible with the OpenSSL license, in the sense that code licensed under the OpenSSL license cannot be included in a GPLv3 work. However, the GPLv3 does include a broader (if no more easily understood) system exception clause, which seems to allow distributing GPLv3 binaries that are /dynamically linked/ against OpenSSL. Is this not the position of FSF/FSF Europe? I discussed this issue with Brett Smith of FSF, and as a result of this he wrote the following brief summary: === We do not believe that OpenSSL qualifies as a System Library in Debian. The System Library definition is meant to be read narrowly, including only code that accompanies genuinely fundamental components of the system. I don't see anything to suggest that that's the case for OpenSSL in Debian: the package only has important priority (as opposed to glibc's required), there are only about 350 packages depending on it (as opposed to glibc's 8500), and it isn't installed on a base system. To put it plainly, if OpenSSL actually were a System Library, I would expect it to look more like one. Thanks for following up on this. However, I am not sure that Brett answered the technical point concerning the GPLv3 that was brought up by Steve. Though I'm not sure that question really needs answering since it is likely to lead to lots of different interpretations of subtle points as we are currently seeing with the System Library definition. What struck me as getting closer to the fundamental problem that I am having is the remarks in a later email by Anthony Towns where there are apparently 360 packages on his system that would be removed if he were to remove OpenSSL. I see the positions of the different people who have responded to this question about linking Bacula with OpenSSL, and though I obviously cannot agree with everyone, since there are opposing interpretations, I can say that each has valid points. To me the issue is much more fundamental. Apparently the problem with OpenSSL is one of an onerous advertising clause, which I don't find so onerous -- so the authors want their names acknowledged for the work they did. In reading the clause that apparently poses the problem: * 3. All advertising materials mentioning features or use of this software *must display the following acknowledgment: *This product includes cryptographic software written by * Eric Young ([EMAIL PROTECTED]) I have to say, that I am not completely sure what they want. I've tried to ask the authors, but their email addresses seem to be invalid. I've tried to ask the current OpenSSL maintainers, but they have not yet responded to my email. In any case, I have added explicit acknowlegements in the LICENSE file and in the manual. As far as I know these are the only advertising materials that are used by Bacula or any of the distros, so I *think* I am in compliance with *their* license. Now, coming back the GPL issue. I can understand why RMS doesn't like the OpenSSL license because of this advertising clause, but what I find *very* hard to understand is why that concerns anyone but me and the people distributing the binaries. We are the only ones who suffer from that clause. The bottom line is that I see no harm to either the Free Software movement nor the authors of GPLed software that I use in Bacula, if I comply the best I can with the terms of the OpenSSL license. Right now, license issues seem to be black and white, that is they either work or do not work with GPL period. It seems to me that in the case of OpenSSL, their license is not totally incompatible with GPL, it is just a bit annoying to some people. I don't want to imply that I encourage such licenses, but given the wide spread usage of OpenSSL and the rather trivial nature of this problem (IMO), it seems to me that the decision on whether or not software can be linked to the OpenSSL code should be up to the persons distributing the binaries. Because of the large number of packages where some, if not many, probably have the same problem as Bacula, I would appreciate hearing FSF's and RMS' position on this. Best regards, Kern -- Brett Smith Licensing Compliance Engineer, Free Software Foundation === Regards Shane -- Shane Coughlan FTF Coordinator Free Software Foundation Europe Office: +41435000366 ext 408 / Mobile: +41792633406 [EMAIL PROTECTED] Support Free Software http://fsfe.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Simon Josefsson [EMAIL PROTECTED] wrote: That is incorrect. The FSF has granted OpenSSL license exceptions to some software that links to OpenSSL. For example, GNU wget. That's not an example (unless you're intending to show a case where FSF allows itself to do things that it forbids others ;-) I don't follow, what do you mean? GNU wget is distributed under the GPL with a license exception to permit linking with OpenSSL. It's a GNU project, as noted. As far as I know, the FSF doesn't forbid anyone to use GPL with an OpenSSL exception. That's entirely possible, but you haven't provided an example which isn't contaminated by self-interest on the part of FSF. If you can provide such an example, there's something to discuss. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Thomas Dickey [EMAIL PROTECTED] writes: As far as I know, the FSF doesn't forbid anyone to use GPL with an OpenSSL exception. That's entirely possible, but you haven't provided an example which isn't contaminated by self-interest on the part of FSF. If you can provide such an example, there's something to discuss. The FSF cannot change the license on code they don't own. As far as I understand, what you are looking for do not appear to be possible from a legal point of view. I'm assuming that you would regard any FSF owned code to be contaminated by the FSFs' self-interest. What kind of example are you looking for? /Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Simon Josefsson [EMAIL PROTECTED] wrote: What kind of example are you looking for? The example that you failed to provide in the posting to which I responded. (let's not get sidetracked) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Steve Steve Langasek wrote: I agree that the GPLv3 is not compatible with the OpenSSL license, in the sense that code licensed under the OpenSSL license cannot be included in a GPLv3 work. However, the GPLv3 does include a broader (if no more easily understood) system exception clause, which seems to allow distributing GPLv3 binaries that are /dynamically linked/ against OpenSSL. Is this not the position of FSF/FSF Europe? I discussed this issue with Brett Smith of FSF, and as a result of this he wrote the following brief summary: === We do not believe that OpenSSL qualifies as a System Library in Debian. The System Library definition is meant to be read narrowly, including only code that accompanies genuinely fundamental components of the system. I don't see anything to suggest that that's the case for OpenSSL in Debian: the package only has important priority (as opposed to glibc's required), there are only about 350 packages depending on it (as opposed to glibc's 8500), and it isn't installed on a base system. To put it plainly, if OpenSSL actually were a System Library, I would expect it to look more like one. - -- Brett Smith Licensing Compliance Engineer, Free Software Foundation === Regards Shane - -- Shane Coughlan FTF Coordinator Free Software Foundation Europe Office: +41435000366 ext 408 / Mobile: +41792633406 [EMAIL PROTECTED] Support Free Software http://fsfe.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQCVAwUBRp9ziNGa7CzA5hXyAQIeqgQA5Mh8Z4gGTebZlnjrarafevRfHDscrl2n 8eAv6tNOXAX1xPCdEOrtKwIsXGb7NaPKQN6++0HjLRpYbogTsCJY1MBRL7UrE1DT cPwoKByg6rEV+0AcGEprhlSftIEzpHoCavRBc6DIs9Z56tTqsV11sIZIqQOpaAuB QigobVJggsU= =/u7s -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kern Sibbald wrote: Well, it is pretty general purpose. None of the FSF code is network or TLS related. The FSF files involved are: src/lib/fnmatch.h FSF src/lib/fnmatch.c FSF src/lib/enh_fnmatch.h FSF src/lib/enh_fnmatch.c FSF (fnmatch enhanced by us) src/lib/idcache.c FSF (from tar I think) src/findlib/save-cwd.c FSF (from tar I think) src/findlib/makepath.c FSF(from tar I think) Just an update for everyone. The FSF (as the copyright holder) is currently in discussions with Kern to see if they can help resolve this issue for the Bacula project. :) Regards Shane - -- Shane Coughlan FTF Coordinator Free Software Foundation Europe Office: +41435000366 ext 408 / Mobile: +41792633406 [EMAIL PROTECTED] Support Free Software http://fsfe.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQCVAwUBRp96a9Ga7CzA5hXyAQIw0QP/bNNtBxlQneasdV7+4QF+Q16BNYebPUag qkWVPqL5H5I62FNmaQL1IvkMZ0welCCKGdeOb9AUxIVHWuL562mtdYiOz8dbcOKg ruHiUYGYpVWj5QOXreAwsnjnZMHfxl6YJMeGK+4mv3gFIwN6CxvLjDO2b7+M5Sq5 FaU1hGid8l4= =8OM8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
On Thu, Jul 19, 2007 at 04:22:06PM +0200, Shane M. Coughlan wrote: === We do not believe that OpenSSL qualifies as a System Library in Debian. The System Library definition is meant to be read narrowly, including only code that accompanies genuinely fundamental components of the system. OpenSSL certainly accompanies genuinely fundamental components of the system; it's status in Debian is that it's as fundamental as apt, and significantly more fundamental than any windowing system, which is explicitly listed as an example of a fundamental component in the GPLv3. I don't see anything to suggest that that's the case for OpenSSL in Debian: the package only has important priority (as opposed to glibc's required), The definition of the required priority is the minimal set of packages that are required for a system to be administered using dpkg. That excludes, for instance, gcc, not to mention window managers and even all our kernel packages. there are only about 350 packages depending on it (as opposed to glibc's 8500), There are apparently 360 packages just on my system which will be removed if I remove openssl, and I only have 1883 installed. On the same system (which is my day to day desktop), removing libx11-6 takes down 610 packages. On a headless server, removing libx11-6 takes down 7 packages, while libssl0.9.8 takes 82 packages with it. and it isn't installed on a base system. The base system is precisely those packages at priority required or important, and includes openssl. To put it plainly, if OpenSSL actually were a System Library, I would expect it to look more like one. From what I can see of the GPLv3 text, OpenSSL plainly is a System Library for Debian -- SSL support is a major essential component of the specific operating system, and one that we include on all systems as soon as they're installed before giving users the option of what to install, whether they're building a server, desktop system, embedded target or anything else. It's integrated into the operating system to the level at which basic tools such as curl and wget are configured to rely on it and through those dependencies such as debootstrap (used to install the Debian base system), openoffice.org, gimp, and bzflag; likewise python directly depends on ssl, and hence so do all the python scripts in the archive. It's not essential by the very limited meaning we use for the Essential: yes field in the Packages files, which is to say, if you remove this package, you will not be able to manage your system using dpkg (and indeed that field is used for only a subset of the Priority: required packages, and happens to not be used for glibc), but it's certainly essential by most common usages of the term, and some more general usage of the term is certainly implied by the GPLv3's reference to window managers as essential components. Cheers, aj signature.asc Description: Digital signature
Re: Bacula and OpenSSL
* Anthony Towns ([EMAIL PROTECTED]) wrote: On Thu, Jul 19, 2007 at 04:22:06PM +0200, Shane M. Coughlan wrote: We do not believe that OpenSSL qualifies as a System Library in Debian. The System Library definition is meant to be read narrowly, including only code that accompanies genuinely fundamental components of the system. Wow is that confused. OpenSSL certainly accompanies genuinely fundamental components of the system; it's status in Debian is that it's as fundamental as apt, and significantly more fundamental than any windowing system, which is explicitly listed as an example of a fundamental component in the GPLv3. Agreed, and with the rest of Anthony's analysis. It may not have been true a few releases ago but things change and it's definitely fundamental in etch and will be included in all Debian releases and installations in the foreseeable future. It has to be explicitly *removed* from even a minimal installation and doing so has some serious implications. Thanks, Stephen signature.asc Description: Digital signature
Re: Bacula and OpenSSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Kern Kern Sibbald wrote: On Saturday 14 July 2007 11:03, Simon Josefsson wrote: That is incorrect. The FSF has granted OpenSSL license exceptions to some software that links to OpenSSL. For example, GNU wget. Interesting. Shane would you comment on this? As Simon said, in certain special circumstances selected GNU tools related to networking have been granted exceptions. I suggest that such a grant is not likely in the case of the general purpose code included with Bacula. However, please bear in mind that I don't speak for FSF :) In addition, there are two files copyrighted by Anders Carlsson, two by Sun Microsystems in the tray-monitor directory, and a number of files by ATT all in the win32 subdirectories. All of the authors of third-party code would need to be contacted for a linking exception, though from your last email it sounds like you have already removed a substantial amount of the third-party code. I have some availability this week. I could do a physical meeting or a phone call during Wednesday and Thursday afternoon if you think it would be useful. :) Regards Shane - -- Shane Coughlan FTF Coordinator Free Software Foundation Europe Office: +41435000366 ext 408 / Mobile: +41792633406 [EMAIL PROTECTED] Support Free Software http://fsfe.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQCVAwUBRpszBdGa7CzA5hXyAQJjYAQA4eT1gTBTujQ89GyIXlMFmBd8ONJEO4Bn fQrn70lo4WkhFPlzWGnlm28JqAlzEH/Q31FDAntVScMf9AXEpGysIL62Y0E7Q80u bLnJwBfWfinOTtXw07qywiG9g6dqyxFHlB7mzg9rj3JbUyafsitlGveOUKpV7tf3 DKwLekVRt3U= =DrGS -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
On Monday 16 July 2007 10:57, Shane M. Coughlan wrote: Hi Kern Kern Sibbald wrote: On Saturday 14 July 2007 11:03, Simon Josefsson wrote: That is incorrect. The FSF has granted OpenSSL license exceptions to some software that links to OpenSSL. For example, GNU wget. Interesting. Shane would you comment on this? As Simon said, in certain special circumstances selected GNU tools related to networking have been granted exceptions. I suggest that such a grant is not likely in the case of the general purpose code included with Bacula. However, please bear in mind that I don't speak for FSF :) Yes, and in addition, after Josselin's email, I did a bit of research, and for at least one of the files that we use (fnmatch.c), the FSF license was changed from GPL to LGPL sometime in 2004 the best I can tell. Unfortunately, we are still using the old GPL'ed version rather than the newer LGPL'ed version. While it would be best to convert to the newer version, it is not so easy as the we have made some modifications to the old one to support Win32 systems (stupid difference of path separators, ...). Question: for old GPL'ed versions of fnmatch.c and fnmatch.h that we are using copyrighted in 1997 by FSF, would it be possible to modify them to use the LGPL as you are currently doing? That would give me a bit of breathing room (i.e. no recoding for the moment). Long term, I am probably going to use your newer LGPLed version since it supports UTF-8, but that will take some modifications and lots of testing. In addition, there are two files copyrighted by Anders Carlsson, two by Sun Microsystems in the tray-monitor directory, and a number of files by ATT all in the win32 subdirectories. All of the authors of third-party code would need to be contacted for a linking exception, though from your last email it sounds like you have already removed a substantial amount of the third-party code. Yes, all the authors would have to be contacted, but given they involve institutions such as FSF and ATT and Sun, I don't plan to go that route, it has little chance of succeeding. For files like fnmatch.c where FSF has already changed the license, I think it makes sense to ask for a change to the old code. For all the rest, I will work on replacing the files and/or rewriting them myself. It is a terrible waste of time, but it is not a monster project, and the only hard part is the testing that will be necessary to validate the changes ... I have some availability this week. I could do a physical meeting or a phone call during Wednesday and Thursday afternoon if you think it would be useful. :) I appreciate your offer, and I think that meeting at some point will be important, especially if FSF is willing to put the older fnmatch.c/h that we use under the LGPL license that is being used by the current version. However, one important issue to work through is Josselin's claim that due to the wording in GPL v3, I could switch to it, and it would be OK to link OpenSSL in as shared objects. If that is the case, it would provide a short term solution to this problem so that Debian can continue to release Bacula with OpenSSL enabled in the next version. Switching to GPL v3 is something I could do before the next release (in a week or two), but I would do it only if I can get FSFE and Debian to confirm that it will resolve the OpenSSL linking problem -- for the moment, I don't have any official confirmation from either of you. Longer term, I am definitely removing all 3rd party copyrighted code that is GPL'ed, and unless GPL v3 turns out to be the magic bullet and does not encomber me with additional constraints, I'll either add back the OpenSSL modification I previously added for Debian, or switch to a less restrictive Open Source License such as Sun's. I'm still looking at other licenses and switching will require a good deal of thought ... Before swtiching to any other license, should that be the case, and possibly before adding any license modifications, Shane and I will very likely need to meet. Regards, Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Kern Kern Sibbald wrote: Yes, and in addition, after Josselin's email, I did a bit of research, and for at least one of the files that we use (fnmatch.c), the FSF license was changed from GPL to LGPL sometime in 2004 the best I can tell. Unfortunately, we are still using the old GPL'ed version rather than the newer LGPL'ed version. While it would be best to convert to the newer version, it is not so easy as the we have made some modifications to the old one to support Win32 systems (stupid difference of path separators, ...). Question: for old GPL'ed versions of fnmatch.c and fnmatch.h that we are using copyrighted in 1997 by FSF, would it be possible to modify them to use the LGPL as you are currently doing? That would give me a bit of breathing room (i.e. no recoding for the moment). Long term, I am probably going to use your newer LGPLed version since it supports UTF-8, but that will take some modifications and lots of testing. FSF would need to answer this question directly. FSF and FSFE are sister organisations but we are administratively separate. I will pass this question onward off-list. :) However, one important issue to work through is Josselin's claim that due to the wording in GPL v3, I could switch to it, and it would be OK to link OpenSSL in as shared objects. I am discussing this with Brett Smith at the moment. Regards Shane - -- Shane Coughlan FTF Coordinator Free Software Foundation Europe Office: +41435000366 ext 408 / Mobile: +41792633406 [EMAIL PROTECTED] Support Free Software http://fsfe.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQCVAwUBRpuLqNGa7CzA5hXyAQL84gP8DyjLbDbgKtoyXdvIukFnmOzgBjcs6EsF oQ3eLqo/mml21UfowSBjYWo6xFePogi+ILhfWfq3eDJ6bYEP+ilysQtgfeHXxxx1 sVbTSHfS+hOtIdnsiCZ6j2O10jYaBMEIedJKkakWHXCbaYwYzvZNGOfC9Nxle8Fz /8q6YlR2R0s= =6XPy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
On Monday 16 July 2007 17:15, Shane M. Coughlan wrote: Hi Kern Kern Sibbald wrote: Yes, and in addition, after Josselin's email, I did a bit of research, and for at least one of the files that we use (fnmatch.c), the FSF license was changed from GPL to LGPL sometime in 2004 the best I can tell. Unfortunately, we are still using the old GPL'ed version rather than the newer LGPL'ed version. While it would be best to convert to the newer version, it is not so easy as the we have made some modifications to the old one to support Win32 systems (stupid difference of path separators, ...). Question: for old GPL'ed versions of fnmatch.c and fnmatch.h that we are using copyrighted in 1997 by FSF, would it be possible to modify them to use the LGPL as you are currently doing? That would give me a bit of breathing room (i.e. no recoding for the moment). Long term, I am probably going to use your newer LGPLed version since it supports UTF-8, but that will take some modifications and lots of testing. FSF would need to answer this question directly. FSF and FSFE are sister organisations but we are administratively separate. I will pass this question onward off-list. :) OK, understood thanks. This is not really extremely urgent since its determination will not change the immenent 2.2.0 release. However, one important issue to work through is Josselin's claim that due to the wording in GPL v3, I could switch to it, and it would be OK to link OpenSSL in as shared objects. I am discussing this with Brett Smith at the moment. Thanks. This point is important (pressing) as it could provide a quick solution for Debian. Best regards, Kern Regards Shane -- Shane Coughlan FTF Coordinator Free Software Foundation Europe Office: +41435000366 ext 408 / Mobile: +41792633406 [EMAIL PROTECTED] Support Free Software http://fsfe.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Kern Sibbald [EMAIL PROTECTED] writes: GPL + OpenSSL exception would be enough to be sure. You may have more luck convincing copyright owners to grant an OpenSSL exception than to accept an entirely new license. I am told that FSF never grants exceptions so this is a hopeless path that I have already explored. That is incorrect. The FSF has granted OpenSSL license exceptions to some software that links to OpenSSL. For example, GNU wget. Exactly what FSF code are you using? It couldn't hurt to ask them. If it is general purpose code, I suspect they won't give it, but if it is network or even TLS related, there could be a chance. /Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
On Saturday 14 July 2007 11:03, Simon Josefsson wrote: Kern Sibbald [EMAIL PROTECTED] writes: GPL + OpenSSL exception would be enough to be sure. You may have more luck convincing copyright owners to grant an OpenSSL exception than to accept an entirely new license. I am told that FSF never grants exceptions so this is a hopeless path that I have already explored. That is incorrect. The FSF has granted OpenSSL license exceptions to some software that links to OpenSSL. For example, GNU wget. Interesting. Shane would you comment on this? Exactly what FSF code are you using? It couldn't hurt to ask them. If it is general purpose code, I suspect they won't give it, but if it is network or even TLS related, there could be a chance. Well, it is pretty general purpose. None of the FSF code is network or TLS related. The FSF files involved are: src/lib/fnmatch.h FSF src/lib/fnmatch.c FSF src/lib/enh_fnmatch.h FSF src/lib/enh_fnmatch.c FSF (fnmatch enhanced by us) src/lib/idcache.c FSF (from tar I think) src/findlib/save-cwd.c FSF (from tar I think) src/findlib/makepath.c FSF(from tar I think) In addition, there are two files copyrighted by Anders Carlsson, two by Sun Microsystems in the tray-monitor directory, and a number of files by ATT all in the win32 subdirectories. My status on this project is: - I have already removed or replaced(with BSD code) three files that were copyrighted by FSF - idcache.c, I will re-write in any case (I've been planning this long before this problem). - I have a BSD licensed replacement for fnmatch, which I can substitute after the 2.2.0 (next) release of Bacula. - Probably enh_fnmatch will follow, but it is a good deal of extra work since it involves a good number of modifications. - save-cwd.c and makepath.c are heavily modified and will be more difficult to replace (confusion of the original code and the heavy modifications make the task harder). - I will rewrite the ATT copyrighted code after 2.2.0 is released, but this code is used only in the Win32 release so does not concern the Debian problem. - The Anders Carlsson and Sun copyrighted code is used in the GTK tray monitor and is problematic because I don't like working on GTK (makes it harder) and I am not familar with the code. I doubt that there is any BSD GTK tray monitor code :-( If you do not build the tray monitor binary with OpenSSL this will eliminate that problem. Regards, Kern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Simon Josefsson [EMAIL PROTECTED] wrote: Kern Sibbald [EMAIL PROTECTED] writes: GPL + OpenSSL exception would be enough to be sure. You may have more luck convincing copyright owners to grant an OpenSSL exception than to accept an entirely new license. I am told that FSF never grants exceptions so this is a hopeless path that I have already explored. That is incorrect. The FSF has granted OpenSSL license exceptions to some software that links to OpenSSL. For example, GNU wget. That's not an example (unless you're intending to show a case where FSF allows itself to do things that it forbids others ;-) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Langasek wrote: I agree that the GPLv3 is not compatible with the OpenSSL license, in the sense that code licensed under the OpenSSL license cannot be included in a GPLv3 work. However, the GPLv3 does include a broader (if no more easily understood) system exception clause, which seems to allow distributing GPLv3 binaries that are /dynamically linked/ against OpenSSL. Is this not the position of FSF/FSF Europe? I am discussing this in detail with Brett Smith of FSF. Kern Sibbald wrote: OK, I think the possible solutions are pretty clear to me. Thank you for the rapid response. No problem. Kern, if it would be useful to you I can arrange a physical meeting or telephone call to discuss these things in more detail. After all, we are only a few kilometres from each other in Switzerland and we might be able to explore options more quickly that way. Regards Shane - -- Shane Coughlan FTF Coordinator Free Software Foundation Europe Office: +41435000366 ext 408 / Mobile: +41792633406 [EMAIL PROTECTED] Support Free Software http://fsfe.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQCVAwUBRpkLutGa7CzA5hXyAQKT5AQAnm8Rf+mzyNtRf29/zhrT/PNQ5agRlJyn zN7LGecsMiFlCfEPI/0OAeu4Y4rE56QnFiJJQjEp4gUw7ybKeNFzCguLegBIUyoi HME3kurobaAgBKA1Bt6dZClE4N1bQ3u9sVmhH9QjWL+HU4ldoLtI6OduqBDNUyin H3OOojb1/Jw= =qI0F -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Le vendredi 13 juillet 2007 à 07:20 +0200, Kern Sibbald a écrit : Then, unless I have seriously misunderstood the reworded system libraries exception, I think relicensing Bacula under the GPLv3 (or dual-licensing under v2 and v3) should be fine for Debian. Sorry, but could you run it by me one more time why GPL v3 will work for Debian and why GPL v2 will not. The problem on GPL v2 for me was I needed to make an exception, which I cannot do without violating the 3rd party GPL licensed code I use. Why does GPL v3 resolve this?From what I understood, you are saying that in GPL v3 any separate object code does not require releasing the source for that object code -- i.e. it is now possible for a GPLed program to link to a separate object that is built from proprietary source? In my opinion the GPLv3 is more liberal with the licensing of the system libraries. This is what makes Nexenta legal now (it links dpkg which is GPL to the Solaris libc which is CDDL) and it applies to the Bacula case as well. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: Bacula and OpenSSL
Kern Sibbald [EMAIL PROTECTED] wrote: I would like a tit-for-a-tat clause so that those who modify it and distribute it are obligated to publish their modifications. The MIT license does not provide that. On the other hand, the MIT license permits even use by the objectionable persons who contribute to this thread. regards. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Kern Sibbald wrote: 2. You recently mentioned to me that GPL v3 may be a solution. Like Linus, I don't see any reason to switch to GPL v3, but if using GPL v3 makes Bacula compatible with OpenSSL AND all distros are happy with that, it seems to me to be an easy solution. I know that GPL v3 is compatible with the Apache license, but can you confirm whether or not it is compatible with whatever OpenSSL uses? I would also appreciate having Debian's legal view on this question. I don't believe that Debian provides legal views... My personal view is that GPLv3 is not compatible with the OpenSSL license. The problematic part of the OpenSSL license is the BSD advertising clause: * 3. All advertising materials mentioning features or use of this *software must display the following acknowledgment: *This product includes software developed by the OpenSSL Project *for use in the OpenSSL Toolkit. (http://www.openssl.org/) (From http://www.openssl.org/source/license.html) The only way this might be compatible with GPLv3 is if this clause was permitted by one of the clauses in GPLv3 section 7, Additional Terms. The only one under which it might fit is clause b): Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms: ... * b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; (From http://www.gnu.org/licenses/gpl.html) However, this only permits requiring preservation of notices in the material. An advertisement mentioning OpenSSL is not part of OpenSSL, and so this clause does not make point 3. of the OpenSSL license GPLv3-compatible. 3. Barring item 2, it seems to me that the only solution is to eliminate all third party software from Bacula and change the license to less restrictive one that permits Bacula being linked with any Open Source software. This seems the correct way forward in the long term. Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Kern Kern Sibbald wrote: What I would like: I would like Bacula to be able to be freely used by all distros without licensing problems with any Open Source software including OpenSSL. snip 1. Convert Bacula to use gnutls. One Debian user is working on this, but it is not a small nor an easy project. And though it is something I consider very worthwhile for Bacula to work with gnutls, it doesn't resolve the problem of using Bacula with OpenSSL. I understood that you require OpenSSL for Bacula due to user demand, so you could not replace it by GNUTLS entirely. Is that correct? 2. You recently mentioned to me that GPL v3 may be a solution. Like Linus, I don't see any reason to switch to GPL v3, but if using GPL v3 makes Bacula compatible with OpenSSL AND all distros are happy with that, it seems to me to be an easy solution. I know that GPL v3 is compatible with the Apache license, but can you confirm whether or not it is compatible with whatever OpenSSL uses? I would also appreciate having Debian's legal view on this question. There was the possibility that the final GPLv3 might turn out compatible with the OpenSSL licence. However, the published GPLv3 is not compatible with the OpenSSL licence. To be sure I also confirmed this with Brett Smith at FSF in Boston. 3. Barring item 2, it seems to me that the only solution is to eliminate all third party software from Bacula and change the license to less restrictive one that permits Bacula being linked with any Open Source software. The issue flagged by Fedora concerned that third-party code. In essence: If you remove all the vanilla GPLv2 or later software from Bacula you could also move back to your previous GPL+extra clauses license, or to a GPLv3 + OpenSSL exception license. Regards Shane - -- Shane Coughlan FTF Coordinator Free Software Foundation Europe Office: +41435000366 ext 408 / Mobile: +41792633406 [EMAIL PROTECTED] Support Free Software http://fsfe.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iQCVAwUBRpZRctGa7CzA5hXyAQJ1UAP/S1VHW5iA9MR0dl+i4C3PEoYnpdgbPSVa nsJp68tErT9QXnnhKBDb0HVZtzHEpTryknssXkFCEeFTy7GllKRUfRys0zKQWF5Q EWSoKooUcZsLMnJpoqgG0P4AX+Nl/3Ft46TtHhe+WFCGAdij8B2puUmx1oq4Uetl hoJ0BlSk40A= =vHfw -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
On Thu, Jul 12, 2007 at 06:06:14PM +0200, Shane M. Coughlan wrote: 2. You recently mentioned to me that GPL v3 may be a solution. Like Linus, I don't see any reason to switch to GPL v3, but if using GPL v3 makes Bacula compatible with OpenSSL AND all distros are happy with that, it seems to me to be an easy solution. I know that GPL v3 is compatible with the Apache license, but can you confirm whether or not it is compatible with whatever OpenSSL uses? I would also appreciate having Debian's legal view on this question. There was the possibility that the final GPLv3 might turn out compatible with the OpenSSL licence. However, the published GPLv3 is not compatible with the OpenSSL licence. To be sure I also confirmed this with Brett Smith at FSF in Boston. I agree that the GPLv3 is not compatible with the OpenSSL license, in the sense that code licensed under the OpenSSL license cannot be included in a GPLv3 work. However, the GPLv3 does include a broader (if no more easily understood) system exception clause, which seems to allow distributing GPLv3 binaries that are /dynamically linked/ against OpenSSL. Is this not the position of FSF/FSF Europe? 3. Barring item 2, it seems to me that the only solution is to eliminate all third party software from Bacula and change the license to less restrictive one that permits Bacula being linked with any Open Source software. The issue flagged by Fedora concerned that third-party code. In essence: If you remove all the vanilla GPLv2 or later software from Bacula you could also move back to your previous GPL+extra clauses license, or to a GPLv3 + OpenSSL exception license. Is there some reason that marking only his code as GPLv2 + OpenSSL exception, making it clear that other code (and which other code) included in Bacula does not have such an exception, would not be acceptable to all parties? Granting an additional permission is not modifying the GPL, and as long as the permission is detachable it would not make the license incompatible with the vanilla GPLv2 used in other parts of the work; and that would permit distributors to make an informed decision whether to excise the GPLv2-only code in order to distribute binaries linked against OpenSSL. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
On Thursday 12 July 2007 18:06, Shane M. Coughlan wrote: Hi Kern Kern Sibbald wrote: What I would like: I would like Bacula to be able to be freely used by all distros without licensing problems with any Open Source software including OpenSSL. snip 1. Convert Bacula to use gnutls. One Debian user is working on this, but it is not a small nor an easy project. And though it is something I consider very worthwhile for Bacula to work with gnutls, it doesn't resolve the problem of using Bacula with OpenSSL. I understood that you require OpenSSL for Bacula due to user demand, so you could not replace it by GNUTLS entirely. Is that correct? Yes, that is essentially correct. gnutls could replace OpenSSL for nearly everyone, but some institutions such as banks and financial instututions may need the extra certification that OpenSSL has. 2. You recently mentioned to me that GPL v3 may be a solution. Like Linus, I don't see any reason to switch to GPL v3, but if using GPL v3 makes Bacula compatible with OpenSSL AND all distros are happy with that, it seems to me to be an easy solution. I know that GPL v3 is compatible with the Apache license, but can you confirm whether or not it is compatible with whatever OpenSSL uses? I would also appreciate having Debian's legal view on this question. There was the possibility that the final GPLv3 might turn out compatible with the OpenSSL licence. However, the published GPLv3 is not compatible with the OpenSSL licence. To be sure I also confirmed this with Brett Smith at FSF in Boston. OK, thanks for the confirmation -- too bad. 3. Barring item 2, it seems to me that the only solution is to eliminate all third party software from Bacula and change the license to less restrictive one that permits Bacula being linked with any Open Source software. The issue flagged by Fedora concerned that third-party code. In essence: If you remove all the vanilla GPLv2 or later software from Bacula you could also move back to your previous GPL+extra clauses license, or to a GPLv3 + OpenSSL exception license. OK, I think the possible solutions are pretty clear to me. Thank you for the rapid response. Best regards, Kern Regards Shane -- Shane Coughlan FTF Coordinator Free Software Foundation Europe Office: +41435000366 ext 408 / Mobile: +41792633406 [EMAIL PROTECTED] Support Free Software http://fsfe.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
On Thursday 12 July 2007 18:06, Gervase Markham wrote: Kern Sibbald wrote: 2. You recently mentioned to me that GPL v3 may be a solution. Like Linus, I don't see any reason to switch to GPL v3, but if using GPL v3 makes Bacula compatible with OpenSSL AND all distros are happy with that, it seems to me to be an easy solution. I know that GPL v3 is compatible with the Apache license, but can you confirm whether or not it is compatible with whatever OpenSSL uses? I would also appreciate having Debian's legal view on this question. I don't believe that Debian provides legal views... Perhaps it was a bad choice of words. Debian has in the past provided me with their take on my license as it applies to their distribution, which is what interests me. My personal view is that GPLv3 is not compatible with the OpenSSL license. That has been confirmed by FSFE (Shane). The problematic part of the OpenSSL license is the BSD advertising clause: * 3. All advertising materials mentioning features or use of this *software must display the following acknowledgment: *This product includes software developed by the OpenSSL Project *for use in the OpenSSL Toolkit. (http://www.openssl.org/) (From http://www.openssl.org/source/license.html) I personally see no particular issue with the advertising clause from two points of view: - if he really wants such an acknowledgement, why not. For me, it doesn't violate any of my fundamental rights. If one mentions Windows, in any documentation whatsoever, one is required to mention that it is a trademark of Microsoft -- the same applies to a lot of other things as well, including the name Bacula :-) - Bacula does no advertisment (we have a users manual, but that is not advertisement, IMO), so this clause would have no effect anyway. The only way this might be compatible with GPLv3 is if this clause was permitted by one of the clauses in GPLv3 section 7, Additional Terms. The only one under which it might fit is clause b): Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms: ... * b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; (From http://www.gnu.org/licenses/gpl.html) However, this only permits requiring preservation of notices in the material. An advertisement mentioning OpenSSL is not part of OpenSSL, and so this clause does not make point 3. of the OpenSSL license GPLv3-compatible. 3. Barring item 2, it seems to me that the only solution is to eliminate all third party software from Bacula and change the license to less restrictive one that permits Bacula being linked with any Open Source software. This seems the correct way forward in the long term. Yes, that is the conculsion I have come to as well. Thanks. It seems a real pity to me that the GPL is so restrictive -- it should make my life as a programmer easier, but it has in fact made it harder. Best regards, Kern Gerv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Kern Sibbald [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Hello Shane, Bacula is nearing the end of a development cycle and the next version will be released in a matter of weeks, so I would like to revisit the problem that recently came up with the Bacula license. My purpose is not to debate the issues but rather come up with a plan forward for Bacula so that all distributions can use it with OpenSSL or any other Open Source code without problems. Please excuse me if I provide you with a bit of my reasoning and thoughts -- the idea is to help you target responses so I can end up with an accpetable solution. History: Bacula originally used the GPL v2 license, but I added some modifications to it -- most if not all are (IMO) now contained in the GPL v3. However, some of my original modifications created objections with Debian, so I removed them. In addition, Debian has an issue with distributing Bacula linked with OpenSSL and as a consequence, I added a modification to the GPL permitting Debian to link Bacula with OpenSSL. In more recent discussions with you, it seems that some of my modifications to the GPL (particularly the Debian clause) created a legal problem with Fedora and hence Red Hat because the GPL v2 is incompatible with the OpenSSL license and because there are about 10-20 files in the Bacula source that are copyrighted by third-parties under the GPL, so by modifying my license, I was or could have been technically violating their licenses. Well it is not a violation to have a mechanism to allow third parties to link to openSSL. The third parties would be violating licences by linking the work (assuming the FSF's linking theories are in fact leagally sound), however that is not your concern. What would be your concern is that distributions are often not willing to distribute the linked executables, for obvious reasons. However, for you the ideal situation would be to get permission from the copyright holders of the gpl'ed code you did not write to add a clause allowing linking to openssl. If you could do that, then just add the clause and everything is fine. One other possibility you did not list in your message would be to convince openSSL to change the licence to one that is GPL-compatible. This seems highly unlikely (nearly impossible), but would finally fix this problem once and for all. (The OpenSSL team feels the licence is GPL-compatible. It's unclear why, as it has a BSD like-advertising clause that is infamous for its GPL-incompatibility). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bacula and OpenSSL
Le jeudi 12 juillet 2007 à 16:41 +0200, Kern Sibbald a écrit : How do we get there? It seems to me that there are a number of alternatives: 1. Convert Bacula to use gnutls. One Debian user is working on this, but it is not a small nor an easy project. And though it is something I consider very worthwhile for Bacula to work with gnutls, it doesn't resolve the problem of using Bacula with OpenSSL. This looks like a good thing to do in the long term anyway, and not only for licensing matters. 2. You recently mentioned to me that GPL v3 may be a solution. Like Linus, I don't see any reason to switch to GPL v3, but if using GPL v3 makes Bacula compatible with OpenSSL AND all distros are happy with that, it seems to me to be an easy solution. I know that GPL v3 is compatible with the Apache license, but can you confirm whether or not it is compatible with whatever OpenSSL uses? I would also appreciate having Debian's legal view on this question. The GPL v3 is not compatible with the OpenSSL license. However, section 6 states: A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work. Apart from the very bad wording, I think the OpenSSL libraries can be perfectly considered as part of the System libraries. This flaw of the GPLv3 is at least good for something. If your GPL software can now be included in the HP-UX or AIX distribution, it can also be included in Debian. Please note that this is only applicable if your third-party contributions are licensed under GPL v2 or later. 3. Barring item 2, it seems to me that the only solution is to eliminate all third party software from Bacula and change the license to less restrictive one that permits Bacula being linked with any Open Source software. GPL + OpenSSL exception would be enough to be sure. You may have more luck convincing copyright owners to grant an OpenSSL exception than to accept an entirely new license. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bacula and OpenSSL
Le jeudi 12 juillet 2007 à 20:18 +0200, Kern Sibbald a écrit : It seems a real pity to me that the GPL is so restrictive -- it should make my life as a programmer easier, but it has in fact made it harder. The main point of the GPL is not to make your life easier, but to prevent your code from being used unfairly. If you want to go the easy way you should choose the MIT license :) -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bacula and OpenSSL
On Thursday 12 July 2007 22:52, Josselin Mouette wrote: Le jeudi 12 juillet 2007 à 16:41 +0200, Kern Sibbald a écrit : How do we get there? It seems to me that there are a number of alternatives: 1. Convert Bacula to use gnutls. One Debian user is working on this, but it is not a small nor an easy project. And though it is something I consider very worthwhile for Bacula to work with gnutls, it doesn't resolve the problem of using Bacula with OpenSSL. This looks like a good thing to do in the long term anyway, and not only for licensing matters. 2. You recently mentioned to me that GPL v3 may be a solution. Like Linus, I don't see any reason to switch to GPL v3, but if using GPL v3 makes Bacula compatible with OpenSSL AND all distros are happy with that, it seems to me to be an easy solution. I know that GPL v3 is compatible with the Apache license, but can you confirm whether or not it is compatible with whatever OpenSSL uses? I would also appreciate having Debian's legal view on this question. The GPL v3 is not compatible with the OpenSSL license. However, section 6 states: A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work. Apart from the very bad wording, I think the OpenSSL libraries can be perfectly considered as part of the System libraries. This flaw of the GPLv3 is at least good for something. If your GPL software can now be included in the HP-UX or AIX distribution, it can also be included in Debian. Well, I don't consider the above a flaw. The flaw (restriction of my freedom) is in GPL if it does not permit linking with OpenSSL (IMO). I agree with your interpretation, but I'm pretty sure that is not the official interpretation that Debian takes or am I mistaken? In fact, I consider for linking with Bacula as a separately installed piece of the system libraries that OpenSSL is part of the operating system in the same way that tcp wrappers or glibc is or any other library is, which would mean that there should be no problem with GPL v2. However, I know as a fact that as far as GPL v2 goes, Debian definitely does not agree with my interpretation. Please note that this is only applicable if your third-party contributions are licensed under GPL v2 or later. Bacula code is GPL v2, but all third party GPL'ed code (mostly FSF) is GPL v2 or later. 3. Barring item 2, it seems to me that the only solution is to eliminate all third party software from Bacula and change the license to less restrictive one that permits Bacula being linked with any Open Source software. GPL + OpenSSL exception would be enough to be sure. You may have more luck convincing copyright owners to grant an OpenSSL exception than to accept an entirely new license. I am told that FSF never grants exceptions so this is a hopeless path that I have already explored. Regards, Kern Unless Debian finds that GPL v3 will work with OpenSSL, barring one more unexplored avenue, over time, I'll purge all third party GPL'ed code and either modify or more likely switch off the GPL license ... Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: Bacula and OpenSSL
On Thursday 12 July 2007 22:59, Josselin Mouette wrote: Le jeudi 12 juillet 2007 à 20:18 +0200, Kern Sibbald a écrit : It seems a real pity to me that the GPL is so restrictive -- it should make my life as a programmer easier, but it has in fact made it harder. The main point of the GPL is not to make your life easier, but to prevent your code from being used unfairly. If you want to go the easy way you should choose the MIT license :) I would like a tit-for-a-tat clause so that those who modify it and distribute it are obligated to publish their modifications. The MIT license does not provide that. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: Bacula and OpenSSL
Le jeudi 12 juillet 2007 à 23:42 +0200, Kern Sibbald a écrit : This flaw of the GPLv3 is at least good for something. If your GPL software can now be included in the HP-UX or AIX distribution, it can also be included in Debian. Well, I don't consider the above a flaw. The flaw (restriction of my freedom) is in GPL if it does not permit linking with OpenSSL (IMO). This is a flaw in the copyleft, because it allows proprietary software distributors to benefit from the software more than they deserve. As for not being compatible with the OpenSSL license, this is intentional and the fact the GPLv3 wasn't changed to allow it confirms this intention. The advertising clause is not problematic for Bacula, but it may be so for much other software. I agree with your interpretation, but I'm pretty sure that is not the official interpretation that Debian takes or am I mistaken? The GPLv3 is quite new and I don't think all consequences have been explored. Anyway, it would be more relevant to know whether the copyright holders (here, the FSF) agree that this clause applies to OpenSSL in Debian (which is priority important and required by key components of the windowing system). In fact, I consider for linking with Bacula as a separately installed piece of the system libraries that OpenSSL is part of the operating system in the same way that tcp wrappers or glibc is or any other library is, which would mean that there should be no problem with GPL v2. However, I know as a fact that as far as GPL v2 goes, Debian definitely does not agree with my interpretation. This is true for Bacula packages you would distribute yourself, but this is *not* the case for packages included in Debian. The GPLv2 reads: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, *unless that component itself accompanies the executable*. This clause couldn't be more explicit. Debian ships all its software at the same place, which means the exception doesn't apply. Bacula code is GPL v2, but all third party GPL'ed code (mostly FSF) is GPL v2 or later. Then, unless I have seriously misunderstood the reworded system libraries exception, I think relicensing Bacula under the GPLv3 (or dual-licensing under v2 and v3) should be fine for Debian. I am told that FSF never grants exceptions so this is a hopeless path that I have already explored. Indeed. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bacula and OpenSSL
On Friday 13 July 2007 01:31, Josselin Mouette wrote: Le jeudi 12 juillet 2007 à 23:42 +0200, Kern Sibbald a écrit : This flaw of the GPLv3 is at least good for something. If your GPL software can now be included in the HP-UX or AIX distribution, it can also be included in Debian. Well, I don't consider the above a flaw. The flaw (restriction of my freedom) is in GPL if it does not permit linking with OpenSSL (IMO). This is a flaw in the copyleft, because it allows proprietary software distributors to benefit from the software more than they deserve. As for not being compatible with the OpenSSL license, this is intentional and the fact the GPLv3 wasn't changed to allow it confirms this intention. The advertising clause is not problematic for Bacula, but it may be so for much other software. I agree with your interpretation, but I'm pretty sure that is not the official interpretation that Debian takes or am I mistaken? The GPLv3 is quite new and I don't think all consequences have been explored. Anyway, it would be more relevant to know whether the copyright holders (here, the FSF) agree that this clause applies to OpenSSL in Debian (which is priority important and required by key components of the windowing system). In fact, I consider for linking with Bacula as a separately installed piece of the system libraries that OpenSSL is part of the operating system in the same way that tcp wrappers or glibc is or any other library is, which would mean that there should be no problem with GPL v2. However, I know as a fact that as far as GPL v2 goes, Debian definitely does not agree with my interpretation. This is true for Bacula packages you would distribute yourself, but this is *not* the case for packages included in Debian. The GPLv2 reads: However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, *unless that component itself accompanies the executable*. This clause couldn't be more explicit. Debian ships all its software at the same place, which means the exception doesn't apply. I think you are misreading the above. It simply says that for us who distribute Bacula code only, we are not required to distribute the source code for other major components that Bacula may use, such as glibc, tcpwrappers, or OpenSSL. However, you (Debian) who distribute a whole operating system, must also include all the source to all the packages, which is exactly what you do. The source code that you distribute includes the source to OpenSSL. There is no issue here since the source code must just be available on request, which is the case. It doesn't have to ship with the binaries. Bacula code is GPL v2, but all third party GPL'ed code (mostly FSF) is GPL v2 or later. Then, unless I have seriously misunderstood the reworded system libraries exception, I think relicensing Bacula under the GPLv3 (or dual-licensing under v2 and v3) should be fine for Debian. Sorry, but could you run it by me one more time why GPL v3 will work for Debian and why GPL v2 will not. The problem on GPL v2 for me was I needed to make an exception, which I cannot do without violating the 3rd party GPL licensed code I use. Why does GPL v3 resolve this?From what I understood, you are saying that in GPL v3 any separate object code does not require releasing the source for that object code -- i.e. it is now possible for a GPLed program to link to a separate object that is built from proprietary source? I am told that FSF never grants exceptions so this is a hopeless path that I have already explored. Indeed. There is a certain logic in that response since they have pushed hard for reducing the number of licenses, it makes sense that they are not going to favor making derivatives themselves to their own licenses ... -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
