SF.net SVN: matplotlib:[7741] branches/v0_99_maint/doc

[<jd...@us...>]

Revision: 7741
          http://matplotlib.svn.sourceforge.net/matplotlib/?rev=7741&view=rev
Author:   jdh2358
Date:     2009-09-11 02:06:30 +0000 (Fri, 11 Sep 2009)

Log Message:
-----------
minor tweaks to licensing devel doc

Modified Paths:
--------------
    branches/v0_99_maint/doc/devel/coding_guide.rst
    branches/v0_99_maint/doc/users/credits.rst

Modified: branches/v0_99_maint/doc/devel/coding_guide.rst
===================================================================
--- branches/v0_99_maint/doc/devel/coding_guide.rst	2009-09-11 01:54:27 UTC (rev 7740)
+++ branches/v0_99_maint/doc/devel/coding_guide.rst	2009-09-11 02:06:30 UTC (rev 7741)
@@ -578,7 +578,7 @@
 
 The two dominant license variants in the wild are GPL-style and
 BSD-style. There are countless other licenses that place specific
-restrictions on code reuse, but there is an important different to be
+restrictions on code reuse, but there is an important difference to be
 considered in the GPL and BSD variants.  The best known and perhaps
 most widely used license is the GPL, which in addition to granting you
 full rights to the source code including redistribution, carries with
@@ -587,7 +587,7 @@
 license. I.e., you are required to give the source code to other
 people and give them the right to redistribute it as well. Many of the
 most famous and widely used open source projects are released under
-the GPL, including sagemath, linux, gcc and emacs.
+the GPL, including linux, gcc, emacs and sage.
 
 The second major class are the BSD-style licenses (which includes MIT
 and the python PSF license). These basically allow you to do whatever
@@ -606,20 +606,20 @@
 sense of the last paragraph are the BSD operating system, python and
 TeX.
 
-There are two primary reasons why early matplotlib developers selected
-a BSD compatible license. We wanted to attract as many users and
-developers as possible, and many software companies will not use GPL code
-in software they plan to distribute, even those that are highly
-committed to open source development, such as `enthought
+There are several reasons why early matplotlib developers selected a
+BSD compatible license. matplotlib is a python extension, and we
+choose a license that was based on the python license (BSD
+compatible).  Also, we wanted to attract as many users and developers
+as possible, and many software companies will not use GPL code in
+software they plan to distribute, even those that are highly committed
+to open source development, such as `enthought
 <http://enthought.com>`_, out of legitimate concern that use of the
 GPL will "infect" their code base by its viral nature. In effect, they
-want to retain the right to release some proprietary code. Companies,
-and institutions in general, who use matplotlib often make significant
-contributions, since they have the resources to get a job done, even a
-boring one, if they need it in their code. Two of the matplotlib
-backends (FLTK and WX) were contributed by private companies.
-
-The other reason is licensing compatibility with the other python
-extensions for scientific computing: ipython, numpy, scipy, the
-enthought tool suite and python itself are all distributed under BSD
-compatible licenses.
+want to retain the right to release some proprietary code. Companies
+and institutions who use matplotlib often make significant
+contributions, because they have the resources to get a job done, even
+a boring one. Two of the matplotlib backends (FLTK and WX) were
+contributed by private companies.  The final reason behind the
+licensing choice is compatibility with the other python extensions for
+scientific computing: ipython, numpy, scipy, the enthought tool suite
+and python itself are all distributed under BSD compatible licenses.

Modified: branches/v0_99_maint/doc/users/credits.rst
===================================================================
--- branches/v0_99_maint/doc/users/credits.rst	2009-09-11 01:54:27 UTC (rev 7740)
+++ branches/v0_99_maint/doc/users/credits.rst	2009-09-11 02:06:30 UTC (rev 7741)
@@ -18,7 +18,11 @@
 
 Andrew Straw provided much of the log scaling architecture, the fill
   command, PIL support for imshow, and provided many examples.  He
-  also wrote the support for dropped axis spines.
+  also wrote the support for dropped axis spines and the `buildbot
+  <http://mpl-buildbot.code.astraw.com/>`_ unit testing infrastructure
+  which triggers the JPL/James Evans platform specific builds and
+  regression test image comparisons from svn matplotlib across
+  platforms on svn commits.
 
 Charles Twardy
   provided the impetus code for the legend class and has made
@@ -116,11 +120,14 @@
   at `NOAA <http://www.boulder.noaa.gov>`_ wrote the
   :ref:`toolkit_basemap` tookit
 
-Sigve Tjoraand, Ted Drain
+Sigve Tjoraand, Ted Drain, James Evans 
   and colleagues at the `JPL <http://www.jpl.nasa.gov>`_ collaborated
   on the QtAgg backend and sponsored development of a number of
   features including custom unit types, datetime support, scale free
-  ellipses, broken bar plots and more.
+  ellipses, broken bar plots and more.  The JPL team wrote the unit
+  testing image comparison `infrastructure
+  <http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/test>`_
+  for regression test image comparisons.
 
 James Amundson
   did the initial work porting the qt backend to qt4


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.