Mailman 3 September 2000 - Python-Dev

Copyright gag
by Vladimir.Marangozov＠inrialpes.fr 03 Sep '00

03 Sep '00

Even CVS got confused about the Python's copyright <wink> ~> cvs update ... cvs server: Updating Demo/zlib cvs server: Updating Doc cvs server: nothing known about Doc/COPYRIGHT cvs server: Updating Doc/api cvs server: Updating Doc/dist ... -- Vladimir MARANGOZOV | Vladimir.Marangozov(a)inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

2 1

Re: [Python-checkins] CVS: python/dist/src LICENSE,1.1.2.7,1.1.2.8
by Fredrik Lundh 03 Sep '00

03 Sep '00

guido wrote: > Modified Files: > Tag: cnri-16-start > LICENSE > Log Message: > Set a release date, now that there's agreement between > CNRI and the FSF. and then he wrote: > Modified Files: > LICENSE > Log Message: > Various edits. Most importantly, added dual licensing. Also some > changes suggested by BobW. where "dual licensing" means: ! 3. Instead of using this License, you can redistribute and/or modify ! the Software 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. For a copy of the GPL, see ! http://www.gnu.org/copyleft/gpl.html. what's going on here? what exactly does the "agreement" mean? (I can guess, but my guess doesn't make me happy. I didn't really think I would end up in a situation where people can take code I've written, make minor modifications to it, and re-release it in source form in a way that makes it impossible for me to use it...) </F>

2 1

Re: Conflict with the GPL
by Guido van Rossum 03 Sep '00

03 Sep '00

> bob weiner wrote: > > We are doing a lot of work at BeOpen with CNRI to get them to allow > > the GPL as an alternative license across the CNRI-derived parts of the > > codebase. /.../ We at BeOpen want GPL-compatibility and have pushed > > for that since we started with any Python licensing issues. Fredrik Lundh replied: > my understanding was that the consortium members agreed > that GPL-compatibility was important, but that it didn't mean > that a licensing Python under GPL was a good thing. > > was dual licensing discussed on the consortium meeting? Can't remember, probably was mentioned as one of the considered options. Certainly the consortium members present at the meeting in Monterey agreed that GPL compatibility was important. > is the consortium (and this mailing list) irrelevant in this > discussion? You posted a +0 for dual licensing if it was the *only* possibility to reach GPL-compatibility for future Python licenses. That's also my own stance on this. I don't believe I received any other relevant feedback. I did see several posts from consortium members Paul Everitt and Jim Ahlstrom, defending the choice of law clause in the CNRI license and explaining why the GPL is not a gret license and why a pure GPL license is unacceptable for Python; I take these very seriously. Bob Weiner and I talked for hours with Kahn on Friday night and Saturday; I talked to Stallman several times on Saturday; Kahn and Stallman talked on Saturday. Dual licensing really was the *only* way to reach an agreement. So I saw no way out of the impasse except to just do it and get it over with. Kahn insisted that 1.6final be released before 2.0b1 and 2.0b1 be made a derived work of 1.6final. To show that he was serious, he shut off our login access to python.org and threatened with legal action if we would proceed with the 2.0b1 release as a derived work of 1.6b1. I don't understand why this is so important to him, but it clearly is. I want 2.0b1 to be released (don't you?) so I put an extra effort in to round up Stallman and make sure he and Kahn got on the phone to get a resolution, and for a blissful few hours I believed it was all done. Unfortunately the fat lady hasn't sung yet. After we thought we had reached agreement, Stallman realized that there are two interpretations of what will happen next: 1. BeOpen releases a version for which the license is, purely and simply, the GPL. 2. BeOpen releases a version which states the GPL as the license, and also states the CNRI license as applying with its text to part of the code. His understanding of the agreement (and that of his attorney, Eben Moglen, a law professor at NYU) was based on #1. It appears that what CNRI will explicitly allow BeOpen (and what the 1.6 license already allows) is #2. Stallman will have to get Moglen's opinion, which may take weeks. It's possible that they think that the BeOpen license is still incompatible with the GPL. In that case (assuming it happens within a reasonable time frame, and not e.g. 5 years from now :-) we have Kahn's agreement to go back to the negotiation table and talk to Stallman about possible modifications to the CNRI license. If the license changes, we'll re-release Python 1.6 as 1.6.1 with the new license, and we'll use that for BeOpen releases. If dual-licensing is no longer needed at that point I'm for taking it out again. > > > BTW, anybody got a word from RMS on whether the "choice of law" > > > is really the only one bugging him ? > > > > Yes, he has told me that was the only remaining issue. > > what's the current status here? Guido just checked in a new > 2.0 license that doesn't match the text he posted here a few > days ago. Most notable, the new license says: > > 3. Instead of using this License, you can redistribute and/or modify > the Software 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. For a copy of the GPL, see > http://www.gnu.org/copyleft/gpl.html. > > on the other hand, another checkin message mentions agreement > between CNRI and the FSF. did they agree to disagree? I think I've explained most of this above. I don't recall that checkin message. Which file? I checked the cvs logs for README and LICENSE for both the 1.6 and 2.0 branch. Anyway, the status is that 1.6 final is incompatible with the GPL and that for 2.0b1 we may or may not have GPL compatibility based on the dual licensing clause. I'm not too happy with the final wart. We could do the following: take the dual licensing clause out of 2.0b1, and promise to put it back into 2.0final if it is still needed. After all, it's only a beta, and we don't *want* Debian to put 2.0b1 in their distribution, do we? But personally I'm of an optimistic nature; I still hope that Moglen will find this solution acceptable and that this will be the end of the story. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)

3 3

New commands to display licence, credits, copyright info
by Charles G Waldman 03 Sep '00

03 Sep '00

I like Bob W's suggestion a lot. It is more open-ended and scalable than just continuing to add more and more lines to the startup messages. I assume these commands would only be in effect in interactive mode, right? You could also maybe add a "help" command, which, if nothing else, could get people pointed at the online tutorial/manuals. And, by all means, please keep the compiler version in the startup message!

2 1

failure in test_sre???
by Mark Favas 03 Sep '00

03 Sep '00

Is it just me, or is test_sre meant to fail, following the recent changes to _sre.c? Short failure message: test test_sre failed -- Writing: 'sre.match("\\x%02x" % i, chr(i)) != None', expected: '' Full failure messages: Running tests on character literals sre.match("\x%02x" % i, chr(i)) != None FAILED Traceback (most recent call last): File "test_sre.py", line 18, in test r = eval(expression) ValueError: invalid \x escape sre.match("\x%02x0" % i, chr(i)+"0") != None FAILED Traceback (most recent call last): File "test_sre.py", line 18, in test r = eval(expression) ValueError: invalid \x escape sre.match("\x%02xz" % i, chr(i)+"z") != None FAILED Traceback (most recent call last): File "test_sre.py", line 18, in test r = eval(expression) ValueError: invalid \x escape (the above sequence is repeated another 7 times) -- Mark

2 2

Re: [Python-Dev] stack check on Unix: any suggestions?
by Skip Montanaro 03 Sep '00

03 Sep '00

Charles> I get the exact same value. Of course the amount of other Charles> stuff running makes no differemce, you get the core dump Charles> because you've hit the RLIMIT for stack usage, not because Charles> you've exhausted memory. Amount of RAM in the machine, or swap Charles> space in use has nothing to do with it. Do "ulimit -s Charles> unlimited" and see what happens... Makes no difference: % ./python Python 2.0b1 (#81, Aug 31 2000, 15:53:42) [GCC 2.95.3 19991030 (prerelease)] on linux2 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam Copyright 1995-2000 Corporation for National Research Initiatives (CNRI) >>> % ulimit -a core file size (blocks) 0 data seg size (kbytes) unlimited file size (blocks) unlimited max locked memory (kbytes) unlimited max memory size (kbytes) unlimited open files 1024 pipe size (512 bytes) 8 stack size (kbytes) unlimited cpu time (seconds) unlimited max user processes 2048 virtual memory (kbytes) unlimited % ./python Misc/find_recursionlimit.py ... Limit of 2300 is fine recurse add repr init getattr getitem Limit of 2400 is fine recurse add repr Segmentation fault Skip

4 7

Namespace collision between lib/xml and site-packages/xml
by Mark Favas 03 Sep '00

03 Sep '00

On July 26 I reported that the new xml package in the standard library collides with and overrides the xml package from the xml-sig that may be installed in site-packages. This is still the case. The new package does not have the same functionality as the one in site-packages, and hence my application (and others relying on similar functionality) gets an import error. I understood that it was planned that the new library xml package would check for the site-package version, and transparently hand over to it if it existed. It's not really an option to remove/rename the xml package in the std lib, or to break existing xml-based code... Of course, this might be fixed by 2.0b1, or is it a feature that will be frozen out <wry smile>? Fred's response was: " I expect we'll be making the package in site-packages an extension provider for the xml package in the standard library. I'm planning to discuss this issue at today's PythonLabs meeting." -- Mark

2 2

Re: [Python-checkins] CVS: python/dist/src/Modules gcmodule.c,2.9,2.10
by Neil Schemenauer 02 Sep '00

02 Sep '00

On Thu, Aug 31, 2000 at 09:01:59PM -0700, Jeremy Hylton wrote: > set the default threshold much higher > we don't need to run gc frequently Are you sure setting it that high (5000 as opposed to 100) is a good idea? Did you do any benchmarking? If with-gc is going to be on by default in 2.0 then I would agree with setting it high. If the GC is optional then I think it should be left as it is. People explicitly enabling the GC obviously have a problem with cyclic garbage. So, is with-gc going to be default? At this time I would vote no. Neil

4 6

Bug #113254: pre/sre difference breaks pyclbr
by Fredrik Lundh 02 Sep '00

02 Sep '00

paul prescod spotted this discrepancy: from the documentation: start ([group]) end ([group]) Return the indices of the start and end of the substring matched by group; group defaults to zero (meaning the whole matched substring). Return None if group exists but did not contribute to the match. however, it turns out that PCRE doesn't do what it's supposed to: >>> import pre >>> m = pre.match("(a)|(b)", "b") >>> m.start(1) -1 unlike SRE: >>> import sre >>> m = sre.match("(a)|(b)", "b") >>> m.start(1) >>> print m.start(1) None this difference breaks 1.6's pyclbr (1.5.2's pyclbr works just fine with SRE, though...) ::: should I fix SRE and ask Fred to fix the docs, or should someone fix pyclbr and maybe even PCRE? </F>

3 3

Verbosity of the Makefile
by M.-A. Lemburg 02 Sep '00

02 Sep '00

This is pure cosmetics, but I found that the latest CVS versions of the Parser Makefile have become somewhat verbose. Is this really needed ? Also, I'd suggest adding a line .SILENT: to the top-level Makefile to make possible errors more visible (without the parser messages the Makefile messages for a clean run fit on a 25-line display). -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

6 9