Add language about rights given by posting a patch:

<li>PostgreSQL is licensed under a BSD license.  By posting a patch
    to the public PostgreSQL mailling lists, you are giving the PostgreSQL
    Global Development Group the non-revokable right to distribute your
    patch under the BSD license.  If you use code that is available under
    some other license that is BSD compatible (eg. public domain), please
    note that in your email submission.</li>

doc/FAQ_DEV

@@ -1,7 +1,7 @@
 
           Developer's Frequently Asked Questions (FAQ) for PostgreSQL
                                        
-   Last updated: Tue Feb 27 18:12:31 EST 2007
+   Last updated: Wed Feb 28 12:27:44 EST 2007
    
    Current maintainer: Bruce Momjian (bruce@momjian.us)
    
@@ -136,20 +136,22 @@ General Questions
        src/tools/make_diff/difforig useful. (Unified diffs are only
        preferable if the file changes are single-line changes and do not
        rely on surrounding lines.)
-    4. PostgreSQL is licensed under a BSD license, so any submissions
+    4. PostgreSQL is licensed under a BSD license. By posting a patch to
-       must conform to the BSD license to be included. If you use code
+       the public PostgreSQL mailling lists, you are giving the
-       that is available under some other license that is BSD compatible
+       PostgreSQL Global Development Group the non-revokable right to
-       (eg. public domain) please note that code in your email submission
+       distribute your patch under the BSD license. If you use code that
+       is available under some other license that is BSD compatible (eg.
+       public domain), please note that in your email submission.
     5. Confirm that your changes can pass the regression tests. If your
        changes are port specific, please list the ports you have tested
        it on.
-    6. Provide an implementation overview, preferably in code comments.
+    6. If you are adding a new feature, confirm that it has been tested
-       Following the surrounding code commenting style is usually a good
+       thoroughly. Try to test the feature in all conceivable scenarios.
-       approach.
     7. New feature patches should also be accompanied by documentation
        patches. If you need help checking the SQL standard, see 1.16.
-    8. If you are adding a new feature, confirm that it has been tested
+    8. Provide an implementation overview, preferably in code comments.
-       thoroughly. Try to test the feature in all conceivable scenarios.
+       Following the surrounding code commenting style is usually a good
+       approach.
     9. If it is a performance patch, please provide confirming test
        results to show the benefit of your patch. It is OK to post
        patches without this information, though the patch will not be

doc/src/FAQ/FAQ_DEV.html

@@ -13,7 +13,7 @@
     <H1>Developer's Frequently Asked Questions (FAQ) for
     PostgreSQL</H1>
 
-    <P>Last updated: Tue Feb 27 18:12:31 EST 2007</P>
+    <P>Last updated: Wed Feb 28 12:27:44 EST 2007</P>
 
     <P>Current maintainer: Bruce Momjian (<A href=
     "mailto:bruce@momjian.us">bruce@momjian.us</A>)<BR>
@@ -190,26 +190,28 @@
     preferable if the file changes are single-line changes and do not
     rely on surrounding lines.)</li>
 
-    <li>PostgreSQL is licensed under a BSD license, so any submissions must 
+    <li>PostgreSQL is licensed under a BSD license.  By posting a patch
-    conform to the BSD license to be included. If you use code that is 
+    to the public PostgreSQL mailling lists, you are giving the PostgreSQL
-    available under some other license that is BSD compatible (eg. public 
+    Global Development Group the non-revokable right to distribute your
-    domain) please note that code in your email submission</li>
+    patch under the BSD license.  If you use code that is available under
+    some other license that is BSD compatible (eg. public domain), please
+    note that in your email submission.</li>
 
     <li>Confirm that your changes can pass the regression tests. If your 
     changes are port specific, please list the ports you have tested it
     on.</li>
 
-    <li>Provide an implementation overview, preferably in code comments.
+    <li>If you are adding a new feature, confirm that it has been tested
-    Following the surrounding code commenting style is usually a good
+    thoroughly.  Try to test the feature in all conceivable
-    approach.</li>
+    scenarios.</li>
 
     <li>New feature patches should also be accompanied by documentation
     patches.  If you need help checking the SQL standard, see <a href=
     "#item1.16">1.16</a>.</li>
 
-    <li>If you are adding a new feature, confirm that it has been tested
+    <li>Provide an implementation overview, preferably in code comments.
-    thoroughly.  Try to test the feature in all conceivable
+    Following the surrounding code commenting style is usually a good
-    scenarios.</li>
+    approach.</li>
 
     <li>If it is a performance patch, please provide confirming test
     results to show the benefit of your patch. It is OK to post patches