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 [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
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 NOT 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=detail&aid=1417298&group_id=1&atid=21 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] / 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. ___ 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
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 [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] 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 [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
Martin v. Löwis wrote: > Sorry, no HTML allowed there. > > I created a support request to change/remove the button at > > http://sourceforge.net/tracker/index.php?func=detail&aid=1417298&group_id=1&atid=21 instead of spending more time and creativity on a sourceforge account that's only used for tracking, how about moving the trackers to python.org ? there are at least two "powered-by-python" alternatives that are vastly better than source-forge's tracker: roundup, which just went 1.0: http://cheeseshop.python.org/pypi/roundup/1.0 and trac, http://www.edgewall.com/trac/ which almost everyone is using these days... ___ 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
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 [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] 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
[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 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 [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
> "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 [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 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 [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" == 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 [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 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 [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
Fredrik Lundh wrote: > instead of spending more time and creativity on a sourceforge account > that's only used for tracking, how about moving the trackers to python.org ? That's an old plan. It failed so far because no volunteer ever appeared to make it happen (actually, some did appear, but didn't actually make it happen). Notice that any such moving would have to carry over the existing tracker items; any volunteer should be available for hand-holding after the move occurs. Groups of people would be better than individual volunteers. > there are at least two "powered-by-python" alternatives that are vastly > better than source-forge's tracker: roundup, which just went 1.0: > > http://cheeseshop.python.org/pypi/roundup/1.0 Guido's preference is on roundup. > and trac, > > http://www.edgewall.com/trac/ > > which almost everyone is using these days... Barry Warsaw favours Jira as a tracker. 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
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 [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] / as path join operator
Stephen J. Turnbull: > 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, Not always. IIRC very old MacOS used an integer directory ID and a string file name. The directory ID was a cookie that you received from the UI and passed through to the file system and there was little support for manipulating the directory ID. Textualized paths were never supposed to be shown to users. Neil ___ 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
"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 > > > > 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 [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] Path inherits from string
> > 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.
That's what I said: Someone has to make the required modifications to
the Python core. Changing how open() works would AFAIK be a
modification to the Python core. open() was just an example and
changing only how open() works would not be sufficient I think.
__import__(), execfile() and third party extensions implemented in C
would also have to be modified so that they treat Path("foobar")
equivalent to "foobar."
--
mvh Björn
___
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
