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 be
> "Tim" == Tim Peters <[EMAIL PROTECTED]> writes:
Tim> I'm not making myself clear.
Whatever makes you think that? 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
histor
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
__
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
[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 a
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 diffe
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 h
> "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
> "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 lib
[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
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 t
> "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
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, "identifia
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
b
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 requir
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
> "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_,
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 tool
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):
http://mail.python.org/pipermail/python-dev/2006-January/060113.
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
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 the license. Anyway, it could
> be t
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, endia
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
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 wrot
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
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 tools to build libffi,
and th
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.
http://mail.python.o
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.
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 http://mail.python.org/pipermail/python-d
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
>
Here's the draft for the first January summary. If anyone has time to
send me/Steve comments/suggestions/corrections/additions, those will
be most welcome. The Py_ssize_t threads were particularly over my
head. As always, many thanks :)
=
Announcements
=
---
31 matches
Mail list logo