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] SourceForge Download Page, Subversion Home Page
Nick Coghlan wrote: Is it possible to make that URL a hyperlink? No, all HTML gets stripped/quoted as text. The Python programming language, an object-oriented scripting and rapid application development language. Despite what the green button below says, you can bNOT/b download it directly from Sourceforge, as SF is used only for bug tracking. You can get releases from the main Python website: Sorry, no HTML allowed there. I created a support request to change/remove the button at http://sourceforge.net/tracker/index.php?func=detailaid=1417298group_id=1atid=21 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] / as path join operator
Stephen J. Turnbull wrote: Jason Filesystem paths are in fact strings on all operating Jason systems I'm aware of. I have no idea what you could mean by that. The data structure used to represent a filesystem on all OS filesystems I've used is a graph of directories and files. A filesystem object is located by traversing a path in that graph. Of course there's a string representation, especially for human use if you define everything that can be identified by one or more well-defined strings as a string, everything is a string. /F ___ 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
On 28-jan-2006, at 0:53, Martin v. Löwis wrote: Ronald Oussoren wrote: Merging the two configure files might be a good idea anyway, that would take away the need to run configure from setup.py. IANAL, but I don't quite get how a GPL'd support script, if there is such a thing, in the build machinery of an extension library would require that Python itself is GPL'd. Section 2b) of the GPL. If a part of the program is GPL, the entire program must be. Also, you must include the entire source of the program, including all build scripts (section 3). So just including the generated configure, and omitting some of its input, would also be a license violation. You have a point there. I'm not entirely convinced though, the argument that Python would be a derived work of libffi's aclocal.m4 when libffi were included in the Python repository seems very weak to me. It is a good argument to just drop libffi's configure script and integrate the functionality of it in the main python configure script. That would remove all possible doubt and shouldn't be too much work. 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. Ronald Regards, Martin smime.p7s Description: S/MIME cryptographic signature ___ 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] stabilizing builds
Thomas Wouters wrote: I'd need developer access back to check it in, though. Unless anyone objects, of course :) I copied ~/thomas/authorized_keys to ~pythondev/keys/thomas.wouters, changed ownership/permissions, and ran make_authorized_keys in the pythondev account. So you should have access now. 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
Ronald Oussoren wrote: You have a point there. I'm not entirely convinced though, the argument that Python would be a derived work of libffi's aclocal.m4 when libffi were included in the Python repository seems very weak to me. The GPL says contains or is derived from. Clearly, identifiable parts of Python are not derived from aclocal.m4. However, the work as a whole (i.e. the entire Python distribution) then becomes derived work of libffi, and aclocal.m4. It is a good argument to just drop libffi's configure script and integrate the functionality of it in the main python configure script. That would remove all possible doubt and shouldn't be too much work. Several autoconf people have argued that this aclocal.m4 is a mistake, and that the intention was that it shouldn't be GPL-licensed. So if we cannot find a volunteer to rewrite the build process of libffi for use in Python, that would also be a strategy (but one that probably takes many months to complete). I would personally drop the use of automake (and just rely on autoconf), and then the need for aclocal would go away. 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. This is the question what constitutes derivative work, and different lawyers have said different things in the past. If we really want to find out, we should ask a lawyer. IANAL, and my understanding is that a) we don't include readline in the Python distribution, so the Python source code cannot be derivative work. In U.S. copyright law, the term is apparently defined as any . . . work [that] may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications which, as a whole, represents an original work of authorship, is a 'derivative work.' http://www.chillingeffects.org/derivative/ I would argue that Modules/readline.c does *not* represent the original work of authorship (i.e. libreadline). Of course, the GPL says derived, not derivative, and doesn't define the term, so you should ask your lawyer; ultimately, a court might decide what it means. b) if we were to distribute binaries of Python, this issue would yet again be different: it seems that a binary readline module (builtin or not) is derivative work of the readline library, whether it is dynamically linked with that library or not. So anybody distributing such a binary might have to distribute it under the terms of the GPL. I say might because there is an exception in the GPL for major components normally distributed with the operating system. On those systems where Python's readline module is available, the readline library could be considered a part of the operating system. To be sure, ask your lawyer; ultimately, a court might decide whether this clause is relevant here. 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] Path inherits from string
BJörn Lindqvist [EMAIL PROTECTED] writes: [M.-A. Lemburg] I don't see why this is critical for the success of the Path object. I agree with Thomas that interfaces should be made compatible to Path object. See the steps I mentioned. Unless step #1 is completed there is no way to make the following code work: open(Path(foobar)) Well, there is one alternative which is: open(Path(foobar).tostring()) And that is a Java-esque workaraound that I think noone would be happy with. Now maybe I'm missing context here but: what on earth are you talking about? Of course there's a way to make open(Path(foobar)) work -- you change how the builtin open() works. This post is not intended as arguing for or against anything, except technical accuracy. Cheers, mwh -- Richard Gabriel was wrong: worse is not better, lying is better. Languages and systems succeed in the marketplace to the extent that their proponents lie about what they can do. -- Tim Bradshaw, comp.lang.lisp ___ 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] SourceForge Download Page, Subversion Home Page
Steve Holden [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] You may be aware that Tim Parkin's work on our next-generation web presence has borne fruit in the shape of beta.python.org. While there's still a lot to be done Tim has given us a great start by creating a framework that makes it rather easier to manage content. For the record, I'm just a user of the language. However, I tend to prefer the current site design over the new one. But I also felt the same way when the Mozilla.org site was updated to be more 'friendly' (quite a while ago), and have learned to live with it, so it is not a major problem. There's the further issue that the entire HTML body of http://svn.python.org/ currently reads !-- not sure what to put here -- It would seem like the logical place to have pointers to Subversion software (downloads, documentation, operating instructions) together with an *annotated* summary of http://svn.python.org/projects/ and links back to the main developer site at the very least. I'm not even sure where that web content is under SVN control at the moment. Also If there is any sort of webcvs software running, it may be ice to link to it from that page. ___ 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
