This is cssc.info, produced by makeinfo version 4.1 from cssc.texi. INFO-DIR-SECTION Miscellaneous START-INFO-DIR-ENTRY * cssc: (cssc). The GNU work-alike replacement for SCCS. END-INFO-DIR-ENTRY This file documents the the GNU `cssc' package for working with SCCS files. Copyright (C) 1997,1998,1999,2000,2001,2002 Free Software Foundation, Inc. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Foundation.  File: cssc.info, Node: Missing Features, Next: Known Problems, Up: Incomplete Missing Features ================ * Documentation is incomplete or missing. That includes this document. * Some programs are missing, that is, some programs are present in the SCCS suite and absent from this one. * On platforms where the C++ compiler used to compile CSSC does not support exceptions, the normal mechanism for recovering from an error in the processing of an SCCS file is unavailable. This means that if such an error occurs, the program will immediately make a fatal exit, as opposed to carrying on with the next file. In order to fix this problem, please either CSSC with a compiler which has working support for exceptions, or process just one file at a time. * Some programs behave subtly differently to their original counterparts. Error messages are different, and also extra warnings are provided in some circumstances. All other differences are also bugs. Please report them (*note Problems::). * Known bugs are listed on the bug tracking system at `http://sourceforge.net/bugs/?group_id=8064'. Some historical known issues are listed in the file `docs/BUGS'. Once this file has become obsolete it will be removed from the distribution. If an item on the TODO list (see the file `docs/TODO') has in fact been fixed, this is a bug in the TODO list. Please report this via the bug tracking system. * Some programs are partially implemented. Not all programs support all the command-line options of their original counterparts. Also, some features are currently missing. If you would like support for some feature that is missing, please request it in the same way you would report a bug; I'd like to know which features are required first.  File: cssc.info, Node: Known Problems, Next: Unemulated Features, Prev: Missing Features, Up: Incomplete Known Problems ============== There are a small number of known problems documented in the files `docs/BUGS' and `docs/TODO'. These will be fixed at some point in the future. Future problems should be reported via the CSSC Bug Tracker, at `http://sourceforge.net/bugs/?group_id=8064'. There are also some security problems with this code:- 1. Temporary file races -- CSSC opens many temporary files, most of them with very predictable names. This can be used as a lever for compromising the security of a system, often by anticipating the name of a file which will be opened at some point, and creating a symbolic link of the same name. Most of the temporary files used are created in the same directory as the SCCS file itself. CSSC should not be used by the owners of files whose security is important, especially to control files whose SCCS file is in a world-writable directory. *Note Filenames::. The `sccsdiff' program ignores the setting of the `TMPDIR' environment variable. Temporary files with predictable names are created in the `/tmp' directory. 2. Setuid execution -- It is common to install an extra set of binaries with the set-user-id bit turned on in their modes, to allow a specified group of users to make revisions to some important files. There are many ways in which a setuid program can be used by malicious users to gain access to the security privileges of the user as whom a program runs. CSSC has not been reviewed with the relevant security issues in mind. Please do not install CSSC programs with the set-user-id or set-group-id bits turned on. 3. Environment variables -- CSSC invokes external programs, notably the `diff' command and the program specified as the MR validation program. Some CSSC programs (for example `sccsdiff') invoke others. This is done without "cleaning up" the environment, and so this is another reason not to use the set-user-id bit for CSSC programs. *Note Environment::. Please refer to the section of the GNU General Public License entitled "NO WARRANTY" for information regarding the lack of warranty for this program. CSSC is _not_ a secure program, please do not rely on it to behave in a secure fashion. Contributions of code or patches to fix these problems are, as always, gleefully welcomed. Please submit these to the maintainer. Additionally, there is currently one problem that may not ever be fixed. This problem occurs only in the `prt' program when the list of ignored or excluded deltas is present for a SID _but that list is empty_. In this case SCCS prints the `Included:' or `Excluded:' line in its output (with no numbers afterward) and CSSC prints nothing. Since "fixing" this problem would require a horrible kludge, this has not been done. It is not expected that this will cause a problem for any users; if this is a problem for you, let the maintainer know and it will be fixed.  File: cssc.info, Node: Unemulated Features, Prev: Known Problems, Up: Incomplete Unemulated features =================== There are some features of (some implementations of) the traditional SCCS suite which it may not be desirable to copy. 1. If an SCCS file is created with the `-i' option, and it turns out to need encoding, then genuine SCCS seeks back to the start of the file and encodes it. However, if the input file is not seekable, for example if it is a pipe, then this doesn't always work. The SCCS file is then sometimes created containing only the initial part of the body, before the offending segment of the file. The exit value of the `admin' program is nevertheless still zero. Tests for this situation are in `tests/binary/seeking.sh' but these tests are only carried out if the program under test seems to be CSSC rather than the genuine SCCS suite. 2. The normal configuration for CSSC is that it supports binary files and has no limit on line length in file with which it deals. Both of these features may be different to the features of some version of SCCS with which you want to interoperate. See *Note Interoperability:: for more information on how to achieve better interoperability with other implementations of SCCS. 3. If you have a hard link to an SCCS file, then SCCS programs would "break" the hard link because the SCCS file is rewritten. For this reason, SCCS checks the link count on the file before using it. The SCCS suite also does this. While CSSC does this consistently, SCCS does not - for example the VAL program does not do this check. There are also a small number of respects in which various implementations differ from each other; in such cases CSSC picks a suitable alternative; *Note SCCS Version Differences::.  File: cssc.info, Node: Year 2000 Issues, Next: Testing, Prev: Incomplete, Up: Top Year 2000 Issues **************** Primordial (but not current) versions of the genuine SCCS suite fail to work correctly in and after the year 2000. The commands affected are `get' and `prs'. Unix vendors have ensured that the version of SCCS that they currently ship works correctly in the year 2000. Sun Microsystems, for example, state in their Year 2000 FAQ (`http://www.sun.com/y2000/faq.html') * *Does Sun see any problems with the source code control system (SCCS)?* No, Sun has adopted the X/Open Commands and Utilities Issue 5 standard, the year 2000 compliant version of SCCS will not be affected by the end of century transition. The X/Open standard states that old dates held in ("yy/mm/dd") format does not change in "s." files, but the values "yy" which range from 69 - 99 are to be interpreted as 1969 - 1999 respectively. Values of "yy" which range from 00 - 68 are to be interpreted as 2000 - 2068 respectively. This interpretation ensures that the year 2000 compliant version of SCCS will work at least to the year 2068. By implementing X/Open's standard, Sun has ensured SCCS user's compatibility with other providers of the SCCS utility. For more information please refer to: `http://www.xopen.org/public/tech/base/year2000.html' Copyright (C) 1994 - 1997 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA 94303 USA. All rights reserved. * Menu: * The Good News:: CSSC works with all dates from 1969 to 2038... * The Bad News:: ...but with hiccups on some operating systems. * Year 2000 Summary:: Parting words on date issues  File: cssc.info, Node: The Good News, Next: The Bad News, Prev: Year 2000 Issues, Up: Year 2000 Issues The Good News ============= Two-digit years are a problem in two places: firstly, within the actual SCCS files, and secondly within command-line options. The two-digit year fields in the SCCS files are correctly dealt with according to the strategy mandated by X/Open. The command-line options are also dealt with similarly. CSSC provides an additional feature for your convenience. If the argument to the `-c' option of `get', `prt', or `prs' contains more than twelve digits, the first two are understood to be the century part of the year. For example, `971120193000' and `19971120193000' both represent exactly the same time (7:30 p.m. on November 20, 1997). The fields of a date can be separated with other (non-digit) characters, and so `1997/11/20-19:30:00' also denotes the same time (but `1997/11/20' is an error because there are fewer than twelve digits). Some versions of SCCS are not year 2000 compliant and write incorrect timestamps into SCCS files. CSSC correctly understands the intended date, and will fix this problem when re-writing the file (*note Bug-for-Bug Compatibility: Bug-for-Bug.). CSSC represents dates internally in a way that works for Gregorian dates up to at least the year 32767 AD on all systems. Some countries didn't recognise the Gregorian calendar system until the early twentieth century but this of course is not really a problem now. The useful life of SCCS is from 1969 until 2068. Years are stored in two-digit form in SCCS files and so although CSSC has no such limits internally, it's not possible to indicate a year outside this range in an SCCS file if you want to retain compatibility with other implementations of SCCS. All the CSSC programs will successfully work with any date in this range, all the way up to 2068, on all systems. In this future, years after 2068 may be represented as four-digit fields, but CSSC doesn't do this yet. The CSSC test suite (*note The Test Suite: Testing.) contains some test files which may be useful in determining the date range with which your usual SCCS implementation will cope. These are in the directory `tests/year-2000'.  File: cssc.info, Node: The Bad News, Next: Year 2000 Summary, Prev: The Good News, Up: Year 2000 Issues The Bad News ============ It's not all good news though. When new deltas are created with the `delta' command, CSSC must consult the operating system to find the current date and time. Some operating systems have a limited range of date representation. For example, the development system I use for most of the work on CSSC can't report any date later than Tuesday Jan 19 03:14:07 2038 as the current time. When running on such systems, CSSC will still be able to work with SCCS files containing dates after this, but activities involving the current time will not work correctly. This date breakdown occurs most obviously with the date stamp that the `delta' program gives each delta in the SCCS file, but also with the commentary-change message of `cdc' and the default comment produced by `admin' when an SCCS file is created.  File: cssc.info, Node: Year 2000 Summary, Prev: The Bad News, Up: Year 2000 Issues Summary ======= To summarise, all reporting activities of CSSC will work correctly throughout the range of time representable in an SCCS file (that is, from 1969 to 2068 inclusive). However, commands which modify SCCS files and need to add dates may fail earlier than this (but then again, may not, depending on your operating system). Now that you know that whatever version of SCCS you are using has probably been fixed by the vendor, and that even if your vendor's SCCS implementation cannot be updated for some reason, CSSC is Year-2000 compliant and to an extent Year-2038 compliant, I'd like you to remember the conversion effort that this has saved you. I'd also like to urge to to actually use that effort to convert your existing projects from SCCS to a more modern version control system, for example GNU CVS. There are other considerations besides Year-2000 compliance, after all. CSSC is not called "Compatibly Stupid Source Control" for nothing.  File: cssc.info, Node: Testing, Next: Problems, Prev: Year 2000 Issues, Up: Top The Test Suite ************** The test suite is the most important single component of the CSSC suite. It ensures that ports to new platforms are working correctly, and that changes in one part of the suite don't accidentally break anything else. The test suites cannot cover everything. More are needed. If you only ever contribute one thing to CSSC, make it a new test case. This chapter explains how to run the test suite and also how to write new test cases. * Menu: * Running the tests:: Running the test cases. * Writing new test cases:: Writing new test cases.  File: cssc.info, Node: Running the tests, Next: Writing new test cases, Up: Testing Running the tests ================= Running the test cases is quite simple. Typically, you might do it after compiling but before installing CSSC. After running "configure", you might compile CSSC with make and test it with make check The full test suite takes just over five minutes to run on a 486 running Linux. If everything works correctly, you will see messages like:- cd tests && make all-tests make[1]: Entering directory `..../CSSC/compile-here/tests' cd ../lndir && make make[2]: Entering directory `..../CSSC/compile-here/lndir' make[2]: `lndir' is up to date. make[2]: Leaving directory `..../CSSC/compile-here/lndir' ../lndir/lndir ../../Master-Source/tests ../../Master-Source/tests/get: command-names: .././common/command-names test-common: .././common/test-common ...more messages from lndir... /bin/sh -ec 'cd admin && for i in *.sh ; \ do \ /bin/sh $i || break; \ done' C1...passed C2...passed .... more output .... C12...passed C13...passed PASS comment.sh: v1...passed .... more output .... b11...passed b12...passed PASS flags.sh: .... more output .... Tests passed. make[1]: Leaving directory `..../CSSC/compile-here/tests' If something goes wrong you will see a "FAIL" message, which looks something like this:- C1...FAIL comment.sh C1: ../../admin -ifoo s.new.txt: Expected return value 0, got return value 1 make[1]: *** [test-admin] Error 1 make[1]: Leaving directory `..../CSSC/compile-here/tests' Tests failed. make: *** [all-tests] Error 2 The thing to remember is that when you run `make check', the `make' program will print on the last line a message saying "Error" only if the tests have failed. If the test suite does indicate that the tests have failed, please submit a bug report (*note Problems::). Please include in your bug report * The output of the test suite (you may find the Unix `script' program invaluable for this) * The contents of the directory containing the test that failed (if you compiled with separate source and object directories, I just want the one in the "object" directory). * As much information about your system as you think is useful, for example the names and versions of the operating system and compiler that you are using. If you want to run just some of the tests, there are rules in the makefile for just running some of them. For example, the tests in the directory `tests/admin' can be run with `make test-admin'. Each test directory is named after one of the CSSC programs. This indicates which program the tests concentrate on verifying. Inevitably these tests will use more than just one CSSC program; for example, most of the tests involve using `admin' to create a SCCS file in the first place. However, the directory indicates which tool those tests concentrate on. If is possible for a test to neither pass or fail, but just go wrong. This can happen when the test script comes upon something that prevents the test itself working correctly, for example, because it can't remove a temporary file or uudecode a built-in sample SCCS file. When this happens you get output much like this:- $ sh flags.sh rm: foo: Permission denied flags.sh: Test could not be completed The part before the colon (`flags.sh') indicates which script could not be completed. No further tests will be attempted. Diagnosing the problem may or may not be simple. In this case, it's not hard; the problem is that the test suite is trying to clear away any temporary files but it can't remove the file "foo" (because the current directory was made read-only to force the test to miscarry, in this contrived case). When the test suite miscarries like this and you can't find the problem, please follow the bug-reporting procedure (*note Problems::), but please indicate that it is a miscarriage in the test suite rather than a concrete test failure.  File: cssc.info, Node: Writing new test cases, Prev: Running the tests, Up: Testing Writing new test cases ====================== The test cases are really just shell scripts. They are suitable for `/bin/sh' on most machines. The procedure for running these is explained in *Note Running the tests::. These shell scripts read in some common function definitions (mostly from `tests/common/test-common') and then proceed to conduct the tests. This section explains those commands used in the test scripts that are not simply normal shell commands. Normal shell commands like `sed' and `grep' are not described. The best approach for writing new test scripts or just individual new test cases is to first think of some aspect that needs better test coverage, and then to write the test script, basing it on an existing script. To make sure that your new tests are really checking for the right things, you can run them against an existing SCCS implementation other than CSSC. * Menu: * Testing the Test Suite: testing tests. How to test the test suite itself * docommand:: Run a command, checking its return value and output. * remove:: Remove a file if it is present. * success:: Declare that a test has passed. * fail:: Declare that a test has failed. * echo_nonl:: Print a string without a following argument. * miscarry:: When a test case cannot be run. * real-thing:: Some test scripts need to know which features to expect. * need-prt:: Not all implementations have prt  File: cssc.info, Node: testing tests, Next: docommand, Up: Writing new test cases Testing the Test Suite ---------------------- The best strategy for testing the CSSC test suite itself is to run it against a genuine edition of SCCS, if you have one available. Before running `make check', set the environment variable `dir' to point to the directory containing the programs to be tested; this should usually be `/usr/sccs'. In many implementations of SCCS, some of the tools execute others (for example, `delta' often executes `get' to retrieve the previous version of the controlled file). This means that to correctly test the test suite, your `PATH' environment variable should be set up to select the SCCS tools you want to test. Here is an example of the correct way to set up the environment to test SCCS tools in `/usr/ccs/bin' :- dir=/usr/ccs/bin PATH=/usr/ccs/bin:$PATH export dir make check When you are sure that the test script is expecting the correct behaviour from programs under test, you can then run it against CSSC. After all, if you're going to set out writing your test by assuming that CSSC is correct in the area under test, of what value is the test?  File: cssc.info, Node: docommand, Next: remove, Prev: testing tests, Up: Writing new test cases docommand --------- The `docommand' function runs a specified program, and checks its return value, standard output and error output against an expected version. If any mismatch occurs, `fail' is called. The `docommand' function is invoked with up to six arguments:- docommand [--silent] LABEL COMMAND RETVAL STDOUT STDERR The `docommand' function normally prints the label to indicate what stage the current test script has reached, followed by "done" when it has finished. The `--silent' option turns off this behaviour, so that if nothing goes wrong, no progress message is printed. This is occasionally used for commands that have already been tested by a script and are known to work, but which must be repeated several times in order to make some other kind of test, which is yet to come. I recommend you try to avoid using this option. The other arguments to `docommand' are:- LABEL This is what is printed to indicate what is going on when the test starts. If all goes according to plan, it is followed by `...done'. COMMAND This is the command to be executed, with all the required arguments. RETVAL This is the expected return value. If COMMAND exits returning any other value, `fail' will be called. If the test should not care about the return value, use `IGNORE' as RETVAL. STDOUT This is the text expected on the standard output of COMMAND. If the test should not care about the standard output, use `IGNORE' as STDOUT. STDERR This is the text expected on the error output of COMMAND. If the test should not care about the error output, use `IGNORE' as STDERR. This command will run `admin' with three arguments, and expect it to produce no output at all and return the value zero:- docommand C5 "${admin} -ifoo -yMyComment $s" 0 "" "" This command does something similar, but the command is expected to fail, returning 1 as its exit status:- # We should not be able to admin -i if the s-file already exists. docommand I7 "${admin} -ifoo $s" 1 "" IGNORE In the example above, the error messages produced by SCCS and CSSC are different, but both indicate the same thing. However, since the messages are different, `IGNORE' is used. The STDOUT and STDERR arguments are processed with the `echo_nonl' function, and so escape codes are valid and indeed heavily used:- # Test the -m (annotate SID) option with several deltas... docommand N4 "$get -p -m $s" 0 \ "1.1\tline1\n1.1\tline2\n1.2\tline3\n" \ IGNORE  File: cssc.info, Node: remove, Next: success, Prev: docommand, Up: Writing new test cases remove ------ The `remove' function is for clearing up temporary files after tests have finished, and for making sure that no instance of a file that a test is supposed to create already exists before the test is made. Typical usage is this:- f=1test s=s.$f p=p.$f remove $f $s $p The `remove' function is defined as:- remove () { rm -rf $* || miscarry Could not remove $* ; }  File: cssc.info, Node: success, Next: fail, Prev: remove, Up: Writing new test cases success ------- The `success' function prints a message indicating that the current test script has passed, and exits successfully. This is always done at the foot of a test script.  File: cssc.info, Node: fail, Next: echo_nonl, Prev: success, Up: Writing new test cases fail ---- If a test fails, it is usually because one of the `docommand' calls fails, and so direct calls to the `fail' function are rare. However, if you do want to call this function directly, you should supply as its argument a short description of what has gone wrong. For example, the `docommand' function uses `fail' in the following way:- fail "$label: $1: Expected return value $2, got return value $rv"  File: cssc.info, Node: echo_nonl, Next: miscarry, Prev: fail, Up: Writing new test cases echo_nonl --------- The `echo_nonl' function outputs its argument, without a following newline. Escape codes as for `echo(1)' are understood. Depending on the actual flavour of system that the test suite is running on, this might internally use `echo -n' or `echo -e .....\c'. Please do not use either the `-n' or `-e' options for `echo(1)' directly in test scripts, because they don't work in the same way on all machines. The `echo_nonl' function is provided for this reason; therefore, please use it. Please note also that while the `printf(1)' command may seem superior, it absolutely cannot be used because not all systems provide it. Typical usage of `echo_nonl' might be:- echo_nonl Please wait while I finish what I am doing... # ... echo done  File: cssc.info, Node: miscarry, Next: real-thing, Prev: echo_nonl, Up: Writing new test cases miscarry -------- The `miscarry' function is used to indicate that while the test suite has not found a problem with the programs being tested, there has been some other kind of problem that prevents further testing. Typical usage might be:- remove foo echo '%M%' > foo test `cat foo` = '%M%' || miscarry cannot create file foo.  File: cssc.info, Node: real-thing, Next: need-prt, Prev: miscarry, Up: Writing new test cases real-thing ---------- The various implementations of SCCS vary in several different ways, but the CSSC test suite tries very hard to pass when run against any genuine implementation of SCCS unless it has a definite bug. This means for example that although the CSSC version of `admin -i' will support automatic switch-over to binary mode for a file provided via stdin, and the test suite tests this, the same property is not required of SCCS itself. The `real-thing' script checks if we are actually tesing a real implementation of SCCS. It sets the environment variable `TESTING_CSSC' to `true' or `false', depending on whether we are testing CSSC or not. If you are really interested in whether the implementation being tested supports binary files or not, you should be using the `config-data' script instead.  File: cssc.info, Node: need-prt, Prev: real-thing, Up: Writing new test cases need-prt -------- The possible non-availability of `prt' is another thing that the CSSC test suite needs to know about in order to run successfully against all working versions of SCCS. Some versions of SCCS lack the `prt' program. For this reason, the tests for this tool (in the `tests/prt' directory) are skipped if `prt' is missing. When writing test scripts, you should never use `prt' unless you are actually testing `prt' itself (you can almost always use `prs' instead). If your test is specifically designed to test the functionality of `prt' itself on the other hand, just source `need-prt' before the first test. The `need-prt' script will skip the remainder of the invoking test script if `prt' is missing. You might use it like this, for example :- #! /bin/sh . ../common/test-common . ../common/need-prt s=s.testfile remove $s docommand e1 "${prt} $s" 1 IGNORE IGNORE success  File: cssc.info, Node: Problems, Next: Copying, Prev: Testing, Up: Top Reporting Bugs ************** If you find a bug in GNU `CSSC', please report this via the CSSC bug tracking system at `http://sourceforge.net/projects/CSSC'. Please include the version number, which you can find by giving the option `--version' to any `CSSC' command. Also include in your message the output that the program produced and the output you expected. An `s.' file and instructions for reproducing the error are almost essential unless the bug is very trivial. If you are unable to send the actual s-file itself due to confidentiality concerns, you can mask the contents by using the script `mogrify.awk', which removes the contents of an SCCS file while preserving its structure. You will need to use `admin -z' on the result in order to correct the checksum of the transformed version of the file. If you do this, please make sure that you check that the problem still occurs with the transformed version of the file. You may also find it helpful to join the mailing list. See the file `docs/mailing-list.txt' for information about the mailing list. If you have other questions, comments or suggestions about GNU `CSSC', contact the maintainer via electronic mail to `jay@gnu.org' .  File: cssc.info, Node: Copying, Next: BSD Code, Prev: Problems, Up: Top GNU GENERAL PUBLIC LICENSE ************************** Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 59 Temple Place - Suite 330, Boston, MA 02111, USA. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble ======== The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things. To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software. Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations. Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all. The precise terms and conditions for copying, distribution and modification follow. TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 1. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you". Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does. 2. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program. You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee. 3. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a. You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. b. You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. c. If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.) These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. 4. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a. Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, b. Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, c. Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable. If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code. 5. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 6. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it. 7. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. 8. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances. It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License. 9. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License. 10. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation. 11. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. NO WARRANTY 12. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 13. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Programs ============================================= If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. ONE LINE TO GIVE THE PROGRAM'S NAME AND AN IDEA OF WHAT IT DOES. Copyright (C) 19YY NAME OF AUTHOR This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA. Also add information on how to contact you by electronic and paper mail. If the program is interactive, make it output a short notice like this when it starts in an interactive mode: Gnomovision version 69, Copyright (C) 19YY NAME OF AUTHOR Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program. You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names: Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. SIGNATURE OF TY COON, 1 April 1989 Ty Coon, President of Vice This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.