number of tests, all because of the codecs/_multibytecodecs issue described
here (it's not a Py3K issue, just something Py3K discovers):
http://mail.python.org/pipermail/python-dev/2006-April/064051.html
Hye-Shik Chang promised to look for a fix, so no need to fix it here. The
tests that are expected to break are:
test_codecencodings_cn
test_codecencodings_hk
test_codecencodings_jp
test_codecencodings_kr
test_codecencodings_tw
test_codecs
test_multibytecodec
This merge fixes an actual test failure (test_weakref) in this branch,
though, so I believe merging is the right thing to do anyway.
not-GPL-compatible to GPL-compatible, with a footnote explaining that
RMS disagrees. I'm not going to discuss this further -- both sides
(CNRI and RMS) will argue their POV till they're blue in the face.
- Removed the subsection numbering in section B (each time a new
license is inserted in the front, the others have to be renumbered).
- Changed the words in the intro to avoid implying that 1.6.1 is
GPL-compatible.
(http://package.debian.org/lintian), which includes a spellchecker for
common typos in control files of packages... You see, we're so
paranoid that we even have automatic tools that keep monitoring
license files ;-)" (Gregor Hoffleit)
nor sufficient to make Python 2.0 compatible with the GPL, we won't
bother with it now.
In other words, we're still where we were weeks ago -- CNRI believes
that its license is GPL-compatible, Stallman says it's not. I'm
trying to arrange a meeting between their lawyers so they can work it
out. Whether dual licensing is the solution is open at this point.
If it is the (only!) solution, we'll add that to the BeOpen license
for 2.0 final.
AGREEMENT VERSION 1.
trade name -> trade names.
Note: depending on community feedback, we may end up taking the dual
licensing clause out for 2.0b1, and put it back into 2.0final, if
there's no other solution for assuring GPL compatibility by then.
See my message to python-dev and license-py20.