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] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
Martin == Martin v Löwis [EMAIL PROTECTED] writes: BTW. The argument that the readline module should be GPL licensed seems rather stronger, it's designed to work with a GPL-ed library and doesn't work with a BSD licensed work-alike of that library. Martin This is the question what constitutes derivative work, and Martin different lawyers have said different things in the Martin past. If we really want to find out, we should ask a Martin lawyer. You also need to ask about the cost of defending against a lawsuit by the FSF, which is both the copyright holder of the library and the primary advocate of the interpretation that a work which is intended to be linked with another work is a derivative. I think the FSF pretty much would have to fight any claims that contest its interpretation of the concept of derived work, because any interpretation that requires a direct source-to-source copy will make the GPL irrelevant. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can do free software business; ask what your business can do for free software. ___ 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] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
Stephen J. Turnbull wrote: You also need to ask about the cost of defending against a lawsuit by the FSF, which is both the copyright holder of the library and the primary advocate of the interpretation that a work which is intended to be linked with another work is a derivative. I think the FSF pretty much would have to fight any claims that contest its interpretation of the concept of derived work, because any interpretation that requires a direct source-to-source copy will make the GPL irrelevant. So would you just like to see the readline module to be removed from the Python distribution? I personally don't, because I don't believe that the status quo conflicts with FSF's interpretation of the GPL, atleast not wrt. to anything the PSF does (i.e. source and Windows distribution). Also, I firmly believe that the FSF would *not* sue the PSF, but instead first ask that the status is corrected. Notice that the LGPL 2.1 somewhat elaborates on what the FSF considers derived wrt. linking: # When a program is linked with a library, whether statically or using a # shared library, the combination of the two is legally speaking a # combined work, a derivative of the original library. The ordinary # General Public License therefore permits such linking only if the # entire combination fits its criteria of freedom. So it is the act of linking (and probably to some extent, the act of compiling) that creates the derivative work. 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] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
[Martin v. Löwis] ... Also, I firmly believe that the FSF would *not* sue the PSF, but instead first ask that the status is corrected. I'd say that's almost certain. Like any organization with something fuzzy to protect, the FSF has far more to lose than to gain by daring a court to rule on their beliefs. Of course the PSF is in a similar boat: both parties would view a lawsuit as a rock-bottom last resort. I'm one PSF Director who would vote to capitulate in an instant to avoid fighting the FSF over readline, and not because of legal arguments, but because I respect their wishes about how _their_ work can be used. OTOH, in the absence of a statement from the FSF that they're unhappy about Python's readline module, I wouldn't yank it just to avoid a theoretical possibility that the FSF might complain someday. ___ 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] Extension to ConfigParser
Fuzzyman fuzzyman at voidspace.org.uk writes: In the past there has been some discussion about a new module to replace ConfigParser. Most notably at http://wiki.python.org/moin/ConfigParserShootout [snip] It would be possible to extend to the ConfigObj API to be backwards compatible with ConfigParser. This would bring the added benefits of ConfigObj, without needing to add an extra module to the standard library. Well nearly. ConfigObj supports config file schema with (optional) type conversion, through a companion module called validate. This could be included or left as an added option. Anyway. If this stands a *chance* of acceptance, I'll write the PEP (and if accepted, do the work - which is not inconsiderable). Personally, I'd prefer to have the different candidates in the Shootout be evaluated and a winner picked (I'm not sure who would do this, or when it would be done). I'll readily declare an interest - I've implemented an alternative hierarchical config module (which is in no way backward compatible with ConfigParser), see http://www.red-dove.com/python_config.html Regards, Vinay Sajip ___ 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] SourceForge Download Page, Subversion Home Page
On Sat, 2006-01-28 at 19:46 +0100, Martin v. Löwis wrote: Barry Warsaw favours Jira as a tracker. Still do! At at one time the Atlassian folks offered to help us import the SF tracker data into Jira if we could get a machine readable (hopefully XML-ish) dump of the current SF tracker data. I don't know if that offer still stands, but if Jira were in the running I would contact them again about it. -Barry signature.asc Description: This is a digitally signed message part ___ 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] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
Martin == Martin v Löwis [EMAIL PROTECTED] writes: Martin So would you just like to see the readline module to be Martin removed from the Python distribution? No. I would much prefer that the readline module be made compatible with libedit (or whatever the pseudo-readline library is called) and that is what I recommend in the short term. Alternatively, libedit should be made more completely compatible with libreadline. In the long term, I would like to see your interpretation established in law (either by legislation or by precedent), but I certainly don't want any precedent set by having the PSF and the FSF at odds with each other. Martin So it is the act of linking (and probably to some extent, Martin the act of compiling) that creates the derivative work. The FSF did not accept that position when Aladdin advanced it in the case of Ghostscript. Cf. my reply to Tim Peters. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can do free software business; ask what your business can do for free software. ___ 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
