;
+@end example
+
+gets added to the pattern. The @code{condition} should be true if the
+intrusion cannot be stopped in sente. In the above example, the relevant
+intrusion pattern will have an action line of the form
+
+@example
+>return (!xplay_attack(a,b));
+@end example
+
+where @samp{b} refers to the stone at @samp{*}. In fact, almost all
+followup-specific constraints look similar to this.
+
+
+@node Influential Display
+@section Colored display and debugging of influence
+
+There are various ways to obtain detailed information about the influence
+computations. Colored diagrams showing influence are possible from
+a colored xterm or rxvt window.
+
+There are two options controlling when to generate diagrams:
+
+@itemize @bullet
+@item @option{-m 0x08} or @option{-m 8}
+@quotation
+Show diagrams for the initial influence computation. This is done
+twice, the first time before @code{make_dragons()} is run and the second time
+after. The difference is that dead dragons are taken into account the
+second time. Tactically captured worms are taken into account both
+times.
+@end quotation
+@item @option{--debug-influence @var{location}}
+@quotation
+Show influence diagrams after the move at the given location. An
+important limitation of this option is that it's only effective for
+moves that the move generation is considering.
+@end quotation
+@end itemize
+
+The other options control which diagrams should be generated in these
+situations. You have to specify at least one of the options above and
+at least one of the options below to generate any output.
+
+@strong{
+The options below must be combined with one of the two previous
+ones, or the diagram will not be printed. For example to print
+the influence diagram, you may combine 0x08 and 0x010, and use
+the option @option{-m 0x018}.}
+
+@itemize @bullet
+@item @option{-m 0x010} or @option{-m 16}
+@quotation
+Show colored display of territory/moyo/area regions.
+@itemize @minus
+@item territory: cyan
+@item moyo: yellow
+@item area: red
+@end itemize
+This feature is very useful to get an immediate impression of the influence
+regions as GNU Go sees them.
+@end quotation
+@item @option{-m 0x20} or @option{-m 32}
+@quotation
+Show numerical influence values for white and black. These come in
+two separate diagrams, the first one for white, the second one for
+black. Notice that the influence values are represented by floats and
+thus have been rounded in these diagrams.
+@end quotation
+@item @option{-m 0x40} or @option{-m 64}
+@quotation
+This generates two diagrams showing the permeability for black and white
+influence on the board.
+@end quotation
+@item @option{-m 0x80} or @option{-m 128}
+@quotation
+This shows the strength of the influence sources for black and white
+across the board. You will see sources at each lively stone (with strength
+depending on the strength of this stone), and sources contributed by
+patterns.
+@end quotation
+@item @option{-m 0x100} or @option{-m 256}
+@quotation
+This shows the attenuation with which the influence sources spread
+influence across the board. Low attenuation indicates far-reaching
+influence sources.
+@end quotation
+@item @option{-m 0x200} or @option{-m 512}
+@quotation
+This shows the territory valuation of GNU Go. Each intersection is
+shown with a value between -1.0 and +1.0 (or -2 resp. +2 if there is
+a dead stone on this intersection). Positive values indicate territory
+for white. A value of -0.5 thus indicates a point where black has a
+50% chance of getting territory.
+@end quotation
+@end itemize
+
+Finally, there is the debug option @option{-d 0x1} which turns on
+on @code{DEBUG_INFLUENCE}. This gives a message for each influence pattern
+that gets matched. Unfortunately, these are way too many messages making
+it tedious to navigate the output. However, if you discover an influence
+source with @option{-m 0x80} that looks wrong, the debug output can
+help you to quickly find out the responsible pattern.
+
+@node Influence Tuning
+@section Influence Tuning with @code{view.pike}
+
+A useful program in the regression directory is @code{view.pike}.
+To run it, you need Pike, which you may download from
+@url{http://pike.ida.liu.se/}.
+
+The test case @file{endgame:920} fails in GNU Go 3.6. We will
+explain how to fix it.
+
+Start by firing up view.pike on testcase endgame:920, e.g. by running
+@command{pike view.pike endgame:920} in the regression directory.
+
+We see from the first view of move values that filling dame at P15 is
+valued highest with 0.17 points while the correct move at C4 is valued
+slightly lower with 0.16. The real problem is of course that C4 is
+worth a full point and thus should be valued about 1.0.
+
+Now click on C4 to get a list of move reasons and move valuation
+information. Everything looks okay except that change in territory is
+0.00 rather than 1.00 as it ought to be.
+
+We can confirm this by choosing the ``delta territory for...'' button
+and again clicking C4. Now B5 should have been marked as one point of
+change in territory, but it's not.
+
+Next step is to enter the influence debug tool. Press the ``influence''
+button, followed by ``black influence, dragons known,'' and ``territory
+value.'' This shows the expected territory if black locally moves first
+everywhere (thus ``black influence''). Here we can see that B5 is
+incorrectly considered as 1.0 points of white territory.
+
+We can compare this with the territory after a white move at C4 (still
+assuming that black locally moves first everywhere after that) by
+pressing ``after move influence for...'' and clicking C4. This looks
+identical, as expected since delta territory was 0, but here it is
+correct that B5 is 1.0 points of territory for white.
+
+The most straightforward solution to this problem is to add a
+non-territory pattern, saying that white can't get territory on B5 if
+black moves first. The nonterritory patterns are in @file{barriers.db}.
+
+@example
+Pattern Nonterritory56
+
+...
+X.O
+?O.
+
+:8,t
+
+eac
+XbO
+?Od
+
+;oplay_attack(a,b,c,d,d)
+
+>non_xterritory(e);
+@end example
+
+In these patterns it's always assumed that @samp{O} moves first and thus it
+says that @samp{X} can't get territory at @code{B5} (@samp{e} in the
+pattern). Now we need to be a bit careful however since after @samp{O} plays
+at @samp{a} and @samp{X} cuts in at @samp{b}, it may well happen that @samp{O}
+needs to defend around @samp{d}, allowing @samp{X} to cut at @samp{c}, possibly
+making the nonterritory assumption invalid. It's difficult to do this entirely
+accurate, but the constraint above is fairly conservative and should guarantee
+that @samp{a} is safe in most, although not all, cases.
diff --git a/gnugo/doc/install.texi b/gnugo/doc/install.texi
new file mode 100644
index 0000000..095613b
--- /dev/null
+++ b/gnugo/doc/install.texi
@@ -0,0 +1,456 @@
+
+You can get the most recent version of GNU Go ftp.gnu.org or a mirror
+(see @url{http://www.gnu.org/order/ftp.html} for a list). You can read
+about newer versions and get other information at
+@url{http://www.gnu.org/software/gnugo/}.
+
+@menu
+* GNU/Linux and Unix:: GNU Linux and Unix Installation
+* Configure Options:: Configure Options
+* Windows and MS-DOS:: Windows Installation
+* Macintosh:: Macintosh Installation
+@end menu
+
+@node GNU/Linux and Unix, Configure Options, ,Installation
+@section GNU/Linux and Unix
+@cindex installation
+
+Untar the sources, change to the directory gnugo-3.8. Now do:
+
+@example
+ ./configure [OPTIONS]
+ make
+@end example
+
+Several configure options will be explained in the next section. You do not
+need to set these unless you are dissatisfied with GNU Go's performance or
+wish to vary the experimental options.
+
+As an example,
+
+@example
+ ./configure --enable-level=9 --enable-cosmic-gnugo
+@end example
+
+@noindent
+will make a binary in which the default level is 9, and the experimental
+``cosmic''' option is enabled. A list of all configure options can be
+obtained by running @command{./configure --help}. Further information
+about the experimental options can be found in the next section
+(@pxref{Configure Options}).
+
+After running configure and make, you have now made a binary called
+@file{interface/gnugo}. Now (running as root) type
+
+@example
+ make install
+@end example
+
+@noindent
+to install @file{gnugo} in @file{/usr/local/bin}.
+
+There are different methods of using GNU Go. You may run it from the
+command line by just typing:
+
+@example
+ gnugo
+@end example
+
+@noindent
+but it is nicer to run it using CGoban 1 (under X Window System),
+Quarry, Jago (on any platform with a Java Runtime Environment) or other
+client programs offering a GUI.
+
+You can get the most recent version of CGoban 1 from
+@url{http://sourceforge.net/projects/cgoban1/}. The earlier version
+1.12 is available from @url{http://www.igoweb.org/~wms/comp/cgoban/index.html}.
+The CGoban version number MUST be 1.9.1 at least or it won't work. CGoban 2
+will not work.
+
+@xref{CGoban}, for instructions on how to run GNU Go from Cgoban, or
+@xref{Other Clients}, for Jago or other clients.
+
+Quarry is available at @url{http://home.gna.org/quarry/}.
+
+@node Configure Options
+@section Configure Options
+
+There are three options which you should consider configuring,
+particularly if you are dissatisfied with GNU Go's performance.
+
+@menu
+* Ram Cache:: Ram Cache
+* Default Level:: Default Level
+* Other Options:: Other Options
+@end menu
+
+@node Ram Cache
+@subsection Ram Cache
+
+By default, GNU Go makes a cache of about 8 Megabytes in RAM for its
+internal use. The cache is used to store intermediate results during
+its analysis of the position. More precisely the default cache size is
+350000 entries, which translates to 8.01 MB on typical 32 bit
+platforms and 10.68 MB on typical 64 bit platforms.
+
+Increasing the cache size will often give a modest speed improvement.
+If your system has lots of RAM, consider increasing the cache
+size. But if the cache is too large, swapping will occur,
+causing hard drive accesses and degrading performance. If
+your hard drive seems to be running excessively your cache
+may be too large. On GNU/Linux systems, you may detect swapping
+using the program 'top'. Use the 'f' command to toggle SWAP
+display.
+
+You may override the size of the default cache at compile time
+by running one of:
+
+@example
+ ./configure --enable-cache-size=n
+@end example
+
+@noindent
+to set the cache size to @code{n} megabytes. For example
+
+@example
+ ./configure --enable-cache-size=32
+@end example
+
+@noindent
+creates a cache of size 32 megabytes. If you omit this, your default
+cache size will be 8-11 MB as discussed above. Setting cache size
+negative also gives the default size. You must recompile and reinstall
+GNU Go after reconfiguring it by running @command{make} and
+@command{make install}.
+
+You may override the compile-time defaults by running @file{gnugo}
+with the option @option{--cache-size n}, where @code{n} is the size in
+megabytes of the cache you want, and @option{--level} where n is the
+level desired. We will discuss setting these parameters next in
+detail.
+
+@node Default Level
+@subsection Default Level
+
+GNU Go can play at different levels. Up to level 10 is
+supported. At level 10 GNU Go is much more accurate but takes
+an average of about 1.6 times longer to play than at level 8.
+
+The level can be set at run time using the @option{--level} option.
+If you don't set this, the default level will be used. You
+can set the default level with the configure option
+@option{--enable-level=n}. For example
+
+@example
+./configure --enable-level=9
+@end example
+
+@noindent
+sets the default level to 9. If you omit this parameter,
+the compiler sets the default level to 10. We recommend
+using level 10 unless you find it too slow. If you decide
+you want to change the default you may rerun configure
+and recompile the program.
+
+@node Other Options
+@subsection Other Options
+
+Anything new in the engine is generally tested as an experimental option
+which can be turned on or off at compile time or run time. Some
+``experimental'' options such as the break-in code are no longer
+experimental but are enabled by default.
+
+This section can be skipped unless you are interested in the
+experimental options.
+
+Moreover, some configure options were removed from the stable
+release. For example it is known that the owl extension code
+can cause crashes, so the configure option --enable-experimental-owl-ext
+was disabled for 3.8.
+
+The term ``default'' must be clarified, since there
+are really two sets of defaults at hand, runtime defaults
+specified in @file{config.h} and compile time default
+values for the runtime defaults, contained in @file{configure}
+(which is created by editing @file{configure.in} then running
+@command{autoconf}. For example we find in @file{config.h}
+
+@example
+/* Center oriented influence. Disabled by default. */
+#define COSMIC_GNUGO 0
+
+/* Break-in module. Enabled by default. */
+#define USE_BREAK_IN 1
+@end example
+
+This means that the experimental cosmic option, which causes
+GNU Go to play a center-oriented game (and makes the engine
+weaker) is disabled by default, but that the break-in module
+is used. These are defaults which are used when GNU Go is
+run without command line options. They can be overridden
+with the run time options:
+
+@example
+gnugo --cosmic-gnugo --without-break-in
+@end example
+
+Alternatively you can configure GNU Go as follows:
+
+@example
+./configure --enable-cosmic-gnugo --disable-experimental-break-in
+@end example
+
+then recompile GNU Go. This changes the defaults in @file{config.h},
+so that you do not have to pass any command line options to GNU Go
+at run time to get the experimental owl extension turned on and
+the experimental break-in code turned off.
+
+If you want to find out what experimental options were compiled into your GNU
+Go binary you can run @command{gnugo --options} to find out. Here is a list
+of experimental options in GNU Go.
+
+@itemize @bullet
+@item @code{experimental-break-in}. Experimental break-in code
+(@pxref{Break Ins}). You should not need to configure this because
+the break in code is enabled by default in level 10, and is turned
+off at level 9. If you don't want the breakin code just play at
+level 9.
+@item @code{cosmic-gnugo}. An experimental style which plays a center
+oriented game and has a good winning rate against standard GNU Go,
+though it makes GNU Go weaker against other opponents.
+@item @code{large-scale}. Attempt to make large-scale captures.
+See:
+
+@url{http://lists.gnu.org/archive/html/gnugo-devel/2003-07/msg00209.html}
+
+for the philosophy of this option. This option makes the engine slower.
+@item @code{metamachine}. Enables the metamachine, which allows
+you to run the engine in an experimental mode whereby it forks
+a new @code{gnugo} process which acts as an ``oracle.'' Has no
+effect unless combined with the @option{--metamachine} run-time
+option.
+@end itemize
+
+Other options are not experimental, and can be changed as
+configure or runtime options.
+
+@itemize @bullet
+@item @code{chinese-rules} Use Chinese (area) counting.
+@item @code{resignation-allowed} Allow GNU Go to resign games.
+This is on by default.
+@end itemize
+
+@node Windows and MS-DOS, Macintosh, Configure Options, Installation
+@section Compiling GNU Go on Microsoft platforms
+
+@subsection Building with older visual studio
+
+The distribution directories contain some .dsp and .dsw files with
+GNU Go. These have been brought up to date in the sense that they
+should work if you have the older VC++ with Visual Studio 6
+but the distributed .dsp and .dsw files will only be of use with
+older version of Visual Studio.
+
+In most cases (unless you are building in Cygwin) the preferred way
+to build GNU Go on Windows platforms is to use CMake. CMake
+understands about many versions of Visual C/Visual Studio, and will
+generate project/solution files for the tools installed on your
+system. So even if you have Visual Studio 6 you may use CMake
+and dispense with the distributed .dsp and .dsw files.
+
+@subsection Building with Visual Studio project files
+
+Before you compile the GNU Go source, you need to run CMake first, to
+generate the build files you'll give to Visual Studio.
+
+From the cmd.exe command prompt, CD into the GNU Go source directory.
+To confirm you're in the right place, you should see the file
+'CMakeLists.txt' in the top-level directory of the GNU Go code (as well
+as others in lower subdirectories).
+
+Direct CMake to generate the new Visual Studio build files by typing:
+
+@example
+ cmake CMakeLists.txt
+@end example
+
+Compile the code by invoking the newly-created Solution file:
+
+@example
+ vcbuild GNUGo.sln
+@end example
+
+This will take a few moments, as CMake generates 4 debug/retail targets:
+
+@example
+ debug
+ release
+ minsizerel
+ relwithdebinfo
+@end example
+
+For each of these targets, Visual Studio is generating a version of
+gnugo.exe:
+
+@example
+ interface\debug\gnugo.exe
+ interface\release\gnugo.exe
+ interface\minsizerel\gnugo.exe
+ interface\relwithdebinfo\gnugo.exe
+@end example
+
+Additionally, there is an 'Install' target available, that will copy the
+the gnugo.exe into the %ProgramFiles% directory. To do this, type:
+
+@example
+ vcbuild INSTALL.vcproj
+@end example
+
+This should result in copying GNU/Go into:
+
+@example
+ "%ProgramFiles%\GNUGo\bin\gnugo.exe" --options
+@end example
+
+In addition to command line use, CMake also has a GUI version. Users of
+the Visual Studio GUI might prefer to use that.
+
+@subsection Building with Nmake makefiles
+
+GNU Go will also build using NMake makefiles. Optionally, instead of
+Visual Studio project/solution files, you may direct CMake to generate
+NMake makefiles. To generate the makefiles:
+
+@example
+ cmake -G "NMake Makefiles" CMakeLists.txt
+@end example
+
+The default rule for the makefile is 'all'. Use the 'help' rule to show
+a list of available targets.
+
+@example
+ nmake -f Makefile help
+@end example
+
+To compile GNU Go:
+
+@example
+ nmake -f Makefil, all
+@end example
+
+One sysand 2009 tems, GNU GO may fail to build when using NMake makefiles.
+only fails the first time run, run NMake again with the 'clean all'
+targets, and it will compile the second and subsequent times.
+
+@example
+ nmake -f Makefile clean all
+@end example
+
+Which will successfully generate a gnugo.exe.
+
+@example
+ interface\gnugo.exe --options
+@end example
+
+@subsection Building with MinGW Makefiles
+
+GNU Go can be built on Windows systems using MinGW.
+
+This development environment uses: the GCC compiler (gcc.exe, not
+cl.exe), the Microsoft C runtime libraries (MSCRT, not GLibC), the GNU
+Make build tool (@code{mingw32-make.exe}, not NMake), all from the Windows
+shell (@code{cmd.exe}, not sh/bash).
+
+For CMake to work, in addition to the base MinGW installation, the C++
+compiler (g++.exe) and GNU Make (mingw32-make.exe) need to be installed.
+This was tested using GCC v3, not the experimental v4. To debug, use
+GDB, as the GCC-generated symbols won't work with NTSD/Windbg/Visual Studio.
+
+To create the makfiles, run CMake with the MinGW generator option:
+
+@example
+ cmake -G "MinGW Makefiles" CMakeLists.txt
+@end example
+
+To build GNU Go, from a cmd.exe shell, run GNU Make (against the
+newly-created 'Makefile' and it's default 'all' target):
+
+@example
+ mingw32-make
+ ..\interface\gnugo.exe --options
+@end example
+
+@subsection Building with MSYS makefiles (MinGW)
+
+GNU Go can be built on Windows systems using MSYS.
+
+This development environment uses: the GCC compiler (gcc.exe, not
+cl.exe), the Microsoft C runtime libraries (MSCRT, not GLibC), the GNU
+Make build tool (make, not NMake), all from the GNU Bash (sh.exe, not
+cmd.exe).
+
+To create the makfiles, run CMake with the MSYS generator option:
+
+@example
+ cmake -G "MSYS Makefiles" CMakeLists.txt
+@end example
+
+Start MSYS's Bash shell, either clicking on a shortcut on from the
+command line:
+
+@example
+ cd /d c:\msys\1.0
+ msys.bat
+@end example
+
+To build GNU Go, from a Bash shell, run GNU Make (against the
+newly-created 'Makefile' and it's default 'all' target):
+
+@example
+ make
+ ../interface/gnugo.exe --options
+@end example
+
+To debug, use GDB, as the GCC-generated symbols won't work with
+NTSD/Windbg/Visual Studio.
+
+@subsection Building on cygwin
+
+With Cygwin, you should be able to
+
+@example
+ tar zxvf gnugo-3.8.tar.gz
+ cd gnugo-3.8
+ env CC='gcc -mno-cygwin' ./configure
+ make
+@end example
+
+@subsection Testing on Windows:
+
+@file{regression/regress.cmd} is a simplified cmd.exe-centric port of the main
+gnugo Unix shell script regress.sh. It can be used to help verify that the
+generated binary might be operational. Read the script's comment header for
+more information. For access to the full GNU Go tests, use Unix, not Windows.
+
+To test:
+
+@example
+ cd regression
+ regress.cmd ..\interface\gnugo.exe
+@end example
+
+@node Macintosh
+@section Macintosh
+
+If you have Mac OS X you can build GNU Go using Apple's compiler,
+which is derived from GCC. You will need Xcode.
+
+One issue is that the configure test for socket support is
+too conservative. On OS/X, the configure test fails, but
+actually socket support exists. So if you want to be able
+to connect to the engine through tcp/ip (using gtp) you
+may @command{configure --enable-socket-support}. There
+will be an error message but you may build the engine
+and socket support should work.
+
+
diff --git a/gnugo/doc/introduction.texi b/gnugo/doc/introduction.texi
new file mode 100644
index 0000000..5f4ece4
--- /dev/null
+++ b/gnugo/doc/introduction.texi
@@ -0,0 +1,177 @@
+
+This is GNU Go 3.8, a Go program. Development versions of GNU Go may be
+found at @url{http://www.gnu.org/software/gnugo/devel.html}. Contact
+us at @email{gnugo@@gnu.org} if you are interested in helping.
+
+@menu
+* About:: About GNU Go and this Manual
+* Copyright:: Copyright
+* Authors:: The Authors of GNU Go
+* Thanks:: Acknowledgements
+* Development:: Developing GNU Go
+@end menu
+
+@node About
+@section About GNU Go and this Manual
+
+The challenge of Computer Go is not to @strong{beat} the computer,
+but to @strong{program} the computer.
+
+In Computer Chess, strong programs are capable of playing at the highest
+level, even challenging such a player as Garry Kasparov. No Go program
+exists that plays at the same level as the strongest human players.
+
+To be sure, existing Go programs are strong enough to be interesting
+as opponents, and the hope exists that some day soon a truly
+strong program can be written. This is especially true in view
+of the successes of Monte Carlo methods, and a general recent
+improvement of computer Go.
+
+Before GNU Go, Go programs have always been distributed as binaries
+only. The algorithms in these proprietary programs are secret. No-one
+but the programmer can examine them to admire or criticise. As a
+consequence, anyone who wished to work on a Go program usually had to
+start from scratch. This may be one reason that Go programs have not
+reached a higher level of play.
+
+Unlike most Go programs, GNU Go is Free Software. Its algorithms and
+source code are open and documented. They are free for any one to
+inspect or enhance. We hope this freedom will give GNU Go's descendents
+a certain competetive advantage.
+
+Here is GNU Go's Manual. There are doubtless inaccuracies. The ultimate
+documentation is in the commented source code itself.
+
+The first three chapters of this manual are for the general
+user. Chapter 3 is the User's Guide. The rest of the book is for
+programmers, or persons curious about how GNU Go works. Chapter 4 is a
+general overview of the engine. Chapter 5 introduces various tools for
+looking into the GNU Go engine and finding out why it makes a certain
+move, and Chapters 6--7 form a general programmer's reference to the GNU
+Go API. The remaining chapters are more detailed explorations of
+different aspects of GNU Go's internals.
+
+@node Copyright
+@section Copyrights
+
+Copyright 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007
+and 2008 by the Free Software Foundation except as noted below.
+
+All source files are distributed under the GNU General Public License
+(@pxref{GPL}, version 3 or any later version), except @file{gmp.c},
+@file{gmp.h}, @file{gtp.c}, and @file{gtp.h}.
+
+The files @file{gtp.c} and @file{gtp.h} are copyright the Free Software
+Foundation. In the interests of promoting the Go Text Protocol these
+two files are licensed under a less restrictive license than the GPL
+and are free for unrestricted use (@pxref{GTP License}).
+
+The two files @file{gmp.c} and @file{gmp.h} were placed in the public domain
+by William Shubert, their author, and are free for unrestricted use.
+
+Documentation files (including this manual) are distributed under
+the GNU Free Documentation License (@pxref{GFDL}, version 1.3 or any later
+version).
+
+The files @file{regression/games/golois/*sgf} are copyright Tristan
+Cazenave and are included with his permission.
+
+The SGF files in @file{regression/games/handtalk/} are copyright Jessie Annala
+and are used with permission.
+
+The SGF files in @file{regression/games/mertin13x13/} are copyright Stefan
+Mertin and are used with permission.
+
+The remaining SGF files are either copyright by the FSF or are in the public domain.
+
+
+
+
+@node Authors
+@section Authors
+
+GNU Go maintainers are Daniel Bump, Gunnar Farneback and Arend
+Bayer. GNU Go authors (in chronological order of contribution)
+are Man Li, Wayne Iba, Daniel Bump, David Denholm, Gunnar
+Farneb@"ack, Nils Lohner, Jerome Dumonteil, Tommy Thorn,
+Nicklas Ekstrand, Inge Wallin, Thomas Traber, Douglas Ridgway,
+Teun Burgers, Tanguy Urvoy, Thien-Thi Nguyen, Heikki Levanto,
+Mark Vytlacil, Adriaan van Kessel, Wolfgang Manner, Jens
+Yllman, Don Dailey, M@aa{}ns Ullerstam, Arend Bayer, Trevor
+Morris, Evan Berggren Daniel, Fernando Portela, Paul
+Pogonyshev, S.P. Lee and Stephane Nicolet, Martin Holters,
+Grzegorz Leszczynski and Lee Fisher.
+
+@node Thanks
+@section Thanks
+
+We would like to thank Arthur Britto, David Doshay, Tim Hunt, Matthias Krings,
+Piotr Lakomy, Paul Leonard, Jean-Louis Martineau, Andreas Roever and Pierce
+Wetter for helpful correspondence.
+
+Thanks to everyone who stepped on a bug (and sent us a report)!
+
+Thanks to Gary Boos, Peter Gucwa, Martijn van der Kooij, Michael
+Margolis, Trevor Morris, M@aa{}ns Ullerstam, Don Wagner and Yin Zheng for help
+with Visual C++.
+
+Thanks to Alan Crossman, Stephan Somogyi, Pierce Wetter and Mathias Wagner
+for help with Macintosh. And thanks to Marco Scheurer and Shigeru Mabuchi for
+helping us find various problems.
+
+Thanks to Jessie Annala for the Handtalk games.
+
+Special thanks to Ebba Berggren for creating our logo, based on a
+design by Tanguy Urvoy and comments by Alan Crossman. The old
+GNU Go logo was adapted from Jamal Hannah's typing GNU:
+@url{http://www.gnu.org/graphics/atypinggnu.html}.
+Both logos can be found in @file{doc/newlogo.*} and @file{doc/oldlogo.*}.
+
+We would like to thank Stuart Cracraft, Richard Stallman and Man Lung Li for
+their interest in making this program a part of GNU, William Shubert for
+writing CGoban and gmp.c, Rene Grothmann for Jago and Erik van Riper and his
+collaborators for NNGS.
+
+
+@node Development
+@section Development
+
+You can help make GNU Go the best Go program.
+
+This is a task-list for anyone who is interested in helping with GNU
+Go. If you want to work on such a project you should correspond with
+us until we reach a common vision of how the feature will work!
+
+A note about copyright. The Free Software Foundation has the copyright
+to GNU Go. For this reason, before any code can be accepted as a part of
+the official release of GNU Go, the Free Software Foundation will want
+you to sign a copyright assignment.
+
+Of course you could work on a forked version without signing
+such a disclaimer. You can also distribute such a forked version of the
+program so long as you also distribute the source code to your
+modifications under the GPL (@pxref{GPL}). But if you want
+your changes to the program to be incorporated into the
+version we distribute we need you to assign the copyright.
+
+Please contact the GNU Go maintainers, Daniel Bump
+(@email{bump@@sporadic.stanford.edu}) and Gunnar Farneb@"ack
+(@email{gunnar@@lysator.liu.se}), to get more information and the
+papers to sign.
+
+Bug reports are very welcome, but if you can, send us bug FIXES as well as bug
+reports. If you see some bad behavior, figure out what causes it, and what to
+do about fixing it. And send us a patch! If you find an interesting bug and
+cannot tell us how to fix it, we would be happy to have you tell us about it
+anyway. Send us the sgf file (if possible) and attach other relevant
+information, such as the GNU Go version number. In cases of assertion failures
+and segmentation faults we probably want to know what operating system and
+compiler you were using, in order to determine if the problem is platform
+dependent.
+
+If you want to work on GNU Go you should subscribe to the
+@uref{http://lists.gnu.org/mailman/listinfo/gnugo-devel,
+GNU Go development list.} Discussion of bugs and feedback
+from established developers about new projects or tuning
+the existing engine can be done on the list.
+
diff --git a/gnugo/doc/logo-32.eps b/gnugo/doc/logo-32.eps
new file mode 100644
index 0000000..95f2870
--- /dev/null
+++ b/gnugo/doc/logo-32.eps
@@ -0,0 +1,1047 @@
+%!PS-Adobe-3.0 EPSF-3.0
+%%Creator: GIMP PostScript file plugin V 1.11 by Peter Kirchgessner
+%%Title: /home/bump/freedom/gnugo-3.1.30/doc/logo-32.eps
+%%CreationDate: Sat Mar 30 08:19:57 2002
+%%DocumentData: Clean7Bit
+%%LanguageLevel: 2
+%%Pages: 1
+%%BoundingBox: 14 14 386 340
+%%EndComments
+%%BeginProlog
+% Use own dictionary to avoid conflicts
+10 dict begin
+%%EndProlog
+%%Page: 1 1
+% Translate for offset
+14.173228 14.173228 translate
+% Translate to begin of first scanline
+0.000000 325.000000 translate
+371.000000 -325.000000 scale
+% Image geometry
+371 325 8
+% Transformation matrix
+[ 371 0 0 325 0 0 ]
+currentfile /ASCII85Decode filter /RunLengthDecode filter
+%%BeginData: 77231 ASCII Bytes
+image
+RJQp_*;Ajep&Fm]q#'[Do`+R^qXF7Zs7?$]qY^9gqY>^=QMR$G!U]X\rttJ"nETN4nbiF[g[Y%5
+o_&+Zp@n@Yqu$>BqNUiEq>p-]rr3i7qtoa[s8Cj,lMpGDoD&%JnFuVMq>1!cJbkW-RJQs`)trae
+md]rCf[9-ep#kQ5lK\6Dn*BW0naP`)o_nUUmI9]=p\OmdJbk]/RJJ#mo)A[hg7ig;&ciA'
+MU_[Zkk"B6o(2A=nFQDMqYU/@qNguGqB,_0nFut_m+H=i!#R*h)I:AIrUJq3oCVJ?oCi"Vqtks@
+QMR$G+8km.qtT^Ss*mTI!!!TQ0>lB,s7#@So_&(Zqt9RSqgnU0qO%+#p\=[]nF?>8D&7i
++E5*qr;>%8q#($`p%S?7qNguGqB#G*q>U3Xm.120N\M/,$P*4;-#V`Bs53;4oDcWL',E"s-P?CoF6)cUmdg/Pr.4^/qO.1%p@\7]q<[>4eGfL?rtZUT!#P\94nIn9
+nalGLr;HNgJbk]/RJJ$#pA+^`md0N>l/LP!!!aqQ,S:>Pqr@_Np%.nRr;6;@qNguFqAo>*r:odO
+q=aU`j8WQp(((Tk!+OX*o`+^Wo(MtXJbkZ.RJJ!&p\=X\nb)qZk5O$%ZN(FH!%.cNl/r$Gqsj.I
+q>5a>Q28W!rql`nrVZ`orqf%[rVl6`s7l9crqH0`rVlcnrVlWhqu$?fq"OF\s7Z*`rqH9hs7,LM
+qXs+QrVEaq!#5kA&ol@sp#tQ+p\k*irr7QGQMSMqs8)rsqtg*^rq8SPrVcNbq>0m^qu-Kkqtp0u>qNh!"qXO@ds82Qe
+qtTp]rVQTj!;ZTjs8;oo-i*c@q>($hq=XU_rr<#rmHOZ$\af_J&HiSMf)P0rq"OX_qY'RTq18C.
+qT8U5qZ-Klq#pKdq"jsert"krs8Vujqu-Bcp\FX[p\Xpc.f92Cr;?Eequ6NhrVl`fmcE3Pqu=cO
+CD6b":'ao^qnTJbk]/anl&9#lOSrq>'g\qY^?l62^WUo_&4`r;$6gq"++OqY9d[
+q"OOXqY^?kq"=F[r;$*VpAP$gq#16h]l!fM1'!-bkkG#Mo'GQ3p\=LUpA=l@qNh!"qEOrVqtg*^
+p@\7XqYBjTm-4!4p[@M@q"O[XmdKlHqY0^VoCDPJqu6Tdn+Q\Tp%@qMrr;o_jQ;Ls$ihDSL%50B%
+-HR?p#tl9p\=OZrVqHFQMS`"s7f=^p%.bDnFH2Ep\"%Bkj/6Cf#ltCnbM\=lh12Rq=O7HmdTlEr
+;H'Jo_\@Po)JR[o@TaM8,rW,AWb$mn`8rti8X1rnEofBqtp6erIOg2qT8U6oM+oGn*TH,kj7m7q
+YL!\m/QgtYgMk)p[72.p&=seo'bu4mdg/Mr9WS:qXj7GinEMorlTdg(FD1L9`=kgkNMO;s75UOm
+I^;Tr;$-`Jbk]/iVNQLs8)`lrqZTjrqfdlqu-Hfp\FaaqYTU9p]'LPf%p3$\bXP.jj7RP50`?Ue
+a3+qpAaaLnb2Pg?gq>pKhqt_E3q"t$fq"OU^qtL'co)JaUn#_l?kg]Y2nGgt.aoGQCs#'0CmIKo/nFcVQp\+F]s
+7u?ASo[L;!rrrB!!#2hZi:!ff`2!5d,k<-l29];nb;t\r;-qu-Hfp\Faco`+shr
+r))Z=$69>nc/15p[?np'0h!9s3:?2qtfj_s8;cjp[RV=jJuT<&cr%5$Q0K_O7MN!nET<=s2&/fM
+3YKOp>#34qY^9eq"jr?qNh!:qYpBlqYp