Ringlord Technologies Products
$VER: Product-Info_Specification 8.0 (23.3.96) --------------------------------------------------------------------------- Product-Info Specification Version 8 March 23, 1996 --------------------------------------------------------------------------- PURPOSE A 'Product-Info' should accompany every released product: software, images, animation, sound, etc. The purpose of a 'Product-Info' is to describe a product in a way that is reasonably complete so that a customer can perform searches on a collection of 'Product-Info' files (records) with a reasonable expectation of locating desired products or excluding undesired ones. The structure of the data is designed so that a search can be defined with some certainty of its "correctness." By providing a well-written 'Product-Info' with your product, you assure yourself of maximum potential exposure to customers who are looking to fill a need that your product might fill. AUDIENCE This document is aimed both at the developer of a product who needs to write an effective and complete Product-Info, as well as at the customer who stands a better chance of locating satisfactory products without having to wade through an inordinate amount of irrelevant products, if she understands what a Product-Info offers. If you are not a developer, you may want to skip down to the EXPORTING AND IMPORTING DATA and the STANDARD FIELDS sections. COPYRIGHT The 'Product-Info' specification is free of copyrights and is freely distributable and available for use by any individual or organization that honors the basic ideas of this document: to provide a fairly concise and relatively burden-free description for a product. AUTHORSHIP The 'Product-Info' specification was designed by Udo Schuermann <walrus@RingLord.com> with initial design criteria and much feedback offered by Fred Fish <fnf@ninemoons.com> and Richard Fish <rjf@ninemoons.com> Support for 'Product-Info' files was first offered in the form of my product "KingFisher Release 2", which is available on Aminet, nearly all of the Fish CD-ROMs for the Amiga, and from the KingFisher home page on the World Wide Web: KingFisher 2 STORAGE A 'Product-Info' is a set of information stored in a file with your project. There are three standard filenames which you can use (the quotes are not part of the name): 1. "Product-Info" 2. ".Product-Info" (note the leading period) 3. "project.pi" ("project" would be replaced by your project's name; example: "KingFisher.pi" or "DiskSalv.pi" or "VT.pi" The file must conform to the following rules: 1. The file may begin with comment line, but is not required to do so. A comment is either a blank line (one that has no text, no blank spaces, no tabs) or a line beginning with a `'#' (hash) symbol. Any combination of these will be ignored at the BEGINNING of the file. 2. The first field (following the optional comments) in the 'Product-Info' must be "name"; Fields are identified by a Field Identifier and followed by their contents. Field contents are ended when another field is encountered or by the end of file. 3. A Field Identifier begins with a "." (dot, period) as the first character on a line, immediately followed by the name of the field. The "name" field is identified by ".name"; The name of the field is separated from the field contents by a white space. White space is a blank, a tab, or a new- line. It is recommended to use a newline, rather than space or tab. A field name cannot contain white space, obviously. 4. The contents of the field may span one or more physical lines in the file. Some fields ignore anything past the first newline; others will ignore newlines and treat them as if they were a normal blank space; other fields require newlines to separate sub-components from each other. It is the purpose of the file you are currently reading to tell you the meaning of each of the defined fields. 5. A collection of fields (beginning with the "name" field) represents a Product-Info record. A record is terminated by the end of file, by the presence of a blank line containing a ^N (control-N) symbol, or by the presence of another "name" field. Thus, a 'Product-Info' may store information for more than a single project, although this practice is in general not encouraged. This feature is used, however, for the construction of variant-record-size databases such as used by KingFisher, but these are not a distribution format that go along with a project. That's the difference. 6. Field names and field contents should use the ISO Latin 1 character set which is the default of the World Wide Web and also the standard of the Amiga computer. The character ^N (ctrl-n) is reserved as a separator between disks in a database of collected records, should this be a desirable feature. 7. If, in the contents of a field, a physical line of text begins with a period (such as ".guide files are provided...") then the period should have a "\" symbol added before the period, as in "\.guide files are provided..." to prevent the line to be interpreted as a new field ("GUIDE") with the contents starting as "files are provided..." In general, it is permitted to "escape" a period in this manner anywhere in a field's contents. 8. A backslash ("\") is represented by placing \\ in the contents of a field. This permits special layout control sequences to be introduced through the \ key, much like the "\." suppresses the interpretation of a line-leading period as the introducer for a field name. 9. Field name identifiers are not case sensitive. FUTURE EXTENSIONS The 'Product-Info' format was designed with future extensibility in mind. Being a text-only format, it lends itself to alteration with any editor of your preference. Its method of defining fields permits it to be adjusted and expanded to meet future requirements, and it is not tied to any particular implementation to facilitate searching. RECENT ADDITIONS The following fields have been added since the widely spread v6 of the 'Product-Info' specification: "aminet-dir", "aminet-file", "url", "keywords", and "execute"; some other fields have suffered some slight modifications: "author", "reference", and "installsize" with the aim to bring the fields in line with original intent. Also added or changed: \> \< \N \# sequences in field contents. KINGFISHER'S IMPLEMENTATION I believe it useful to provide the following information specific to KingFisher's implementation of 'Product-Info' support, as the databases and software are widely available on CD-ROM: 1. A KingFisher database is described by a .kfdb file, whose (textual) contents describes the filenames containing the actual database records, the files used for indexing these database files, as well as some other, less vital information. 2. A database consists of zero or more records spread over one or more files and is indexed by a single (primary) index file. Although KingFisher supports the format of (and is shipped with) the original KingFisher 1 database, it does not support adding such records to an existing database: The new format has a header to identify and distinguish the new format. The header is 8 characters (KF20DATA) plus a newline character. Index files are similarly identified by a KF20INDX header plus other information. 3. Records collected from 'Product-Info' files and stored into a database are stripped of their comments to preserve space. 4. As index files may become corrupted or lost, a special marker symbol is inserted on a line by itself between disks. This permits KingFisher to keep track of the disk on which a given item is stored and recover this information effortlessly if the index needs to be rebuilt. KingFisher 1 used a blank line between 2-line records; KingFisher 2 uses a line with a single ^N (ctrl-n) symbol on it. 5. A record begins with a "name" field and continues until another "name" field is encountered. 6. The efficient storage of variable-size records brings with it the problem of very costly insert and removal algorithms. KingFisher offers only truncation and append methods for this reason. 7. If a text file being imported (appended) to a database does not begin with a "name" field (nor comments) but the first line is less than 30 characters long, KingFisher will try to parse the file looking for a "name" field anyway, even though DATA TRANSPORT MARKERS (see next section, "Exporting and Importing Data") should have been used. This is a non- standard extension on this specification to facilitate support for the old KingFisher 1 database format. This ends the section on KingFisher's implementation of the 'Product-Info' standard. EXPORTING AND IMPORTING DATA To enable effortless and error-free methods for export and import of 'Product-Info' records, it is required to enclose records with DATA TRANSPORT MARKERS. These markers are NOT REQUIRED INSIDE OF 'PRODUCT-INFO' FILES; they are used only when unrelated text (and comments) surrounds a 'Product-Info' file! Multiple DATA TRANSPORT MARKERS may be used in a single text, so that each 'Product-Info' record is enclosed; or one pair of these markers may enclose multiple, consecutive 'Product-Info' records: EXAMPLE: The following examples are to be read as complete files between the lines that look like this: --------------- Example 1: A file containing text in addition to the database record. ---------------------------------------- Hello, Joe. Here is the description of that weird game I was telling you about. See if you can figure out how to win this. Good luck! .BEGIN-FISH-DESCRIPTION .name MonkeyCommand .author KingKong Industries .description Lure the love struck monster ape back to his island. Tools include Fay Wray's torn nightgown, a Fokker airplane (you get to pilot it), a compass and a map. \.png image support lets you paint your own airplane decals. .END-FISH-DESCRIPTION ---------------------------------------- Example 2: A file containing nothing but two database records. Notice that the DATA TRANSPORT MARKERS are omitted in this case, as they are unnecessary. It would not hurt to place them there, however! ---------------------------------------- .name MonkeyCommand .author KingKong Industries .description Lure the love struck monster ape back to his island. Tools include Fay Wray's torn nightgown, a Fokker airplane (you get to pilot it), a compass and a map. \.png image support lets you paint your own airplane decals. .name MonkeyCommand II .author KingKong Industries .description Keep the captured ape from assaulting the defenses of the prison that was erected at the conclusion of MonkeyCommand I. The game consists of coordinating the actions of four native tribal leaders and their vassals in repairing the damage done by the enraged monster ape as it tries to escape and revenge itself on whoever won the original MonkeyCommand. ---------------------------------------- Example 3: A file containing two database records interspersed with extraneous text. The records are protected by DATA TRANSPORT MARKERS ---------------------------------------- Hi Tom, Remember that monkey game you told my about? .BEGIN-FISH-DESCRIPTION .name MonkeyCommand .author KingKong Industries .description Lure the love struck monster ape back to his island. Tools include Fay Wray's torn nightgown, a Fokker airplane (you get to pilot it), a compass and a map. \.png image support lets you paint your own airplane decals. .END-FISH-DESCRIPTION Well, seems that one wasn't enough and they released another one. We'll have to figure out how to finally beat the first one, it seems, before they let us play the next. Maybe we can look through the binary to find that code phrase. Here's the text: .BEGIN-FISH-DESCRIPTION .name MonkeyCommand II .author KingKong Industries .description Keep the captured ape from assaulting the defenses of the prison that was erected at the conclusion of MonkeyCommand I. The game consists of coordinating the actions of four native tribal leaders and their vassals in repairing the damage done by the enraged monster ape as it tries to escape and revenge itself on whoever won the original MonkeyCommand. .restriction You need the secret code from the first MonkeyCommand which you can only get if you won that game. .END-FISH-DESCRIPTION (=:Joe:=) ---------------------------------------- STANDARD FIELDS The following are standard fields. Their meaning is fixed, although sometimes open to interpretation. Nothing forces you to obey these rules, but the closer you adhere to them, the more successful a search will be that relies on these rules. 1. If a field does not apply, or you have no data to supply, leave it out. You may provide a blank field, but this will have the same effect. 2. Pay attention to the FORMAT, which describes if a field is a single line field (ignores 2nd and further lines) or if it will flow its contents (ignoring YOUR newlines) or if it has any other constraints. 3. The only absolutely required field must also be the first field in any 'Product-Info': "name" =========================================================================== .name (absolutely required; must also be the first field) Purpose: The program's popular name. This is sometimes an abbreviated version of the "fullname" Format: 1 line only Example: KingFisher Example: HomeBase VI Example: BLAZEMONGER Example: AIBB Example: gcc .fullname (optional) Purpose: The full (or complete) name of the program if it differs from the "name"; omit this field if you would merely duplicate "name" Format: 1 line only Example: Amiga Intuition Based Benchmarks Example: GNU C Compiler .short (optional, but recommended) Purpose: A one-line description, preferably not exceeding 40 characters in length, à la Aminet. A single- glance to the program's purpose. Format: 1 line, best not to exceed 40 characters Example: Software catalog/search/maintenance tool Example: Full featured C/C++ package; CLI only Example: 230db sound, mind-reading, killer game .type Purpose: Categorize the package; multiple keywords permitted, but adhere as closely as possible to the list given at the end of this document. Wild variations will reduce the value of this field. Format: One or more lines, but best not to exceed a single word or two. Example: database Example: animation player Example: animation tool Example: spreadsheet Example: communications Example: display commodity Example: mouse commodity .description Purpose: A full-text description of your package, containing anything that is NOT ALREADY available through the other fields (above and below.) The reader should gain a good understanding what your program can and cannot do. If you mention other (similar) software, please add these also to the "reference" field. Please note that this field FLOWS text and is not designed for fixed-pitch ASCII graphics or other flash. If you need to insert a newline, do so with the "\n" sequence (backslash followed by a lowercase "n"); newline characters are treated as blanks. See the section on FORMATTING below! Format: Free form: Any number of lines, treated as a single stream of text and formatted according to embedded formatting symbols (see FORMATTING below.) Notes: The text should be readable regardless of the font that is used in its display, and regardless of the line width available (resizable window vs. printer) .version Purpose: The program's version number; please note that this should follow the standard guidelines for versions, as obeyed by most (but sadly not all, not even all system software): 37.1 < 37.17 < 37.39 < 37.100 < 37.170 The following are all vastly different versions: 37.1 37.10 37.100 37.1000 Format: One line only: MAJOR.MINOR Example: 37.100 Notes: Nothing requires you to maintain your versions this way, but you should be aware that some software may make use of this field by searching for a release that has reached, for example, at least version 2 (perhaps as a requirement that said software has been maintained by its author beyond some initial release 1); if your program's version is "v940205" then this would simply count as version 0 and could be missed. .date Purpose: The program's official release date. NOT the date when it made it into the database. Format: year.month.day Example: 1993.09.27 Example: 1996.01.01 Notes: The format was chosen to make it easily sortable. Note the use of leading zeros in month and day, and the complete year (with century.) .author Purpose: Any and all authors who have a part in the program. Format: Any number of lines, each name should be placed on its own line. Example: Joe R. User Tea Rexx Example: J. Jones Random Hacker Bone Head Notes: Addresses matching these authors should be placed into the .address field, one after the other, and in the correct order to produce a 1-to-1 relation. .address (optional) Purpose: Describe a full postal address of the author(s), to be used when it becomes necessary or desirable to contact the author by snailmail. Do not specify the author's name, as this already appears in the "author" field. Format: Multiple lines. Formatting symbols are not used, as physical newlines are respected. Example: 7022 Hanover Parkway, Apt. C2 Greenbelt, MD 20770-2049 USA .email (optional) Purpose: Full electronic mail address Format: Multiple lines, each having a 1-to-1 relation with the "author" field; more than one email address may appear on a line, separated by blank space (the preferred way) or by commas. Example: walrus@wam.umd.edu Example: walrus@wam.umd.edu walrus@uga.umd.edu .url (optional) Purpose: Universal Resource Locator, usually for ftp sites or World Wide Web support/home pages. Format: One or more lines, each on a 1-to-1 relation with the "author" field. More than one URL (Universal Resource Locator) may appear on a single line. Example: http://www.wam.umd.edu/~walrus/KingFisher.html Example: ftp://nowhere.com/Bogus.png .keywords (optional) Purpose: List as few or as many keywords as necessary to sum up the major features of this package. It is recommended to keep this entry to 10 keywords or less, but no definitive limit will be enforced. The idea with this field is to help construct a memory- resident quick index for systems that can afford to maintain a large amount of data in RAM. Format: One or more lines; keywords or keyphrases separated by white space (space, tab, or newline.) Example: fish disks library maintenance search expressions product-info .restrictions (optional) Purpose: If your software has any restrictions placed upon it, list them here, in detail. You should indicate if your package has been made dysfunctional (such as would be the case with a demo package.) If the program will not run on anything less than a 68020 CPU, you should list this here, to. Format: Free form (see "description") Example: Demo version has SAVE and PRINT disabled. Example: Documentation available only in German. Example: Disables video DMA while playing samples. Notes: List actual restrictions here, not minimum system requirements. .requirements (optional) Purpose: List minimum requirements for your program. These should give the reader enough information to determine if the software is likely to run on his/ her system. Be sure to specify operating system, (hard)disk requirements, non-standard libraries (such as MUI) and whether or not some or all of these required libraries are included in the distribution. Format: Free form (see "description") Example: 68020, 68030, or 68040 CPU; 3M free RAM; 18M disk space; at least 640�480 display capabilities and 16 colors or better. Example: Requires WB2.1 (V38) Example: Requires 1024�768 (or larger) displays. Example: Works only with 4096-channel, 230db BLAZETHUNDER audio board. Example: Requires MUI (Magic User Interface) version 10. .reference (optional) Purpose: List the full path to software in some way related to this package. This may include previous versions of your package or similar packages. The path is a volume:path/ or volume:path/archive Format: 2 lines per reference: the first is the path with trailing slash (if you do not give the slash then the name of an archive is assumed); the second line is the version number. Example: FishROM-0002:Productivity/Databases/HomeBase VI/ 417.0 FishROM-0001:Productivity/Databases/HomeBase VI/ 415.12 .distribution (optional) Purpose: Describe the distribution and ownership status of this software. Please see below for a list of the most common (and recommended) terms. Format: 1 line Example: shareware Example: commercial demo .price (optional) Purpose: If your package is available for a fee, describe this price here. it is strongly recommended that the first currency is expressed in US dollars to provide a common base unit for prices. If your package is freely available and has no price attached, then omit this field. Format: Free form but best adhere to examples. Example: $50(US), DM75 .installsize (optional) Purpose: The minimum and maximum sizes of the package as it is installed. The minimum size should give an indication of how much disk space is required for an absolute minimal installation. If the reader has less diskspace than that, the program is likely not to be able to function at all. The maximum is the absolute highest amount of diskspace that the package is likely to consume when all portions are installed (including optional tutorials, demo files, etc.) Format: One or more lines; only the first line has a fixed format, the rest are free-form. Example: 220K - 2400K Most of the database files can be kept on floppy disks, so valuable hard disk space is not wasted. Example: 18K Example: 38K - 500K Lots of documentation and example scripts make up the bulk of this installation. Notes: It is recommended that sizes are scaled to kilo- bytes to maintain a uniform scale, rather than expressing them in bytes or megabytes. Always add a size quantifier (K=kilobyte=1024bytes, M=megabyte, T=terabyte, etc.) .exectype (optional) Purpose: Describe the type of executable(s) that make up your program. Most packages are probably compiled C, but some may be shell or ARexx scripts, BASIC, AMOS, or otherwise interpreted. The reason for this is that some packages are known to cause problems on some systems, or the customer is looking for something "better" than interpreted BASIC and would like to know this before "wasting" time locating, downloading, and installing the package. Format: Free form (see "description") Example: Compiled C Example: AmigaBASIC .source (optional) Purpose: Describe what source code is available as part of your package. If source is not available, then omit this field. How large is the source? What compiler, translator, or interpreter is required? It might be good to give an idea of the version of the compiler that is required. Format: Free form (see "description") Example: SAS/C 6.56, Manx, DICE source (750K) available for $15(US); some old SAS/C 5.10b sources (30K) included free. Example: Limited C source examples (15K) included Example: All source plus custom libraries: 12M .construction Purpose: Describe the types of languages used to create this program and the methods used to build the final executable. If possible, include the compiler versions and possibly important options, such as optimization for various CPUs (it is possible to optimize somewhat for a 68040 without sacrificing 68000 compatibility.) Format: Free form (see "description") Example: SAS/C++ 6.56 with speed optimizations weighed for the 68040 CPU (68040 not required, however.) Example: AdaEd Example: Handcrafted assembly Example: Fortran with self-made compiler. Example: AMOS .tested (optional) Purpose: Give an indication of which configurations have served as test environments. If the software operates without problems with non-standard system enhancements, this would be a good place to mention them. Format: Free form (see "description") Example: A500(512K Chip, 0K Fast, 1 Floppy), A2000(1M Chip, 2M Fast, 40M HD, 1 Floppy); not tested on 68020+ CPUs. Example: A1000, A500, A600, A2000, A2000/30, A3000, A1200, A4000/30, A4000/40 with various amounts of Chip and Fast RAM, with and without MMU or FPU. Found to be free of Enforcer hits and able to work with virtual memory products; compatible with Retina, EGS/Spectrum, and Picasso software. Also tested under V33 through V40 system software. Example: CPU: 68000, 68020, 68030, 68040 (68060 unknown); Kickstart V37, V38, V39, V40; Video/Graphics: PAL, NTSC, Picasso II (Village Tronic and CyberGraphX), GVP EGS Spectrum (others unknown); Tested with system enhancements such as GigaMem 3.12, VMM 3.2, Enforcer 37.62, Executive 1.30, IPrefs2Fast 0.9b, OpaqueMove 1.0, KingCON 1.3. .run (optional) Purpose: Specifies how to start the program. Format: visible=type,command where 'visible' would be what the user would see and select; 'type' is either 'CLI' or 'WB' (the system interface) and 'command' is the program to execute. The 'CLI' version may include parameters, including I/O redirection, as this string is passed directly to the System() call. Example: HomeBase VI=WB,HomeBase VI HomeBase VI=CLI,ExecuteMe.HB6 HomeBase VI Fixer=CLI,ExecuteMe.HB6Fixer KingFisher=CLI,KingFisher Example: FishTub=WB,ExecuteMe Notes: As this item may be dangerous to the unsuspecting user, it has not been implemented by KingFisher and is not likely to be implemented. .execute (optional) Purpose: An 'execute' script. This entry has been added by Fred Fish; the script views the documentation, installs the software, or merely runs the program. Format: A shell script, line by line. Notes: It is not recommended that this entry be supplied by you, as Fred Fish may simply replace it with a version of his own. .docs (optional) Purpose: List all documentation files associated with your package. Do not specify the files if they are not available as-is; if they are only located within an archive, omit them. Format: 1 line per file, do not include the path as this is provided by the "stored-in" field. Example: HomeBase.guide HomeBase.dvi HomeBase.doc .described-by (optional) Purpose: Who created the description ('Product-Info' file) for this project. Format: Free form (should include an electronic mail address too, if available.) Example: Fred Fish <fnf@amigalib.com> Example: Udo Schuermann <walrus@wam.umd.edu> .submittal (optional) Purpose: Who submitted to package to Fred (or else how the package came to be on the reference disk.) Format: Free form (usually one line) Example: Submitted on disk directly by the author. Example: Downloaded from wuarchive.wustl.edu in pub/aminet/util/misc .stored-in Purpose: Specifies where and especially HOW the package is stored. This field should specify EITHER the name of a directory (ending with a ':' or a '/') OR the name of a file. In the case of an archive, the name should reflect that with the appropriate extension (.lha .zip .gz .Z etc.) Format: One or more lines Example: FF1000:d501-1000/Disk950/Enforcer/ FF1000:d501-1000/Disk950/Enforcer/Enforcer FF1000:BBS/d501-1000/Disk950/Enforcer/Enforcer.lha Notes: This field is usually generated by the disk creator software, not by the submitter of the package, as the final location on the disk may not be controlled by the submitter of the Product-Info. .path (obsolete) .aminet-dir (optional) Purpose: The path (WITHOUT trailing '/') where this package is available on the global Aminet. Format: One line; must NOT end with a '/' Example: biz/dbase Example: gfx/edit Notes: Together with aminet-file, this entry can be used to construct the complete path to this package on Aminet or Aminet CD-ROMs. .aminet-file (optional) Purpose: The name of the package (archive) as stored on Aminet. Example: KingFisher220.lha Example: VanGogh.lha Notes: Together with aminet-dir, this entry can be used to construct the complete path to this package on Aminet. =========================================================================== FORMATTING SYMBOLS Fields denoted as "free form" disregard the physical line breaks, performing word-wrapping of the text within the current margins of the display window or the printer's paper. To affect the layout to some degree, the following symbols may be inserted at strategic places in the text: \\ A single \ (backslash) symbol. \. A single . (dot) especially useful if/when such a dot is found (against normal practice) at the very beginning of a line of text and would then be misunderstood to represent a field-name-specifier. \n End of paragraph. Text following this symbol is forced to the beginning of the next visible line. Fixes all \= tab definitions into place. The next \= will cause all tabs to be cleared and a new one to be set. Some fields, notably the "description" field, may insert an extra blank line between paragraphs. If this is not desired, \N may be used instead. \N End of paragraph. Acts much like \n but will have no effect if two newlines (\n or \N) preceed it. Will also override the paragraph spacing of some fields (see \n above.) \N is useful in controlling excessive inter-field spacing. \> Indent (move left margin one tab stop to the right) until the next newline ("\n"). \< Un-indent (move an indented margin leftward again after the use of a \> indent symbol and before a \n is encountered.) \t Tabs to the next tab. Do not use tabs for paragraph indentation after a "\n". The implementation of tabs should, ideally, move the cursor to the next tab stop (to the right OR the left) so that the 3rd tab on a line actually moves to the 3rd defined tab stop. If this is not possible, it is recommended to suppress tab motion (or limit it to a single space) if leftward motion of the cursor is not possible. \= Sets a tab at the current horizontal position. The next \n will fix these tabs into place and prevent further additions until the tabs are cleared by the next "\=" (not yet implemented in KingFisher.) \# Toggle between verbatim and flow mode. Most fields are flow fields, meaning that newlines and multiple spaces are treated as a single space, and the end of paragraphs must be specified by an explicit \n sequence. The effect of \# is, therefore, dependent on the type of field in which it is used: in a flow field, the first \# toggles into verbatim mode where multiple blanks and newlines are passed on to the display. The creation of tabular displays is made easier in verbatim mode. EXAMPLES OF "TYPE" WORDS Action Game Animation Animation Player Animation Tool Archiver CLI Tool Communications Compiler Compression Database Disk Tool Display Commodity Drawing Image Conversion Image Processing Library Mouse Commodity Music Composition OS Utility Painting Picture Printing Sound Analysis Sound Editing Sound Playing Spreadsheet Strategy Game Text Text Editing Text Viewer Thinking Game Word Processing Workbench Tool LIST OF SOFTWARE STATUS KEYWORDS Commercial Commercial software is owned and distributed through licenses. It costs money to individual end-users and is not freely distributable. SUCH PIECES SHOULD NOT APPEAR ON DISKS THAT ARE MEANT FOR FREELY DISTRIBUTABLE SOFTWARE! Commercial Demo Represents a demonstration of a commercial package. As such, commercial demos are freely distributable and may have limitations as described in the .restrictions field. Giftware Like shareware, usually. Shareware Such software is owned and copyrights are held by the author(s). The software may be distributed freely, but not sold for profit, of course. Shareware often specifies a limit of some time after which you are requested or required to register the software (i.e. pay for it.) This provides you with the means to evaluate the software thoroughly before paying for it. Freeware Such software is owned and copyrights are held by the author(s). The software may be distributed freely, but not sold for profit, which would mean the software is no longer FREEware. No payments are required for such software. Public Domain Software labeled PD (Public Domain) belongs to the public, i.e. ANYONE. Some people release their software into the public domain with the mistaken idea that they can continue to own and control the program. Not so. Software that is labeled Public Domain (or said by the author to be released into the public domain) truly belongs to anyone and everyone. It is quite legal for someone to take such a program and sell it for profit as is. Likewise, it perfectly acceptable to modify public domain software to build a better product (or whatever) out of it and then sell it for profit. GNU Public License The terms and conditions of this license are long and not easily reproduced here. Suffice to say that software released under the GNU Public License must be distributed with source code. They are not public domain, however. GNU Library Public License The terms and conditions of this license are long and not easily reproduced here. Suffice to say that software released under the GNU Library Public License must be distributed with source code. They are not public domain, however. Copyright but Freely Redistributable The author holds all copyrights but allows the material to be freely distributed under specified conditions. #EOT
All content is copyright © Ringlord Technologies unless otherwise stated. We do encourage deep linking to our site's pages but forbid direct reference to images, software or other non-page resources stored here; likewise, do not embed our content in frames or other constructs that may mislead the reader about the content ownership. Play nice, yes?