Re: [Python-Dev] (libffi) Re: Copyright issue
On 1/30/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Well done! Would you like to derive a Python patch from that? Yup. I'll do. On 1/30/06, Thomas Heller [EMAIL PROTECTED] wrote: That's great! Would you like to integrate these changes into to ctypes CVS repository yourself? I indend to do a few releases still from there, before the first Python 2.5. If so, please tell me your SF username and I'll add you as developer. Also, please note that all work should be done on the 'branch_1_0' CVS branch - the HEAD is only experimental code (and not currently used). My SF username is perky. I'll try to make it portable but it'll lose some platforms through compilers because few of libffi sources are in preprocessed assembly (.S) which isn't supported by distutils yet. So, we'll need tests on various compiler/platforms before the release. Hye-Shik ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Hye-Shik Chang [EMAIL PROTECTED] writes: On 1/30/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Well done! Would you like to derive a Python patch from that? Yup. I'll do. On 1/30/06, Thomas Heller [EMAIL PROTECTED] wrote: That's great! Would you like to integrate these changes into to ctypes CVS repository yourself? I indend to do a few releases still from there, before the first Python 2.5. If so, please tell me your SF username and I'll add you as developer. Also, please note that all work should be done on the 'branch_1_0' CVS branch - the HEAD is only experimental code (and not currently used). My SF username is perky. Added. I'll try to make it portable but it'll lose some platforms through compilers because few of libffi sources are in preprocessed assembly (.S) which isn't supported by distutils yet. So, we'll need tests on various compiler/platforms before the release. Isn't it sufficient to append .S to self.compiler.src_extensions? Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
On 28/01/2006, at 8:04 PM, Martin v. Löwis wrote: The compiler needs specific exemptions because parts of the GPLed runtime libraries are included in all compiled code. No part of the autotools ends up in the finished code. If it did, you would need m4 to run Python and you don't. It doesn't matter whether it ends up in the finished code: if the aclocal.m4 is indeed GPL-licensed, then the entire Python source distribution must be GPL-licensed, because it contains or is derived from the Program or any part thereof. The build tools: m4 scripts, the configure shell script and the Makefiles all contain GPL code and are under GPL. However, none of this ends up in the 'finished program' which is the executable versions of Python and its associated libraries. The build tools are just tools not part of the program. The program is not 'derived' from the build tools. Maybe it would help to put it in a another domain: Say I decide to write the great Australian novel. I sit at my computer and type in the words. Those words are my copyright and I am able to restrict their use as provided in copyright legislation. These rights are inherent and exist regardless of whether or not I add a copyright notice. The notice is just a courtesy and a convenience which tells anyone who would like to use the work they need to get my permission. A license is just a set of standard permissions passed on with the work. Now I print out my novel. That printed version is 'derived' from the representation in the computer. So it is covered by the same copyright. If I compress the computer files, those are still derived work. If some American decides to write the great American novel by boiler-plating large chunks of my work with a little of his, then that work is derived and copyright to both of us. His actions are legal unless he tries to publish it, which would require my permission. This is analogous to linking a program with a library provided by another party. That is why one needs the specific concessions in the gcc compiler to cover the linked run time libraries. Of course the computer on which I wrote the book has an operating system which is copyright. The word processing software I used to do the writing is also copyright. However none of either program ends up in my novel. So the novel is not derived from them, and their copyright holders have no rights over the novel. I can happily package appropriately licensed copies of the word processing software with the finished book. So that others can try their hand at the same thing. In no way does such an operation give the software copyright holders any rights over the book. This is exactly analogous to including the GPL tools with your source distribution. You must comply with the GPL in respect of the GPL code. So you must include copyright notices and and make any modifications or improvements freely available. However, if you build a binary from the sources which does not include or link GPL code then the FSF have no rights over it and you are not obliged to acknowledge them or include their copyright notice. A Python binary is no more derived from the autotools than the book is derived from the word processing software. Bill Northcott ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
On 29/01/2006, at 5:48 AM, Martin v. Löwis wrote: Yes, but your conclusion is wrong. Python uses autoconf, but not aclocal/automake. The generated configure is explicitly not covered by the GPL; What makes you think that? I can see no such concession in the autoconf source distribution. A configure script is built up from lots of code fragments out of the autoconf and automake M4 files, and would clearly be covered by GPL. Bill Northcott ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
OTOH this (from python-sig-mac) is a worry if it is correct: s Apparently the readline library in MacOSX isn't really readline. s It's a renamed libedit. Not having encountered this deception s before, Python's build procedure doesn't know to test the capability s of readline. I suggest you just comment out the readline checks in s setup.py. Piet libedit (editline) is a different library with a similar function Piet as readline, but not compatible with it. It has a BSD license. It Piet is often used instead of readline for non-GPL software. True. I believe it was written by Rich Salz several years ago. Python used to work with it, but eventually started using some readline functionality which libedit doesn't provide. I don't recall what that is. If you distribute Python sources that link the GNU libreadline then all your code will be covered by GPL, because libreadline uses the full GPL not LGPL. That is why Apple and other commercial vendors do not include it in their OS. Bill Northcott ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
On 29/01/2006, at 5:48 AM, Martin v. Löwis wrote: Yes, but your conclusion is wrong. Python uses autoconf, but not aclocal/automake. The generated configure is explicitly not covered by the GPL; What makes you think that? I can see no such concession in the autoconf source distribution. A configure script is built up from lots of code fragments out of the autoconf and automake M4 files, and would clearly be covered by GPL. Bill Northcott ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
On 28/01/2006, at 8:04 PM, Martin v. Löwis wrote: The compiler needs specific exemptions because parts of the GPLed runtime libraries are included in all compiled code. No part of the autotools ends up in the finished code. If it did, you would need m4 to run Python and you don't. It doesn't matter whether it ends up in the finished code: if the aclocal.m4 is indeed GPL-licensed, then the entire Python source distribution must be GPL-licensed, because it contains or is derived from the Program or any part thereof. The build tools: m4 scripts, the configure shell script and the Makefiles all contain GPL code and are under GPL. However, none of this ends up in the 'finished program' which is the executable versions of Python and its associated libraries. The build tools are just tools not part of the program. The program is not 'derived' from the build tools. Maybe it would help to put it in a another domain: Say I decide to write the great Australian novel. I sit at my computer and type in the words. Those words are my copyright and I am able to restrict their use as provided in copyright legislation. These rights are inherent and exist regardless of whether or not I add a copyright notice. The notice is just a courtesy and a convenience which tells anyone who would like to use the work they need to get my permission. A license is just a set of standard permissions passed on with the work. Now I print out my novel. That printed version is 'derived' from the representation in the computer. So it is covered by the same copyright. If I compress the computer files, those are still derived work. If some American decides to write the great American novel by boiler-plating large chunks of my work with a little of his, then that work is derived and copyright to both of us. His actions are legal unless he tries to publish it, which would require my permission. This is analogous to linking a program with a library provided by another party. That is why one needs the specific concessions in the gcc compiler to cover the linked run time libraries. Of course the computer on which I wrote the book has an operating system which is copyright. The word processing software I used to do the writing is also copyright. However none of either program ends up in my novel. So the novel is not derived from them, and their copyright holders have no rights over the novel. I can happily package appropriately licensed copies of the word processing software with the finished book. So that others can try their hand at the same thing. In no way does such an operation give the software copyright holders any rights over the book. This is exactly analogous to including the GPL tools with your source distribution. You must comply with the GPL in respect of the GPL code. So you must include copyright notices and and make any modifications or improvements freely available. However, if you build a binary from the sources which does not include or link GPL code then the FSF have no rights over it and you are not obliged to acknowledge them or include their copyright notice. A Python binary is no more derived from the autotools than the book is derived from the word processing software. Bill Northcott ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
On 29/01/2006, at 7:00 PM, Martin v. Löwis wrote: Again: What matters is what ends up in the source distribution, http://www.python.org/ftp/python/2.4/Python-2.4.tgz No really that is wrong. What matters is what is in the Python executables, but you don't want to know that. So I will bow out of the discussion. Cheers Bill PS Linking with GNU libreadline really is a problem. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Bill Northcott wrote: What makes you think that? I can see no such concession in the autoconf source distribution. A configure script is built up from lots of code fragments out of the autoconf and automake M4 files, and would clearly be covered by GPL. No. As I just said in the other mail: The generated configure contains the explicit permission: # Copyright (C) 2003 Free Software Foundation, Inc. # This configure script is free software; the Free Software Foundation # gives unlimited permission to copy, distribute and modify it. If you look at the autoconf sources, you will find various such blocks (e.g. in lib/autoconf/general.m4): # As a special exception, the Free Software Foundation gives unlimited # permission to copy, distribute and modify the configure scripts that # are the output of Autoconf. You need not follow the terms of the GNU # General Public License when using or distributing such scripts, even # though portions of the text of Autoconf appear in them. The GNU # General Public License (GPL) does govern all other use of the material # that constitutes the Autoconf program. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Martin v. Löwis [EMAIL PROTECTED] writes: The source distribution would contain aclocal.m4; it would not contain the autoconf/autoheader tools themselves. To a rather different point, do we need aclocal.m4 at all? This is the log for aclocal.m4: r34284 | anthonybaxter | 2003-09-27 11:12:27 +0200 (Sat, 27 Sep 2003) | 5 lines fix for bug #811160 - autoconf vs. hp/ux system header files. also applied to release23-maint. Note that aclocal.m4 can go away when autoconf 2.58 is out. I think 2.58 actually had a brown-paper-bag release style bug, but 2.59 has been out for ages now. If we were prepared to AC_PREREQ(2.59), I think this whole issue could go away. Cheers, mwh -- Finding a needle in a haystack is a lot easier if you burn down the haystack and scan the ashes with a metal detector. -- the Silicon Valley Tarot (another one nicked from David Rush) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Michael Hudson wrote: I think 2.58 actually had a brown-paper-bag release style bug, but 2.59 has been out for ages now. If we were prepared to AC_PREREQ(2.59), I think this whole issue could go away. It seems you are right, so I removed the file, and require ac 2.59. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
On 1/28/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Thomas Heller wrote: Can anyone of the python-dev core team comment: can we live with the GPL licensed aclocal.m4 file, in the source distribution and in SVN? My understanding that doing so would be in violation of section 2b) of the GPL. However, I still think it is possible to include libffi - we just have to discard the build process, and do our own. I did some work to make ctypes+libffi compacter and liberal. http://openlook.org/svnpublic/ctypes-compactffi/ (svn) I removed sources/gcc and put sources/libffi copied from gcc 4.0.2. And removed all automake-related build processes and integrated them into setup.py. There's still aclocal.m4 in sources/libffi. But it is just identical to libffi's acinclude.m4 which looks liberal. Hye-Shik ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Martin v. Löwis [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Michael Hudson wrote: I think 2.58 actually had a brown-paper-bag release style bug, but 2.59 has been out for ages now. If we were prepared to AC_PREREQ(2.59), I think this whole issue could go away. It seems you are right, so I removed the file, and require ac 2.59. Does this mean that ctypes can and will be included with 2.5? If so, hoorays from many people. And by the way, I agree that willfully or carelessly irritating FSF is a bad idea. Terry J Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Hye-Shik Chang wrote: I did some work to make ctypes+libffi compacter and liberal. http://openlook.org/svnpublic/ctypes-compactffi/ (svn) I removed sources/gcc and put sources/libffi copied from gcc 4.0.2. And removed all automake-related build processes and integrated them into setup.py. There's still aclocal.m4 in sources/libffi. But it is just identical to libffi's acinclude.m4 which looks liberal. Well done! Would you like to derive a Python patch from that? Don't worry about MSVC, yet, I will do that once the sources are in the subversion. (Of course, for due process, it would be better if this code gets integrated into the official ctypes first, and then we incorporate some named/versioned snapshot into /external, and svn cp it into python/trunk from there). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Terry Reedy wrote: I think 2.58 actually had a brown-paper-bag release style bug, but 2.59 has been out for ages now. If we were prepared to AC_PREREQ(2.59), I think this whole issue could go away. It seems you are right, so I removed the file, and require ac 2.59. Does this mean that ctypes can and will be included with 2.5? No; as Michael Hudson said: this is an entirely unrelated issue, with Python's aclocal.m4 (which I deleted). It just occurred to him that this had TODOs as well (from a technological view, not from a licensing view). However, Hye-Shik Chan is to praise for looking into the libffi build process. So there is still a good chance that ctypes will be in 2.5 (if he or somebody else follows up). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Hye-Shik Chang [EMAIL PROTECTED] writes: On 1/28/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Thomas Heller wrote: Can anyone of the python-dev core team comment: can we live with the GPL licensed aclocal.m4 file, in the source distribution and in SVN? My understanding that doing so would be in violation of section 2b) of the GPL. However, I still think it is possible to include libffi - we just have to discard the build process, and do our own. I did some work to make ctypes+libffi compacter and liberal. http://openlook.org/svnpublic/ctypes-compactffi/ (svn) I removed sources/gcc and put sources/libffi copied from gcc 4.0.2. And removed all automake-related build processes and integrated them into setup.py. There's still aclocal.m4 in sources/libffi. But it is just identical to libffi's acinclude.m4 which looks liberal. That's great! Would you like to integrate these changes into to ctypes CVS repository yourself? I indend to do a few releases still from there, before the first Python 2.5. If so, please tell me your SF username and I'll add you as developer. Also, please note that all work should be done on the 'branch_1_0' CVS branch - the HEAD is only experimental code (and not currently used). Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Bill Northcott wrote: Quite so, but using the autotools does NOT include any GPL code in the resulting program. Hmm. Please take a look at http://cvs.sourceforge.net/viewcvs.py/*checkout*/ctypes/ctypes/source/gcc/libffi/aclocal.m4?rev=1.1.4.1 This file contains a large number of licensing text blocks, many of which read # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2, or (at your option) # any later version. So it seems to me that this specific generated aclocal.m4 *does* include GPL code. So this does not apply. All that is needed is to include in the source distribution a copy of GPL, note that GPL applies to some files in the sources and ensure that copyright notices at the heads of GPL files are intact. If nothing in the generated files is licensed under the terms of the GPL, why would it be necessary to include a copy of the GPL? The compiler needs specific exemptions because parts of the GPLed runtime libraries are included in all compiled code. No part of the autotools ends up in the finished code. If it did, you would need m4 to run Python and you don't. It doesn't matter whether it ends up in the finished code: if the aclocal.m4 is indeed GPL-licensed, then the entire Python source distribution must be GPL-licensed, because it contains or is derived from the Program or any part thereof. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
On Fri, 2006-01-27 at 18:03 +0100, Thomas Heller wrote: [I've added python-dev to cc:] Anthony Green [EMAIL PROTECTED] writes: On Fri, 2006-01-27 at 17:08 +0100, Thomas Heller wrote: Anyway, another question is: Is aclocal.m4 needed at all for building (or maybe for regenerating the configure scripts), or is it optional? aclocal.m4 is required, but is only used as a build-time tool. The fact that aclocal.m4 is distributed under the GPL should have no impact on the licensing terms used for software built using aclocal.m4. If I understand correctly this means that the Python source distribution would have to be GPL licensed, while the built programs would be able to use another license. I'm pretty sure this kills the whole idea (to include libffi in python). I guess I wasn't clear. aclocal.m4 is just a tool used to build libffi. Like your C compiler. Bundling it with the Python source distribution should have no impact on the licensing of Python itself, since it isn't really part of the resulting Python binary - just like your C compiler isn't. AG ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Giovanni == Giovanni Bajo [EMAIL PROTECTED] writes: Giovanni This would be a new interpretation of the license. The whole Giovanni autotools chain is GPL and it is used on way too many Giovanni programs which are not GPL. They're so many I won't even Giovanni mention one. Anyway, IANAL, so if you're really concerned Giovanni you can mail the FSF and ask clarifications. No, Martin is correct about this. The output of autoconf is explicitly *not* under the GPL, by design. This is also true for the m4 macros from automake -- again, an explicit decision. The problem is, some other projects have not been so careful. Tom ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
On Jan 27, 2006, at 1:32 PM, Thomas Heller wrote: I guess I understood this already. The difference to the C compiler is that the compiler is not 'bundled' with Python, it is installed separately. Can anyone of the python-dev core team comment: can we live with the GPL licensed aclocal.m4 file, in the source distribution and in SVN? Does phython already use autoconf? I think it does, if so then there should be no issues. -- Pinski ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Martin == Martin v Löwis [EMAIL PROTECTED] writes: Martin Instead, it means we need a build process for libffi which is Martin independent of autoconf (or convince the authors of aclocal.m4 to Martin relicense it, but that is likely futile). Martin As a matter of fact, Python itself uses autoconf, but without Martin aclocal.m4. autoconf generates configure for us, but configure is Martin not GPL-licensed, even though it is generated through autoconf: Martin # Copyright (C) 2003 Free Software Foundation, Inc. Martin # This configure script is free software; the Free Software Foundation Martin # gives unlimited permission to copy, distribute and modify it. libffi's aclocal.m4 is created by the aclocal tool, which stitches it together from different .m4 files it finds. For m4 files that are part of the automake distribution, the intent was explicitly to have the same more liberal permissions that apply to 'configure'. If you can't find a statement saying this somewhere, then I believe that to be a bug (I see one at the top of aclocal.m4 FWIW -- this applies to all the automake-shipped m4 files). I know I explicitly brought this up with RMS at some point in the distant past and got the needed permissions to make this so. However, libffi probably also uses macros from other places -- at least GCC and libtool. I don't know the legal status of these. The GCC macros are probably not really necessary for your situation. The libffi configury in the GCC tree is set up to build libffi as a target library. Most likely, you don't need this. libffi/acinclude.m4 needs some license clarification. It isn't clear who owns this code :-( I think a real fix is probably not out of reach, should you wish to pursue it. Tom ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
On 28/01/2006, at 10:41 AM, Martin v. Löwis wrote: You misunderstand the GPL. Section 2b) is pretty clear that any application that contains GPL-licensed code must be, itself, distributed under the terms ofthe GPL Quite so, but using the autotools does NOT include any GPL code in the resulting program. So this does not apply. All that is needed is to include in the source distribution a copy of GPL, note that GPL applies to some files in the sources and ensure that copyright notices at the heads of GPL files are intact. The compiler needs specific exemptions because parts of the GPLed runtime libraries are included in all compiled code. No part of the autotools ends up in the finished code. If it did, you would need m4 to run Python and you don't. Cheers Bill Northcott ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Andrew Pinski wrote: Does phython already use autoconf? I think it does, if so then there should be no issues. Yes, but your conclusion is wrong. Python uses autoconf, but not aclocal/automake. The generated configure is explicitly not covered by the GPL; the status of the generated aclocal.m4 is unclear (it says it is GPL'ed; it also says it isn't). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Anthony Green [EMAIL PROTECTED] writes: On Fri, 2006-01-27 at 18:03 +0100, Thomas Heller wrote: [I've added python-dev to cc:] Anthony Green [EMAIL PROTECTED] writes: On Fri, 2006-01-27 at 17:08 +0100, Thomas Heller wrote: Anyway, another question is: Is aclocal.m4 needed at all for building (or maybe for regenerating the configure scripts), or is it optional? aclocal.m4 is required, but is only used as a build-time tool. The fact that aclocal.m4 is distributed under the GPL should have no impact on the licensing terms used for software built using aclocal.m4. If I understand correctly this means that the Python source distribution would have to be GPL licensed, while the built programs would be able to use another license. I'm pretty sure this kills the whole idea (to include libffi in python). I guess I wasn't clear. aclocal.m4 is just a tool used to build libffi. Like your C compiler. Bundling it with the Python source distribution should have no impact on the licensing of Python itself, since it isn't really part of the resulting Python binary - just like your C compiler isn't. I guess I understood this already. The difference to the C compiler is that the compiler is not 'bundled' with Python, it is installed separately. Can anyone of the python-dev core team comment: can we live with the GPL licensed aclocal.m4 file, in the source distribution and in SVN? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Thomas Heller [EMAIL PROTECTED] wrote: On Fri, 2006-01-27 at 17:08 +0100, Thomas Heller wrote: Anyway, another question is: Is aclocal.m4 needed at all for building (or maybe for regenerating the configure scripts), or is it optional? aclocal.m4 is required, but is only used as a build-time tool. The fact that aclocal.m4 is distributed under the GPL should have no impact on the licensing terms used for software built using aclocal.m4. If I understand correctly this means that the Python source distribution would have to be GPL licensed, while the built programs would be able to use another license. I'm pretty sure this kills the whole idea (to include libffi in python). I guess I wasn't clear. aclocal.m4 is just a tool used to build libffi. Like your C compiler. Bundling it with the Python source distribution should have no impact on the licensing of Python itself, since it isn't really part of the resulting Python binary - just like your C compiler isn't. I guess I understood this already. The difference to the C compiler is that the compiler is not 'bundled' with Python, it is installed separately. That's no different. If you burn a CD containing a copy of the GCC and a copy of a commercial software you are not violating any license. If you distribute an .ISO file containing a copy of the GCC and a copy of a commercial software, you are not violating any license. If you distribute a .zip file containing a copy of GCC and a copy of a commercial software, you are not violating any license. There is an important difference between aggreggation of different programs, and static/dynamic linking of parts. Autoconf is a build tool, and it does not impose any license on the software you use it with. Plus some files have the special exception from GPL so that even the files *generated* by autoconf (and partly made of pieces of autoconf) do not require to be GPL. This is exactly like GCC's runtime library (libgcc, and also libstdc++) which are GPL with the special exception, and you can use them also for commercial products. Also, do not understimate previous history. There are zillions of programs out there using Autconf and *not* being GPL. -- Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Andrew Pinski [EMAIL PROTECTED] writes: Does phython already use autoconf? I think it does, if so then there should be no issues. [Anthony Green] I guess I wasn't clear. aclocal.m4 is just a tool used to build libffi. Like your C compiler. Bundling it with the Python source distribution should have no impact on the licensing of Python itself, since it isn't really part of the resulting Python binary - just like your C compiler isn't. [Thomas Heller] I guess I understood this already. The difference to the C compiler is that the compiler is not 'bundled' with Python, it is installed separately. Giovanni Bajo [EMAIL PROTECTED] writes: That's no different. If you burn a CD containing a copy of the GCC and a copy of a commercial software you are not violating any license. If you distribute an .ISO file containing a copy of the GCC and a copy of a commercial software, you are not violating any license. If you distribute a .zip file containing a copy of GCC and a copy of a commercial software, you are not violating any license. There is an important difference between aggreggation of different programs, and static/dynamic linking of parts. Autoconf is a build tool, and it does not impose any license on the software you use it with. Plus some files have the special exception from GPL so that even the files *generated* by autoconf (and partly made of pieces of autoconf) do not require to be GPL. This is exactly like GCC's runtime library (libgcc, and also libstdc++) which are GPL with the special exception, and you can use them also for commercial products. Also, do not understimate previous history. There are zillions of programs out there using Autconf and *not* being GPL. Ok, understood - there is no problem. Hopefully the rest of the pythondev team is also convinced. The only question I have (maybe this is too off-topic, but since we're here already): Nearly all the tools that autoconf and automake use are careful to include an exception clause to the GPL license. Why is aclocal.m4 different? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Thomas Heller wrote: Can anyone of the python-dev core team comment: can we live with the GPL licensed aclocal.m4 file, in the source distribution and in SVN? My understanding that doing so would be in violation of section 2b) of the GPL. However, I still think it is possible to include libffi - we just have to discard the build process, and do our own. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Giovanni Bajo wrote: That's no different. If you burn a CD containing a copy of the GCC and a copy of a commercial software you are not violating any license. If you distribute an .ISO file containing a copy of the GCC and a copy of a commercial software, you are not violating any license. If you distribute a .zip file containing a copy of GCC and a copy of a commercial software, you are not violating any license. You misunderstand the GPL. Section 2b) is pretty clear that any application that contains GPL-licensed code must be, itself, distributed under the terms ofthe GPL b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. It further elaborates (in 2, below c) that you could distribute identifiable sections of [your] work [which] are not derived from the Program separately, as long as you omit the Program. But if you distribute them as a whole, the whole must be licensed under the GPL. There is an important difference between aggreggation of different programs, and static/dynamic linking of parts. There is an exception for mere aggregation: # In addition, mere aggregation of another work not based on the Program # with the Program (or with a work based on the Program) on a volume of # a storage or distribution medium does not bring the other work under # the scope of this License. However, inclusion of aclocal.m4 isn't mere aggregation [...] on a volume of storage. aclocal.m4 is an essential part of the software as a whole, so 2b) applies. Also, do not understimate previous history. There are zillions of programs out there using Autconf and *not* being GPL. Yes, and SCO is (rightly, IMO) complaining that zillions of open source people do not honor IP properly. That doesn't mean Python should follow. Instead, it means we need a build process for libffi which is independent of autoconf (or convince the authors of aclocal.m4 to relicense it, but that is likely futile). As a matter of fact, Python itself uses autoconf, but without aclocal.m4. autoconf generates configure for us, but configure is not GPL-licensed, even though it is generated through autoconf: # Copyright (C) 2003 Free Software Foundation, Inc. # This configure script is free software; the Free Software Foundation # gives unlimited permission to copy, distribute and modify it. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Thomas Heller [EMAIL PROTECTED] wrote: Andrew Pinski [EMAIL PROTECTED] writes: Does phython already use autoconf? I think it does, if so then there should be no issues. [Anthony Green] I guess I wasn't clear. aclocal.m4 is just a tool used to build libffi. Like your C compiler. Bundling it with the Python source distribution should have no impact on the licensing of Python itself, since it isn't really part of the resulting Python binary - just like your C compiler isn't. [Thomas Heller] I guess I understood this already. The difference to the C compiler is that the compiler is not 'bundled' with Python, it is installed separately. Giovanni Bajo [EMAIL PROTECTED] writes: That's no different. If you burn a CD containing a copy of the GCC and a copy of a commercial software you are not violating any license. If you distribute an .ISO file containing a copy of the GCC and a copy of a commercial software, you are not violating any license. If you distribute a .zip file containing a copy of GCC and a copy of a commercial software, you are not violating any license. There is an important difference between aggreggation of different programs, and static/dynamic linking of parts. Autoconf is a build tool, and it does not impose any license on the software you use it with. Plus some files have the special exception from GPL so that even the files *generated* by autoconf (and partly made of pieces of autoconf) do not require to be GPL. This is exactly like GCC's runtime library (libgcc, and also libstdc++) which are GPL with the special exception, and you can use them also for commercial products. Also, do not understimate previous history. There are zillions of programs out there using Autconf and *not* being GPL. Ok, understood - there is no problem. Hopefully the rest of the pythondev team is also convinced. The only question I have (maybe this is too off-topic, but since we're here already): Nearly all the tools that autoconf and automake use are careful to include an exception clause to the GPL license. Why is aclocal.m4 different? Is aclocal.m4 even GPL in the first place? I don't see such a notice in my libffi copy. Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Martin v. Löwis [EMAIL PROTECTED] wrote: Can anyone of the python-dev core team comment: can we live with the GPL licensed aclocal.m4 file, in the source distribution and in SVN? My understanding that doing so would be in violation of section 2b) of the GPL. This would be a new interpretation of the license. The whole autotools chain is GPL and it is used on way too many programs which are not GPL. They're so many I won't even mention one. Anyway, IANAL, so if you're really concerned you can mail the FSF and ask clarifications. BTW, by your reading, libffi itself would be a GPL violation. Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (libffi) Re: Copyright issue
Giovanni Bajo wrote: This would be a new interpretation of the license. The whole autotools chain is GPL and it is used on way too many programs which are not GPL. They're so many I won't even mention one. Anyway, IANAL, so if you're really concerned you can mail the FSF and ask clarifications. No. As Tom Tromey explains, significant parts of autoconf have a special exception, allowing parts of autoconf to be used without any restrictions when they get copied into, say, configure. If you only use those parts of autoconf, you don't violate the GPL. However, it appears that (at least parts of) aclocal.m4 originate from code which doesn't have such a liberal license. BTW, this interpretation isn't new at all. I first heard it in 1992. People tend to reinterpret it because they can't believe the original words, and then those interpretations become urban myth. BTW, by your reading, libffi itself would be a GPL violation. Well, no. I interpret it to be dual-licensed: Identifiable parts of it are independent work, and can be licensed independently of the Program (i.e. autoconf). They meet all requirements of the GPL (providing all code they need to provide) - it's just difficult to find out what the license is. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
