[pypy-svn] r3617 - pypy/trunk/doc/funding/negotiations

[lac at codespeak.net]

Author: lac
Date: Thu Apr  1 13:08:45 2004
New Revision: 3617

Modified:
   pypy/trunk/doc/funding/negotiations/responses_2nd_april.txt
Log:
fix typos, add line about using GPL limiting our ability to be part of
Python 3000, and change some word orders.



Modified: pypy/trunk/doc/funding/negotiations/responses_2nd_april.txt
==============================================================================
--- pypy/trunk/doc/funding/negotiations/responses_2nd_april.txt	(original)
+++ pypy/trunk/doc/funding/negotiations/responses_2nd_april.txt	Thu Apr  1 13:08:45 2004
@@ -20,7 +20,7 @@
 
 **Action: the involvement and funding mechanism of PBF should be fully described**
 
-The project coordinator sent a mail on 31th of March detailing the
+The project coordinator sent a mail on the 31th of March detailing the
 future role of the PBF within the PyPy research project.  At the same
 time, participants formerly supposed to work through the PBF are now to
 enter the consortium.  
@@ -28,25 +28,22 @@
 **Action: in first instance no workpackages should be removed 
 as savings should be obtained through economizing the work planning.**
 
-After the withdrawal of MPI and the budget pressure there wasn't 
-enough time to discuss the complete work-plan with all consortium
-partners.  But the consortium has now revisited each work package description 
-and thus provides a much better and more consistent work plan.  We were
-able to retain all Workpackages and tasks by being more specific 
-about the exact deliverables and tasks.  Also each of the partners
+The consortium has now revisited each work package description 
+and has provided a much better and more consistent work plan.  We were
+able to retain all Workpackages and were more specific 
+about the exact deliverables and tasks. It was also necessary to
+reduce the scope of some of the work packages.  Each of the partners
 in the consortium now has to accept a much higher risk and responsbility 
 for producing all deliverables with the reduced resources. 
 
 The consortium intends to interact early and often with specific
-communities and individuals. This should generally lead to a much 
-better mobilization of resources. 
+communities and individuals. This should effectively mobilise our resources. 
 
 **Action: provide fully completed and quality checked CPFs.**
 
-We have much improved and completed the CPFs.  The project office's
+We have completed and greatly improved the CPFs.  The project office's
 responses to our consortium-proposal (sent by the PyPy project
-coorindator on 29th of March) may make further changes neccessary, 
-though. 
+coorindator on 29th of March) may still make further changes neccessary. 
 
 **Action: Also the reduction of the end-user involvement represents already 
 a reduction in work and required budget.**
@@ -72,7 +69,7 @@
 - D13.2 will provide a tool for end-users to support customizing PyPY 
   to domain specific needs. 
 - D14 deliverables provide interaction with various end user communities 
-  including the Research center of IBM in Zuerich 
+  including the Research center of IBM in Zurich 
 
 **Action: the body text should be preserved, and a full tracing to
 workpackages should be ensured (adding tasks, subtasks, and defined
@@ -162,7 +159,12 @@
 all consortium partners commit to produce source code always under an MIT 
 license the project explicitely reserves the right to include GPLed software. 
 In the latter case some versions of PyPy might have to be released under
-a GPL license due to its viral nature. 
+a GPL license.  If PyPy becomes the basis of Python 3000, there may be
+some pressure to release this under the Python license.  If we develop
+under the MIT license, then we are most flexible in this regard.  Committing
+to a GPL license would drastically reduce our ability to become the basis
+of Python 3000, since the CPython developers have already rejected the
+GPL as the license for developing Python. 
 
 **Action: The DoW will be modified to avoid this [user] confusion.**