Tim == Tim Peters [EMAIL PROTECTED] writes:
Tim I'm not making myself clear.
Whatever makes you think that?wink In fact, everything you've said
about your criteria for behavior was quite clear from the first, and
it was fairly easy to infer your beliefs about the implications of
history.
I
On Mon, 2006-01-30 at 16:44 -0500, Tim Peters wrote:
OTOH, I have no reason to _presume_ that this is their hoped-for
outcome wrt Python, neither to presume that the politics shaping their
tussle with Aladdin are relevant to the PSF. The law is rarely
applied uniformly, in large part because
Tim == Tim Peters [EMAIL PROTECTED] writes:
Tim [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.
They would ask first. That's what they did in the case of Aladdin
Ghostscript's use of readline.
Rather than the back-n-forth about what the FSF might or might not do,
can we just ask them for an official opinion and settle the matter?
The Aladdin case makes me think we should do this, probably before 2.5
comes out - because if we do have to yank readline, I'd really not
like to see this
Anthony Baxter wrote:
Rather than the back-n-forth about what the FSF might or might not do,
can we just ask them for an official opinion and settle the matter?
Who would we need to talk to for a definitive answer? I'm sure there's
various FSF mailing lists where we could get 157 different
[Stephen J. Turnbull]
...
Aladdin took a position similar to Martin's, and only yanked the
offending Makefile stanza when the FSF called them and said we're
ready to go to court; are you?
...
It's not theoretical; it's almost identical to the Aladdin case.
Legally the PSF is, if anything,
On Mon, Jan 30, 2006 at 04:44:47PM -0500, Tim Peters wrote:
Python is a high-profile project that hasn't been hiding its readline
module, and if I presume anything here it's that the FSF would have
complained by now if they really didn't want this.
In fact, we can be absolutely certain the
Anthony Baxter wrote:
Rather than the back-n-forth about what the FSF might or might not do,
can we just ask them for an official opinion and settle the matter?
We can ask, sure. Whether this settles the matter depends on the
answer.
Regards,
Martin
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
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
[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
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
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
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
John J Lee [EMAIL PROTECTED] writes:
On Thu, 26 Jan 2006, Thomas Heller wrote:
[...]
As I said in the other thread (where the discussion should probably be
continued anyway):
http://mail.python.org/pipermail/python-dev/2006-January/060113.html
only aclocal.m4 isn't clear to me about
On 27-jan-2006, at 17:14, Thomas Heller wrote:
John J Lee [EMAIL PROTECTED] writes:
On Thu, 26 Jan 2006, Thomas Heller wrote:
[...]
As I said in the other thread (where the discussion should
probably be
continued anyway):
On Fri, 27 Jan 2006, Thomas Heller wrote:
John J Lee [EMAIL PROTECTED] writes:
On Thu, 26 Jan 2006, Thomas Heller wrote:
only aclocal.m4 isn't clear to me about the license. Anyway, it could
be that this file isn't needed after all - I don't know enough about the
GNU toolchain to be
Thomas == Thomas Heller [EMAIL PROTECTED] writes:
Thomas I cannot uinderstand your reasoning. How can 'info
Thomas autoconf' incluence the license of the aclocal.m4 file?
It doesn't. The point is the documentation explains that all of the
other files are _part of autoconf_, and come
Stephen J. Turnbull wrote:
Otherwise, not using the distributed aclocal.m4 may be possible, but
it's a bad idea.
That may not be so bad, actually. It looks like libffi's aclocal.m4
is not hand-written, but generated through aclocal(1). Not sure why
this is done, but this seems to be the cause
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
Tony Meyer [EMAIL PROTECTED] writes:
-
Adding ctypes to the standard library
-
Thomas Heller suggested that ctypes be included in core Python
(starting with 2.5). The common response was that while ctypes is a
useful,
On Thu, Jan 26, 2006 at 09:54:51AM +0100, Thomas Heller wrote:
The current state is that ctypes uses GPL'd tools to build libffi, and
those can't be committed into Python SVN.
http://mail.python.org/pipermail/python-dev/2006-January/059937.html
But
Thomas Wouters [EMAIL PROTECTED] writes:
On Thu, Jan 26, 2006 at 09:54:51AM +0100, Thomas Heller wrote:
The current state is that ctypes uses GPL'd tools to build libffi, and
those can't be committed into Python SVN.
http://mail.python.org/pipermail/python-dev/2006-January/059937.html
But
On 26-jan-2006, at 13:29, Thomas Heller wrote:
Thomas Wouters [EMAIL PROTECTED] writes:
On Thu, Jan 26, 2006 at 09:54:51AM +0100, Thomas Heller wrote:
The current state is that ctypes uses GPL'd tools to build
libffi, and
those can't be committed into Python SVN.
On Jan 26, 2006, at 7:29 AM, Thomas Heller wrote:
And licenses are fluid, it may be a piece of cake to
get one of those 'tools' un-GPL'ed, even if they are.
I wouldn't even know whom to ask.
On Jan 26, 2006, at 9:22 AM, Ronald Oussoren wrote:
It shouldn't be too hard to use Python's main
On 26-jan-2006, at 18:04, James Y Knight wrote:
On Jan 26, 2006, at 7:29 AM, Thomas Heller wrote:
And licenses are fluid, it may be a piece of cake to
get one of those 'tools' un-GPL'ed, even if they are.
I wouldn't even know whom to ask.
On Jan 26, 2006, at 9:22 AM, Ronald Oussoren
On 26-jan-2006, at 16:33, Thomas Heller wrote:
Ronald Oussoren [EMAIL PROTECTED] writes:
On 26-jan-2006, at 13:29, Thomas Heller wrote:
Thomas Wouters [EMAIL PROTECTED] writes:
On Thu, Jan 26, 2006 at 09:54:51AM +0100, Thomas Heller wrote:
The current state is that ctypes uses GPL'd
Ronald Oussoren [EMAIL PROTECTED] writes:
On Jan 26, 2006, at 9:22 AM, Ronald Oussoren wrote:
It shouldn't be too hard to use Python's main configure script to
calculate the information necessary to build libffi. A lot of it is
already calculated anyway (sizeof various type, endianness), some
28 matches
Mail list logo
