Re: [Python-Dev] (libffi) Re: Copyright issue
Bill Northcott wrote: > 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. Again: What matters is what ends up in the source distribution, http://www.python.org/ftp/python/2.4/Python-2.4.tgz The source distribution would contain aclocal.m4; it would not contain the autoconf/autoheader tools themselves. The configure script is *NOT* under GPL, it explicitly says # 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. Likewise, the Makefile.in is not under GPL, either: Makefile.in says # Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, # 2003, 2004 Free Software Foundation, Inc. # This Makefile.in is free software; the Free Software Foundation # gives unlimited permission to copy and/or distribute it, # with or without modifications, as long as this notice is preserved. > 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. See, and this is precisely the difference. The word processor doesn't end up in the distributed book. However, aclocal.m4 ends up in the source distribution. > I can happily package appropriately licensed copies of the word > processing software with the finished book. Right: "appropriately licensed". Whether you *actually* can do this depends on the license of the word processor. For example, if the license says "not for resale", you cannot do this - even if you are, yourself, licensed to use the copy you got. So do I have permission to distribute copies of aclocal.m4? Yes, the GPL allows this. Does it put additional obligations in doing so? Yes, it does: 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. Is (a future) Python-2.5.tgz "work that I distribute or publish"? Yes, it is. Does it "in whole or in part contain" "the Program or any part thereof"? Yes, it does. So I must "cause" Python-2.5.tgz "to be licensed as whole at no charge to all third parties under the terms of" the GPL. > A Python binary is no more derived from the autotools than the book is > derived from the word processing software. No, the Python binary isn't. The Python source is. Regards, Martin ___ Python-Dev mailing list [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
