[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
www/doc GNU-Press-styleguide.pdf GNU-Press-styl...
From: |
Matt Lee |
Subject: |
www/doc GNU-Press-styleguide.pdf GNU-Press-styl... |
Date: |
Wed, 08 Jun 2011 15:06:45 +0000 |
CVSROOT: /web/www
Module name: www
Changes by: Matt Lee <mattl> 11/06/08 15:06:44
Removed files:
doc : GNU-Press-styleguide.pdf
GNU-Press-styleguide.texi bibliography.html
contact.html expanding.html gnupresslogo.jpg
gnupresspub.html potentialauthors.html
small-gnupress.png teachingprofessionals.html
Log message:
Moved these files to www.fsf.org/campaigns/gnu-press/ -- redirects are
coming
CVSWeb URLs:
http://web.cvs.savannah.gnu.org/viewcvs/www/doc/GNU-Press-styleguide.pdf?cvsroot=www&rev=0
http://web.cvs.savannah.gnu.org/viewcvs/www/doc/GNU-Press-styleguide.texi?cvsroot=www&r1=1.1&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/doc/bibliography.html?cvsroot=www&r1=1.8&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/doc/contact.html?cvsroot=www&r1=1.13&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/doc/expanding.html?cvsroot=www&r1=1.13&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/doc/gnupresslogo.jpg?cvsroot=www&rev=0
http://web.cvs.savannah.gnu.org/viewcvs/www/doc/gnupresspub.html?cvsroot=www&r1=1.75&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/doc/potentialauthors.html?cvsroot=www&r1=1.19&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/doc/small-gnupress.png?cvsroot=www&r1=1.2&r2=0
http://web.cvs.savannah.gnu.org/viewcvs/www/doc/teachingprofessionals.html?cvsroot=www&r1=1.11&r2=0
Patches:
Index: GNU-Press-styleguide.pdf
===================================================================
RCS file: GNU-Press-styleguide.pdf
diff -N GNU-Press-styleguide.pdf
Binary files /tmp/cvsZpUREj and /dev/null differ
Index: GNU-Press-styleguide.texi
===================================================================
RCS file: GNU-Press-styleguide.texi
diff -N GNU-Press-styleguide.texi
--- GNU-Press-styleguide.texi 18 Jan 2009 16:07:12 -0000 1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,632 +0,0 @@
-\input texinfo @c -*-texinfo-*-
address@hidden %** start of header
address@hidden styleguide.info
address@hidden GNU Style Guide
address@hidden setchapternewpage odd
address@hidden edition-major-minor-number 4.15
address@hidden
address@hidden finalout
address@hidden %** end of header
-
address@hidden
- ## Summary of shell commands to create various output formats:
-
- ## Info output
- makeinfo --no-split --paragraph-indent=0 --verbose style.texi
-
- ## DVI output
- texi2dvi style.texi
-
- ## HTML output
- makeinfo --html --no-split --verbose style.texi
-
- ## Plain text output
- makeinfo --fill-column=70 --no-split --paragraph-indent=0 \
- --verbose --no-headers --output=style.txt style.texi
-
- ## DocBook output
- makeinfo --docbook --no-split --paragraph-indent=0 --verbose style.texi
-
- ## XML output
- makeinfo --xml --no-split --paragraph-indent=0 --verbose style.texi
-
address@hidden ignore
-
address@hidden
address@hidden 10
address@hidden @titlefont{A Style Guide for GNU Documentation}
address@hidden 12pt
address@hidden by Ron Hale-Evans
address@hidden 12pt
address@hidden Based largely on comments by Robert J. Chassell
address@hidden and Richard M. Stallman
address@hidden 0pt plus 1fill
address@hidden Copyright @copyright{} 2001 Free Software Foundation, Inc.
address@hidden titlepage
-
address@hidden
address@hidden Top, Basic points of style, (dir), (dir)
address@hidden A guide to writing documentation in the GNU style.
-
-Copyright @copyright{} 2001 Free Software Foundation, Inc.
address@hidden ifnottex
-
address@hidden
-* Basic points of style::
-* Ordering your text::
-* Code examples::
-* Metaphors::
-* English usage::
-* Texinfo usage::
-* Format while writing::
address@hidden menu
-
address@hidden Basic points of style, Ordering your text, Top, Top
address@hidden Basic points of style
-
address@hidden
-The goal of free GNU documentation is to help the users and developers
-of GNU software. There is no need for you to provide examples for
-software running under other operating systems. In particular, there
-is no need for you to provide examples for operating systems that take
-away your freedom.
-
address@hidden @bullet
address@hidden
-Show, don't just tell. Use plenty of examples (but don't be
-overly redundant).
-
address@hidden
-Move slowly. Do not impose too much of a cognitive load at once
-on the reader.
-
address@hidden
-Explain things in detail if you are writing a tutorial for a novice.
-Since one tends to under-explain anyway, pretend you are writing for
-an intelligent person who lives in an undeveloped country and is
-unfamiliar with the technology you are explaining.
-
address@hidden
-Don't say too little. If you cannot include enough information on a
-topic to do more than tantalize a novice, omit it entirely.
-
address@hidden
-Do not assume the reader has specific knowledge of mathematics or
-computer science when it is possible she doesn't. You may have to
-explain what an integer is or what a byte is, at least at the level of
-a tutorial.
-
address@hidden
-Explain your value judgments. For example, if you say a code snippet
-is or is not ``useful'', explain @emph{why} it is or is not. Value
-judgments can only be formed by people with knowledge of the relevant
-subject, and if the reader had the knowledge you use to form your
-judgments, she probably wouldn't need to read your documentation!
-
address@hidden
-If necessary, repeat yourself, especially if the information you are
-repeating is important and might be missed the first time. Also, if
-your reader is unlikely to remember a minor point that is nevertheless
-important to understand a major one, it is acceptable to repeat the
-information.
-
address@hidden
-Avoid editorializing, either about things outside the text (``As we
-know, every operating system but GNU sucks''), or about the text
-itself (``At last, we can address@hidden'').
-
address@hidden
-Design your text for a blind person; this is a good discipline.
-Documents, especially web pages, turn out much better. When you want
-to know how a document will sound to a blind person, you can run it
-through Festival or Emacspeak.
-
address@hidden
-Diagrams are sometimes helpful. Similarly, tables and lists of
-categories (variable types, types of operator, etc.) can help the
-reader encompass a large amount of information without a lot of
-superfluous connective text.
-
address@hidden
-Think of problems the reader might encounter --- ``gotchas'' that you
-might have experienced yourself --- then point them out. For example,
-in C and C++, point out the difference between @code{=} and @code{==}.
-
address@hidden
-Explain conventions. Note that software programming and usage often
-relies on conventions that are not obvious. For example, a @samp{0}
-return code in a C program signifies ``zero errors''. It is good to
-explain a convention such as this.
-
address@hidden
-Always tell people how to pronounce code when you introduce new
-terms. For example, if you are explaining pointers, tell the reader
-that @code{*my_ptr} can be pronounced ``the contents of the memory
-location @code{my_ptr}.'' The idea is to teach those who sound things
-out when reading to pronounce code the right way, rather than to come
-up with an idiosyncratic, personal method of reading, which can hurt
-their ability to learn the language.
-
-People who do not pronounce words, but depend entirely upon
-visualization, will not care much for this, but will not be hurt.
-Indeed, they will benefit, since they need to learn pronunciation in
-order to talk with other programmers.
-
address@hidden
-Qualify your statements. Don't simply say, for example,
-``Parameters must have their types declared.'' Must @emph{all}
-parameters have their types declared? If so, say so; if not, state
-which parameters must have their types declared and which must not;
-and give examples where necessary.
address@hidden itemize
-
address@hidden Ordering your text, Code examples, Basic points of style, Top
address@hidden Ordering your text
-
address@hidden
-Write about first things first.
-
address@hidden @bullet
address@hidden
-Write about the most important things in a section first. You may
-want to give each its own subsection. Don't make the mistake of
-writing, ``Blah, blah, and blah. Oh, and by the way, this is really
-important: @dots{}''
-
address@hidden
-Put important notes to the reader in subsections of their own.
-This tells the reader the notes really are important.
-
-While ``first things first'' usually applies, in some cases, the very
-end of a section is the best place for an important note, perhaps
-prefixed with @samp{@@address@hidden:@}}. People tend to remember
-best the things they are shown first and last. Also, an important note
-can sometimes tie up a section very nicely.
-
address@hidden
-Order the information in your nodes from simple to complex.
-
address@hidden
-Don't use terms without defining them, at least in a brief,
-preliminary way. Do not use them @emph{in the process of} defining
-them. Here, for example, is a classic error: @samp{This variable can
-take only @@address@hidden address@hidden: true and false.}
-
address@hidden
-Make your assumptions clear @emph{before} you use them. For example,
-if you assume that the reader knows basic trigonometry, say so before
-you launch into an example involving it. You might also give pointers
-to where the reader could @emph{learn} about the subject in question.
-
address@hidden 1500
address@hidden
-Recursion and nested data structures are difficult. Your text can
-easily get out of control. Be extra careful to phrase your
-explanations clearly so the reader does not end up in a tangle.
-
address@hidden @strong
address@hidden Bad:
-``All variables local to a block are invisible outside
-their block, but visible within every block their block contains.''
-
address@hidden Good:
-``A local variable is visible within its own block and
-the ones that block contains, but invisible outside its own block.''
address@hidden table
-
address@hidden
-If your chapter is titled ``About foo and
-bar'', do not discuss your topics in the order ``bar'' and ``foo''. Be
-parallel and consistent throughout the section in question. This may
-mean you will have to order your text carefully in advance, but your
-readers will thank you.
-
address@hidden
-If you have two tables or lists of information that discuss the
-same items, combine them! Don't make the reader flip from one to the
-other, correlating them in her head.
-
address@hidden
-Don't combine different topics in the same paragraph or node. If
-you want to start a new topic, start a new paragraph or a new node.
-
address@hidden
-After you have made an important point in a paragraph, end the
-paragraph and let the reader ``walk away with'' that information.
-Don't clutter the paragraph with details, trailing off into
-irrelevance; save the details for later.
-
address@hidden
-When you are explaining a feature of a program, it is often helpful to
-awaken the reader's interest by first outlining a problem the feature
-solves or a need it fulfills. Write text that ``motivates'' the
-reader to understand why the feature is needed. You should assume
-that most people will not themselves think that they need the feature
-ahead of time, and that when the feature is introduced, only the
-really smart readers will figure out for themselves why it is a good
-idea.
-
address@hidden itemize
-
address@hidden Code examples, Metaphors, Ordering your text, Top
address@hidden Code examples
-
address@hidden
-Examples should follow the GNU style. Consult the @cite{GNU
-Coding Standards} for further information.
-
address@hidden @bullet
address@hidden
-Give sample output for code examples wherever possible.
-
address@hidden
-Don't waste the reader's time with frivolous examples that have no
-real use. For example, in the @cite{GNU C Tutorial}, it was judged too
-frivolous to show the reader how to print out the values of pointers (of
-the pointers themselves, not the addresses pointed to), even though
-earlier editions of the book had done so.
-
address@hidden
-When you discuss a function, do not include the parentheses in
-its name unless you are illustrating a function call. For example, use
address@hidden rather than @code{cos()}.
-
address@hidden
-In an example, snuggle code up to the @code{@@example} and
address@hidden@code{@@end example}} lines; do not insert blank lines between the
-lines containing the formatting commands and the lines containing the
-code.
-
address@hidden
-Always check your code examples by compiling and running them before
-including them in your text. This applies even to small examples.
-Double-check your mathematical examples as well as your code. Nothing
-will make your reader lose confidence in your documentation faster
-than catching you in a simple error.
-
address@hidden
-Use the present ``timeless'' tense when talking about what a code
-example does. Example: ``The @code{foo} function takes an integer
-variable @code{bar} and multiplies it by 5.''
-
address@hidden
-Put ellipses inside dummy code blocks, unless you want to imply
-they are no-ops.
-
address@hidden
-In examples of code, use all-caps only for macros and the like that
-are normally written in uppercase letters. Use lowercase letters for
-everything else.
-
address@hidden
-Don't use examples that will become dated. You don't know how
-long your text will be read. Example: If you are writing in the year
-2002, and you want to use an example of a variable containing a year,
-rather than creating a variable called @code{cur_year} and making it
-equal to @samp{2002}, it is better to create a variable called
address@hidden and make it equal to @samp{1969}.
-
address@hidden
-In your code examples, use variable names that are concrete rather
-than abstract. Concrete names are less confusing. For example, a
-variable called @code{cost_of_lunch} is better than one called
address@hidden or @code{foo}. On the other hand, do not use
-variable names that are so concrete that the example itself takes over
-and the lesson it is supposed to convey is lost.
-
address@hidden
-Satisfy the reader's curiosity about whether alternate coding
-practices are possible, but make your recommendations clear.
address@hidden itemize
-
address@hidden Metaphors, English usage, Code examples, Top
address@hidden Metaphors
-
address@hidden
-People reason using metaphors.
-
address@hidden @bullet
address@hidden
-Develop your metaphors explicitly. For example, if you say local
-variables are ``invisible'' outside their functions, explain that this
-usage stems from a metaphor in which functions are something like
-buildings and local variables are like people looking from one building
-to another.
-
address@hidden
-Jargon often has a metaphorical underpinning. For example,
-pointers ``point to'' memory addresses. It is helpful to explain these
-metaphorical underpinnings when introducing a jargon term.
-
address@hidden
-Explain where your metaphors fail. For example, when explaining
-pointers in C, explain that while, with the same finger, you can point to
-anything you like in real life (whether it be animal, vegetable, or
-mineral) a given pointer can only point to a certain type of variable
-(only to integers or only to floats, for example).
-
address@hidden
-Use a metaphor consistently; do not mix metaphors.
-For example, when discussing local variables, do not at one point say
-they are ``invisible'' outside their functions and at another point
-say that they are ``nonexistent'' outside their functions. Stick to
-one metaphor or the other.
-
-If you @emph{must} use more than one metaphor, introduce transitional
-material and explain how and why you are switching metaphors.
-
address@hidden
-Avoid idioms and implicit metaphors wherever possible.
-People translate GNU documentation into many different languages.
-English idioms such as ``this feature opens the door to the
-possibility of @dots{}'' only make more work for translators whose
-languages do not possess the idiom.
address@hidden itemize
-
address@hidden English usage, Texinfo usage, Metaphors, Top
address@hidden English usage
-
address@hidden
-!!! is it really true that early editions of `The Elements of Style'
-are now in the public domain? I cannot find my copy to check when it
-was first copyrighted. In the US, the recent change in law kept books
-that were published between 1923 and 1941 out of the public domain.
address@hidden ignore
-
address@hidden
-Consult good books on English style. For example, a classic text is
address@hidden Elements of Style} by Strunk and White. Early editions of
-it are now in the public domain and are therefore free in the GNU
-sense.
-
address@hidden
-Also consult the @cite{GNU Coding Standards}, which discusses
-documentation as well as code.
-
address@hidden @bullet
address@hidden
-Don't mention non-free software by name unless it is unavoidable.
-
address@hidden
-Refer to GNU more and Unix less.
-
-Always write ``GNU/Linux'', never just ``Linux'', unless you are
-only referring to the Linux kernel.
-
address@hidden
-Use ``illegal'' only for matters of the law and government. For
-violations of the rules of C or other languages, use ``invalid''.
-
address@hidden
-Always address the reader as ``you''. Example: ``If you want to
-display the diagram, press the @key{RET} key.''
-
address@hidden
-Use ``must'', ``should'', ``may'', and ``can'' appropriately. Do not
-conflate them when discussing actions you must, should, may, or can
-perform while using software.
-
address@hidden
-Examples are not ``given'' but ``shown''. Only
-useful stand-alone programs qualify as gifts.
-
address@hidden 1500
address@hidden
-``Kinds of'' and ``types of'' are followed by a singular noun.
-For example:
-
address@hidden @strong
address@hidden Bad:
-``kinds of computers'', ``types of variables''
-
address@hidden Good:
-``kinds of computer'', ``types of variable''
address@hidden table
-
address@hidden
-There should be no text between ``as follows'' and what is said to
-follow.
-
address@hidden 1500
address@hidden
-Be careful to separate English from C code (or the code of whatever
-computer language you are using). For example, in the first example
-below, the English word ``or'' might be confused by the reader with
-the Boolean operator @sc{or}.
-
address@hidden @strong
address@hidden Bad:
address@hidden@@address@hidden address@hidden (or operator on Boolean values)}
-
address@hidden Good:
address@hidden@@address@hidden address@hidden (an operator on Boolean values)}
address@hidden table
-
address@hidden
-Failure to process negatives is a common problem in reading. Phrase
-your text so that a reader is not likely to miss an important ``not''.
-Do not repeat the negative information in a manner that could make it
-appear positive.
-
address@hidden
-Distinguish computer science terms and jargon from the language of the
-reader's everyday experience. For example, you may need to tell the
-reader that the Boolean value @code{true} is true and only true, while
-in real life ``true'' might mean ``only partly true'', as in ``that's
-a true story, although parts are exaggerated''.
-
address@hidden 1500
address@hidden
-Most people except LISP programmers dislike parentheses. Use as
-few as possible. If you can, avoid using parentheses in tables.
-
address@hidden @strong
address@hidden Bad:
-unary plus (example: @code{+5})
-
address@hidden Good:
-unary plus, example: @code{+5}
address@hidden table
-
address@hidden
-Use language precisely. For example, when discussing C, a
-``declaration'' is not the same as a ``definition''. Many distinct
-terms sound alike and are used in similar ways, but that is no excuse
-for @emph{you} to conflate them, or to fail to distinguish them for
-your readers. Moreover, don't simply say that two terms are
-different, but explain their differences.
-
-Similarly, distinguish one use of a jargon word from another. For
-example: ``value of a variable'' vs. ``passing by value''.
address@hidden itemize
-
address@hidden Texinfo usage, Format while writing, English usage, Top
address@hidden Texinfo usage
-
address@hidden
-Please read the Texinfo manual through; it will do you good.
-
address@hidden @bullet
address@hidden
-Use @samp{@@code}, @samp{@@samp}, @samp{@@file}, etc. correctly;
-for clarification,
address@hidden
-see the @cite{Texinfo Manual}.
address@hidden iftex
address@hidden
-see the @cite{Texinfo Manual}.
address@hidden ifhtml
address@hidden
-see @ref{Top, , , texinfo, The Texinfo Manual}.
address@hidden ifinfo
-
address@hidden
-Use @samp{@@xref} properly; never use it in mid-sentence.
-
address@hidden
-To emphasize, use @samp{@@emph} or @samp{@@strong}, not all-caps.
-
address@hidden
-For meta-syntactic variables, use @samp{@@var}, not angle brackets.
-
address@hidden
-End every sentence with two spaces so Emacs can see where
-sentences begin and end. (See
address@hidden
-the ``Sentences'' section in @cite{The GNU Emacs Manual},
address@hidden iftex
address@hidden
-the ``Sentences'' section in @cite{The GNU Emacs Manual},
address@hidden ifhtml
address@hidden
address@hidden, , The GNU Emacs Manual, emacs, The GNU Emacs Manual},
address@hidden ifinfo
-which describes convenient sentence-related commands.)
-
address@hidden
-Use @samp{@@group} to hold together examples that should stay all
-on one page.
-
-Note that the @code{@@group} command does not currently work with the
address@hidden@@table} command. Instead, use the @code{@@need} command with
address@hidden@@table}. Similarly, use the @code{@@need} command before a
-plain text paragraph that introduces an example or list.
address@hidden
-(See the @cite{Texinfo Manual}.)
address@hidden iftex
address@hidden
-(See the @cite{Texinfo Manual}.)
address@hidden ifhtml
address@hidden
-(@xref{Top, , , texinfo, The Texinfo Manual}.)
address@hidden ifinfo
-
address@hidden
-Never use typesetting commands for markup! Always use logical
-markup instead. You gain nothing in Info by putting ``Important:'' in
-boldface. Unless your reader uses an unusual stylesheet, you will not
-help Emacspeak, either. Replace @samp{@@address@hidden:@}} with
address@hidden@@address@hidden:@}} so formatting software can figure out
-how to handle the markup appropriately. The use of typesetting markup
-is the bane of the HTML world; logical markup works better, and one
-reason that XML was invented.
-
-The only legitimate use of a typesetting command in GNU
-documentation is to cause plain, explanatory text in a table or example
-to be in a Roman font. Use the @code{@@r} command to do this.
-
address@hidden itemize
-
address@hidden Format while writing, , Texinfo usage, Top
address@hidden Format As You Write
-
address@hidden
-Format your text as you write. This eases your final cleanup.
-
address@hidden
-Then, at the end of your project, again check how your text will look
-in Info, on a Web page, and typeset for printing. Listen to it as
-well; or, at at the very least, consider how it sounds when read out
-loud.
-
address@hidden @bullet
address@hidden
-As you write, make sure your file will compile as an Info document.
-In GNU Emacs, you can do the following:
-
address@hidden
address@hidden
-Run @kbd{C-c C-m C-b} (@code{makeinfo-buffer}), then
address@hidden
-run @kbd{C-u C-c C-u C-a} (which is @code{texinfo-all-menus-update},
-with a prefix argument); then
address@hidden
-fix the remaining errors, then
address@hidden
-repeat this sequence until there are no more errors.
address@hidden enumerate
-
address@hidden
-Run the spell-checker!
-
address@hidden
-When polishing the text, make sure your page layout is attractive; for
-example, make sure you don't use too much whitespace. You can group
-chunks of text together with the @code{@@group} and @code{@@need}
-commands.
-
address@hidden 1500
address@hidden
-In tables and code examples, line up columns neatly:
-
address@hidden:}
address@hidden
-a: 1
-b : 2
-c:3
address@hidden smallexample
-
address@hidden:}
address@hidden
-a : 1
-b : 2
-c : 3
address@hidden smallexample
-
address@hidden
-When you email your manuscript to your editor, consider compressing it
-with @code{gzip} and sending it as a uuencoded or base-64 encoded
-attachment. This will prevent it from being mangled in email. Some
-email programs transform a @samp{From} at the start of a line to
address@hidden>From}. Gzipped and encoded attachments are not vulnerable to
-this sort of corruption. (Short documents without a @samp{From} at
-the start of a line do not need to be compressed and encoded.)
-
address@hidden
-As I said before, look at your text in all three major output formats:
-in Info, on a Web page, and typeset for printing. In addition, listen
-to it; or else consider how it sounds when read out loud.
address@hidden itemize
-
address@hidden
-
Index: bibliography.html
===================================================================
RCS file: bibliography.html
diff -N bibliography.html
--- bibliography.html 15 Jan 2009 15:54:16 -0000 1.8
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,308 +0,0 @@
-<!--#include virtual="/server/header.html" -->
-<title>Documentation of the GNU project - Bibliography of Legal Writings on
the GPL</title>
-<!--#include virtual="/server/banner.html" -->
-<h2>Bibliography of Legal Writings on the GPL</h2>
-
-<h3>CASE LAW</h3>
-
-<p>
-PLANETARY MOTION, INC. v. TECHSPLOSION, INC., 261 F.3d 1188 (11th
-Cir. 2001) (“Software distributed pursuant to [the GNU General
-Public License] is not necessarily ceded to the public domain and the
-licensor purports to retain ownership rights, which may or may not
-include rights to a mark”).
-</p>
-
-<h3>LAW REVIEW ARTICLES</h3>
-
-<p>
-Patrick K. Bobko, LINUX AND GENERAL PUBLIC LICENSES: CAN COPYRIGHT
-KEEP “OPEN SOURCE” SOFTWARE FREE?, 28 AIPLA Q.J. 81 (2000)
-(“Using Linux as the subject of analysis, this article discusses
-the enforceability of the licenses that protect non-proprietary
-software and keep it ‘open-source.’ The analysis involves
-two primary issues: whether the improvements made to Linux are
-derivative works or are themselves copyrightable, and whether the GPL
-is an enforceable non-exclusive license.”).
-</p>
-
-<p>
-Patrick K. Bobko, OPEN-SOURCE SOFTWARE AND THE DEMISE OF COPYRIGHT, 1
-Rutgers Computer & Tech. L.J. 51 (2001) (“With the emergence
-of open-source software (‘OSS’), some of the debate over
-copyright protection has taken a new focus. Although OSS depends upon
-copyright protection for its continued existence, the economic
-incentives of OSS are not the traditional economic incentives assumed
-by copyright law because they do not arise out of a monopoly of the
-copyrighted material. As a result, copyright law plays a diminished
-role in OSS. Part I of this article examines the economic foundation
-of the commercial software industry and its reliance upon copyright
-law, highlighting the current debate concerning the appropriate level
-of software protection for a program's non-literal elements. Part II
-examines OSS and its impact on the information industries with
-particular emphasis on its freedom from market pressures and technical
-superiority over its proprietary counterparts. This article concludes
-that although some copyright protection is required to perpetuate the
-open-source movement, OSS' emergence has substantially mooted the
-current debate over the appropriate level of protection for a
-program's non-literal elements.”).
-</p>
-
-<p>
-Robert W. Gomulkiewicz, HOW COPYLEFT USES LICENSE RIGHTS TO SUCCEED IN
-THE OPEN SOURCE SOFTWARE REVOLUTION AND THE IMPLICATIONS FOR ARTICLE
-2B, 36 Hous. L. Rev. 179 (1999) (“This Article examines the
-origins and continuing momentum of the open source revolution. It then
-discusses the principles of open source licensing and why licensing is
-central to the open source revolution. The Article concludes by
-discussing the implications that copyleft licensing principles have
-for proposed Article 2B of the Uniform Commercial Code
-(‘UCC’), a provision that would govern software licenses.
-The Article points out that in order to foster innovative developments
-such as the open source revolution, Article 2B needs to, among other
-things, validate the enforceability of standard-form mass-market
-licenses, preserve the ability of software developers to freely
-allocate risk, and provide sensible contract default rules.”).
-</p>
-
-<p>
-Teresa Hill, NOTE: FRAGMENTING THE COPYLEFT MOVEMENT: THE PUBLIC WILL
-NOT PREVAIL, 1999 Utah L. Rev. 797 (1999) (“This Note analyzes
-the copyleft movement from the traditional sociological perspectives
-of social movement theory. Specifically, this Note investigates
-whether the copyleft movement will effectuate any change in
-intellectual property considering the fragmentation of the movement by
-emerging market changes. In Part II, this Note examines the
-historical development of copyright and its application to computer
-software, specifically focusing on courts' inconsistent application of
-copyright law to new technology. Part III next examines what the
-copyleft movement is, how the copyleft movement developed, and how the
-general criticisms of traditional notions of copyright as applied to
-computer software are incorporated into the copyleft movement. Part
-IV analyzes the copyleft movement and its fragmentation, arguing that
-to the public's detriment, copyleft will not be the force that drives
-the nail in the coffin of copyright. In conclusion, this Note argues
-that the fragmentation of the copyleft movement will ultimately render
-it unable to affect radical legal changes in intellectual
-property.”).
-</p>
-
-<p>
-Natasha T. Horne, OPEN SOURCE SOFTWARE LICENSING: USING COPYRIGHT LAW
-TO ENCOURAGE FREE USE, 17 Ga. St. U. L. Rev. 863 (2001) (“Part I
-of this Note reviews the history and philosophies of the open source
-movement. Part II discusses the roles copyright and software
-licensing play in open source software development. Part III examines
-the licensing terms of several popular open source licenses used
-today. Part IV provides a few pointers for selecting a license.
-Finally, Part V suggests that the open source movement may be
-disproving the need for financial incentives under copyright
-law.”).
-</p>
-
-<p>
-Nigel Howard, Dan Ravicher, Ken Johnson, HOW TO USE PATENT LAW TO THE
-ADVANTAGE OF OPEN-SOURCE SOFTWARE DEVELOPERS, 7 NO. 7
-Intell. Prop. Strategist 1 (May 2001) (“At first glance, patent
-law appears to impede those engaged in the free distribution of
-software: Software patents give their owners the right to prevent
-others from practicing the claimed software. However, patent law may
-in fact be a potential friend to those engaging in open-source/free
-software development. But the picture is not all rosy. To evaluate
-how best to take advantage of patent law to achieve an open-source
-software developer's business objectives, you need to be aware of both
-the potential benefits and pitfalls that patent law poses to
-open-source development.”).
-</p>
-
-<p>
-Dennis M. Kennedy, A PRIMER ON OPEN SOURCE LICENSING LEGAL ISSUES:
-COPYRIGHT, COPYLEFT AND COPYFUTURE, 20 St. Louis U. Pub. L. Rev. 345
-(2001) (“This article … discuss[es] the Open Source
-history and the role of the Open Source Definition, describe[s] the
-general categories of Open Source licenses, survey[s] generally some
-of the legal issues raised in the Open Source approach and with the
-Open Source licenses, and draw[s] some tentative conclusions about the
-likely impact of Open Source on traditional copyright and licensing
-law as it becomes a more significant component of the Internet and
-computer systems, as well as a part of our way of thinking about
-intellectual property and licensing in a rapidly changing
-world.”).
-</p>
-
-<p>
-Marcus Maher, OPEN SOURCE SOFTWARE: THE SUCCESS OF AN ALTERNATIVE
-INTELLECTUAL PROPERTY INCENTIVE PARADIGM, 10 Fordham
-Intell. Prop. Media & Ent. L.J. 619 (2000) (”This paper
-… provid[es] a factual introduction into the details of the
-open source development process. Next, a background introduction to
-complexity theory [is] provided. The features of open source
-development [are] then … analyzed, uncovering the complex
-nature of open source development. While the complex nature of open
-source software provides an explanation as to its technical success,
-it also provides insight into a number of problems that are facing the
-open source community. The threats to the complex nature of open
-source development [are] considered and means of circumventing these
-problems suggested. Finally, the potential for complexity to solve
-some anticipated open source problems [is] discussed.”).
-</p>
-
-<p>
-David McGowan, LEGAL IMPLICATIONS OF OPEN-SOURCE SOFTWARE, 2001
-U. Ill. L. Rev. 241 (2001) (“Using the GNU/Linux operating
-system as a case study, [Professor McGowan] probes the organization of
-the open-source community and the philosophies of its leading members
-in order to understand how traditional firm models, intellectual
-property, and contract law might apply. Professor McGowan concludes
-by reviewing recent attempts by courts to impose traditional
-principles in computer software transaction disputes. Ultimately, it
-appears that the open-source community cannot be neatly categorized.
-Although many traditional firm theories—such as the formation of
-a hierarchy—and legal principles—such as
-copyright—do apply to the open-source model, these theories and
-principles are employed in creative ways not previously
-envisioned.”).
-</p>
-
-<p>
-Stephen M. McJohn, THE PARADOXES OF FREE SOFTWARE, 9 Geo. Mason
-L. Rev. 25 (2000) (“For many software producers, the fact that
-their customer receives only the executable code is important. The
-producer attempts to maintain control over the code in two ways. She
-can deliver only the executable code, so the licensee can run the
-program but little else. She can also deliver the code subject to a
-license that restricts further copying and distribution, so the
-licensee does not turn around and sell or give copies to other
-potential customers. Open source software producers, by contrast,
-grant much freer access, both practically and legally, by delivering
-source code along with the executable code, and by freely granting
-permission to modify and further distribute the software. As
-discussed in the [article], open source software both challenges the
-theoretical underpinnings of intellectual property law and promises to
-affect the development of intellectual property law.”).
-</p>
-
-<p>
-Shawn W. Potter, OPENING UP TO OPEN SOURCE, 6 Rich. J.L. &
-Tech. 24 (2000) (“This paper is structured to address several
-purposes in its discussion of the open source movement. First, Part
-III … discuss[es] on a broad level how society benefits from a
-software development process like open source, and how open source
-affects copyright and traditional notions of software piracy and
-reuse. Part III … also reviews[s] solutions that open source
-offers and outline the problems that may occur as the open source
-model continues to unfold. Part IV … considers the
-contemporary objections to open source products, and …
-demonstrate[s] that copyright, licensing, and warranties—the
-legal issues in software—basically make purchasers no worse off
-under an open source environment than a proprietary paradigm. As
-such, businesses and consumers should not shy away from open source
-products. Part V crystalizes the underlying issue in this paper: open
-source has many beneficial aspects, but still, the market has been
-slow to accept it. The article concludes with possible solutions to
-the problem of slow acceptance, as the author asserts that both the
-market and government can take steps to foster the growth of open
-source. In the end, the reader will recognize that the traditional
-objections to open source software are fairly minimal. While open
-source may not reach revolutionary status, it opens the door to
-positive changes regarding intellectual property rights and
-licensing.”).
-</p>
-
-<p>
-Daniel B. Ravicher, FACILITATING COLLABORATIVE SOFTWARE DEVELOPMENT:
-THE ENFORCEABILITY OF MASS-MARKET PUBLIC SOFTWARE LICENSES, 5
-Va. J.L. & Tech. 11 (2000) (“Although numerous claims of
-infringement and threats to seek legal resolution of software
-copyright issues have been made, no court ha[d] yet ruled on the
-enforceability of public software licenses. As a result, companies
-desiring to follow the open model of software development must bear
-the cost of this legal uncertainty, which, in turn, reduces the
-ability of these companies to compete in markets occupied by closed
-model firms. [The article] addresses every conceivable argument
-against the enforceability of public software licenses [and concludes
-that] [b]ased on current relevant doctrine and prevailing public
-policy interests, public software licenses that adhere to distinct
-procedural requirements are enforceable.”).
-</p>
-
-<h3>ADMINISTRATIVE MATERIALS</h3>
-
-<p>
-AN OVERVIEW OF “OPEN SOURCE” SOFTWARE LICENSES: A REPORT
-OF THE SOFTWARE LICENSING COMMITTEE OF THE AMERICAN BAR ASSOCIATION'S
-“INTELLECTUAL PROPERTY” SECTION, available at
-http://www.abanet.org/intelprop/opensource.html (last modified
-November 6, 2001) (“This paper's purpose is to flag some of the
-legal issues in an effort to provide a resource for software licensing
-lawyers who are requested to counsel their clients on the positive and
-negative aspects of [open source] licenses. Despite the many
-advantages of open source software licenses, there are reasons why
-lawyers must be cautious about recommending open source to their
-clients for inclusion in commercial software products.”).
-</p>
-
-</div>
-<!--#include virtual="/server/footer.html" -->
-<div id="footer">
-
-<p>
-Please send FSF & GNU inquiries to
-<a href="mailto:address@hidden"><em>address@hidden</em></a>.
-There are also <a href="/contact/">other ways to contact</a>
-the FSF.
-<br />
-Please send broken links and other corrections or suggestions to
-<a href="mailto:address@hidden"><em>address@hidden</em></a>.
-</p>
-
-<p>
-Please see the
-<a href="/server/standards/README.translations.html">Translations
-README</a> for information on coordinating and submitting
-translations of this article.
-</p>
-
-
-<p>
-Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2009 Free
-Software Foundation, Inc.</p>
-<p>
-Verbatim copying and distribution of this entire article is permitted
-in any medium, provided this notice is preserved.
-</p>
-
-<p>
-Updated:
-<!-- timestamp start -->
-$Date: 2009/01/15 15:54:16 $
-<!-- timestamp end -->
-</p>
-</div>
-
-<div id="translations">
-<h4>Translations of this page</h4>
-
-<!-- Please keep this list alphabetical by language code. -->
-<!-- Comment what the language is for each type, i.e. de is German. -->
-<!-- Write the language name in its own language (Deutsch) in the text. -->
-<!-- If you add a new language here, please -->
-<!-- advise address@hidden and add it to -->
-<!-- - /home/www/html/server/standards/README.translations.html -->
-<!-- - one of the lists under the section "Translations Underway" -->
-<!-- - if there is a translation team, you also have to add an alias -->
-<!-- to mail.gnu.org:/com/mailer/aliases -->
-<!-- Please also check you have the language code right; see: -->
-<!-- http://www.loc.gov/standards/iso639-2/php/code_list.php -->
-<!-- If the 2-letter ISO 639-1 code is not available, -->
-<!-- use the 3-letter ISO 639-2. -->
-<!-- Please use W3C normative character entities. -->
-
-<ul class="translations-list">
-<!-- English -->
-<li><a href="/doc/bibliography.html">English</a> [en]</li>
-</ul>
-</div>
-</div>
-</body>
-</html>
Index: contact.html
===================================================================
RCS file: contact.html
diff -N contact.html
--- contact.html 27 Jul 2010 08:56:49 -0000 1.13
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,97 +0,0 @@
-<!--#include virtual="/server/header.html" -->
-<title>Contacting GNU Press - GNU Project - Free Software Foundation
(FSF)</title>
-<!--#include virtual="/server/banner.html" -->
-<h2>Contacting GNU Press</h2>
-
-<img src="/doc/small-gnupress.png" alt="" style="float: right;" />
-
-<dl>
-<dt><strong>Postal Mail:</strong></dt>
-
-<dd>
-GNU Press<br />
-c/o Free Software Foundation<br />
-51 Franklin St, Fifth Floor<br />
-Boston, MA 02110-1301<br />
-USA
-</dd>
-
-<dt><b>Phone:</b></dt>
-
-<dd>617-542-5942. Ask the receptionist for GNU Press.</dd>
-
-<dt><b>Fax:</b></dt>
-
-<dd>617-542-2652</dd>
-
-<dt><b>E-mail:</b></dt>
-
-<dd><a href="mailto:address@hidden"><address@hidden></a></dd>
-
-</dl>
-
-</div>
-<!--#include virtual="/server/footer.html" -->
-<div id="footer">
-
-<p>
-Please send FSF & GNU inquiries to
-<a href="mailto:address@hidden"><em>address@hidden</em></a>.
-There are also <a href="/contact/">other ways to contact</a>
-the FSF.
-<br />
-Please send broken links and other corrections or suggestions to
-<a href="mailto:address@hidden"><em>address@hidden</em></a>.
-</p>
-
-<p>
-Please see the
-<a href="/server/standards/README.translations.html">Translations
-README</a> for information on coordinating and submitting
-translations of this article.
-</p>
-
-<p>
-Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2009
-Free Software Foundation, Inc.</p>
-<p>
-Verbatim copying and distribution of this entire article is permitted
-in any medium, provided this notice is preserved.
-</p>
-
-<p>
-Updated:
-<!-- timestamp start -->
-$Date: 2010/07/27 08:56:49 $
-<!-- timestamp end -->
-</p>
-</div>
-
-<div id="translations">
-<h4>Translations of this page</h4>
-
-<!-- Please keep this list alphabetical by language code. -->
-<!-- Comment what the language is for each type, i.e. de is German. -->
-<!-- Write the language name in its own language (Deutsch) in the text. -->
-<!-- If you add a new language here, please -->
-<!-- advise address@hidden and add it to -->
-<!-- - /home/www/html/server/standards/README.translations.html -->
-<!-- - one of the lists under the section "Translations Underway" -->
-<!-- - if there is a translation team, you also have to add an alias -->
-<!-- to mail.gnu.org:/com/mailer/aliases -->
-<!-- Please also check you have the language code right; see: -->
-<!-- http://www.loc.gov/standards/iso639-2/php/code_list.php -->
-<!-- If the 2-letter ISO 639-1 code is not available, -->
-<!-- use the 3-letter ISO 639-2. -->
-<!-- Please use W3C normative character entities. -->
-
-<ul class="translations-list">
-<!-- English -->
-<li><a href="/doc/contact.html">English</a> [en]</li>
-<!-- Polish -->
-<li><a href="/doc/contact.pl.html">polski</a> [pl]</li>
-</ul>
-</div>
-</div>
-</body>
-</html>
Index: expanding.html
===================================================================
RCS file: expanding.html
diff -N expanding.html
--- expanding.html 16 Jan 2009 17:23:42 -0000 1.13
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,161 +0,0 @@
-<!--#include virtual="/server/header.html" -->
-<title>Expanding Bookstore Availability - GNU Project - Free Software
Foundation (FSF)</title>
-<!--#include virtual="/server/banner.html" -->
-<h2>Instructions to Friends of GNU on how to get GNU Press books into
-their local bookstores</h2>
-
-<p>
-First visit the <a href="http://shop.fsf.org/category/books/">FSF
-Online Shop</a> to familiarize yourself with the current title list,
-and see if any new ones have been announced.
-</p>
-
-<p>
-Contact several bookstores in your region with good-sized technical
-sections. Don't select more than one branch each of chain stores.
-Find out whether they stock GNU Press books, and whether or not all
-their distributors stock GNU Press books.
-</p>
-
-<p>
-One useful technique is to look through the store for books about
-Richard Stallman or his work—in particular, <cite>Free As In
-Freedom</cite>. Then you can say to the buyer, “You
-carry <tt>N</tt> different books about Stallman's work, including his
-biography, but you don't carry his own book.” This technique is
-sometimes effective, since it provides a reason for them to be
-interested.
-</p>
-
-<p>
-If the bookstore does not stock GNU Press books but one or more of
-their distributors does:
-</p>
-
-<p>
-Call or visit the store and ask to speak to the person in charge of
-technical book section. (The average person working on the store
-floor cannot help you in this matter.) Ask why they don't hold GNU
-books in stock. Point out to the bookstore that the GNU project
-provides many of the main programs used by programmers and system
-administrators, and that they are missing stocking the definitive
-books for these programs. This may be sufficient to encourage the
-bookstore to inquire to their distributor.
-</p>
-
-<p>
-If some or all of the bookstore's distributors do not supply GNU Press
-books: Ask the bookstore employee the name and telephone number of the
-distributors they purchase from—doing the same for 3 or 4
-computer bookshops will give a good picture of the main distributors
-in your region to focus on.
-</p>
-
-<p>
-Telephone the distributors to verify whether they do or don't stock
-GNU Press books. If not, find out the name of the person responsible
-for specifying which books the distributor stocks.
-</p>
-
-<p>
-Tell the purchasing manager you are ringing on behalf of GNU Press.
-Explain what the GNU project is, making sure the purchasing manager is
-clear the GNU project publishes definitive books for a range of
-programs published as part of the GNU project, and that the programs
-are common to many. Point the purchasing manager to the
-www.gnupress.org web site. Sometimes a purchasing manager will be
-sufficiently technically oriented to discuss the ubiquity of programs
-such as GNU Make and GCC. Once the purchasing manager has understood
-these issues, he is likely to want to see samples of GNU Press books,
-perhaps two or three titles to get a feel for the breadth and depth of
-coverage and the quality of writing style. At this stage, you should
-contact GNU Press to co-ordinate. Send email
-to <a href="mailto:address@hidden"><address@hidden></a>.
-</p>
-
-<p>
-When making your sales pitch, good books to mention are <cite>GNU
-Make</cite>, <cite>MDK</cite> and <cite>Free Software Free
-Society</cite>. This gives a cross section of technical manual,
-“fun” book and philosophical book.
-</p>
-
-<p>
-Find out when it is convenient to contact the purchasing manager after
-he has received the sample books. Call the purchasing manager around
-the designated time. If he isn't available, repeat contact attempts
-in around 10 day intervals.
-</p>
-
-<p>
-When the purchasing manager has agreed to carry GNU Press books, a
-contract will need to be drawn up. This should be done between GNU
-Press <a href="mailto:address@hidden"><address@hidden></a> and the
-distributor directly.
-</p>
-
-</div>
-<!--#include virtual="/server/footer.html" -->
-<div id="footer">
-
-<p>
-Please send FSF & GNU inquiries to
-<a href="mailto:address@hidden"><em>address@hidden</em></a>.
-There are also <a href="/contact/">other ways to contact</a>
-the FSF.
-<br />
-Please send broken links and other corrections or suggestions to
-<a href="mailto:address@hidden"><em>address@hidden</em></a>.
-</p>
-
-<p>
-Please see the
-<a href="/server/standards/README.translations.html">Translations
-README</a> for information on coordinating and submitting
-translations of this article.
-</p>
-
-
-<p>
-Copyright © 2002, 2003, 2004, 2005, 2006, 2009 Free Software
-Foundation, Inc.
-</p>
-<p>
-Verbatim copying and distribution of this entire article is permitted
-in any medium, provided this notice is preserved.
-</p>
-
-<p>
-Updated:
-<!-- timestamp start -->
-$Date: 2009/01/16 17:23:42 $
-<!-- timestamp end -->
-</p>
-</div>
-
-<div id="translations">
-<h4>Translations of this page</h4>
-
-<!-- Please keep this list alphabetical by language code. -->
-<!-- Comment what the language is for each type, i.e. de is German. -->
-<!-- Write the language name in its own language (Deutsch) in the text. -->
-<!-- If you add a new language here, please -->
-<!-- advise address@hidden and add it to -->
-<!-- - /home/www/html/server/standards/README.translations.html -->
-<!-- - one of the lists under the section "Translations Underway" -->
-<!-- - if there is a translation team, you also have to add an alias -->
-<!-- to mail.gnu.org:/com/mailer/aliases -->
-<!-- Please also check you have the language code right; see: -->
-<!-- http://www.loc.gov/standards/iso639-2/php/code_list.php -->
-<!-- If the 2-letter ISO 639-1 code is not available, -->
-<!-- use the 3-letter ISO 639-2. -->
-<!-- Please use W3C normative character entities. -->
-
-<ul class="translations-list">
-<!-- English -->
-<li><a href="/doc/expanding.html">English</a> [en]</li>
-</ul>
-</div>
-</div>
-</body>
-</html>
Index: gnupresslogo.jpg
===================================================================
RCS file: gnupresslogo.jpg
diff -N gnupresslogo.jpg
Binary files /tmp/cvsedNykm and /dev/null differ
Index: gnupresspub.html
===================================================================
RCS file: gnupresspub.html
diff -N gnupresspub.html
--- gnupresspub.html 11 Jan 2009 14:47:23 -0000 1.75
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,133 +0,0 @@
-<!--#include virtual="/server/header.html" -->
-<title>Documentation of the GNU Project: GNU Press - Published
Documentation</title>
-<!--#include virtual="/server/banner.html" -->
-<h2>GNU Press — Published Documentation</h2>
-
-<img src="/doc/gnupresslogo.jpg" alt="" style="float: right;" />
-
-<p>
-GNU Press publishes affordable books on computer science using freely
-distributable licenses. We are the publishing department of the Free
-Software Foundation, a non-profit organization. All our proceeds
-directly support the <a href="http://www.fsf.org/">Free Software
-Foundation</a> and <a href="/">Project GNU</a>.
-</p>
-
-<p>
-GNU Documentation is unique because of our attitude towards it. We
-believe the reader should be free to copy and redistribute it, just
-like our software. Originally, all our documentation was released
-under a short <a href="/licenses/licenses.html#WhatIsCopyleft">
-Copyleft</a> license, or under
-the <a href="/licenses/licenses.html#GPL">GNU General Public License
-(GPL)</a> itself; in 2001 the <a href="/licenses/licenses.html#FDL">
-Free Documentation License (FDL)</a> was created to address certain
-needs that were not met by licenses originally designed for software.
-For more detailed information on our theory of free documentation,
-please see Richard Stallman's essay,
-“<a href="/philosophy/free-doc.html">Free Software and Free
-Manuals</a>”.
-</p>
-
-<p>
-Our original mission was just printing manuals of GNU software
-programs. We are now expanding into the fields of general computer
-science and computer science philosophy as well. Our new
-“Philosophy of Software Freedom” series will examine the
-free software philosophy from a number of different angles, such as
-law, ethics, and business. We hope to bring the discussion into the
-mainstream, and show how the free software philosophy can be applied
-to seemingly unrelated fields, such as classical musical composition
-and art.
-</p>
-
-<p>
-We welcome inquiries from <a href="/doc/potentialauthors.html">
-potential authors</a>, and are especially interested in working
-with <a href="/doc/teachingprofessionals.html">computer science
-teachers</a> to create more materials for classroom use.
-</p>
-
-<p>
-Please help us write more documentation for Project GNU! New software
-packages are being written daily by this world-wide movement. For
-information on how to help, click here.
-</p>
-
-<p>
-Please help us get our books into more
-bookstores. <b><a href="/doc/expanding.html">Expanding Bookstore
-Availability</a></b> is an article written by a volunteer on how you
-can help to increase the distribution of GNU Press books where you
-live.
-</p>
-
-<h3><a href="http://shop.fsf.org/category/books/">List of books in
-print</a></h3>
-
-</div>
-<!--#include virtual="/server/footer.html" -->
-<div id="footer">
-
-<p>
-Please send FSF & GNU inquiries to
-<a href="mailto:address@hidden"><em>address@hidden</em></a>.
-There are also <a href="/contact/">other ways to contact</a>
-the FSF.
-<br />
-Please send broken links and other corrections or suggestions to
-<a href="mailto:address@hidden"><em>address@hidden</em></a>.
-</p>
-
-<p>
-Please see the
-<a href="/server/standards/README.translations.html">Translations
-README</a> for information on coordinating and submitting
-translations of this article.
-</p>
-
-<p>
-Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2009 Free
-Software Foundation, Inc.
-</p>
-<p>
-Verbatim copying and distribution of this entire article is permitted
-in any medium, provided this notice is preserved.
-</p>
-
-<p>
-Updated:
-<!-- timestamp start -->
-$Date: 2009/01/11 14:47:23 $
-<!-- timestamp end -->
-</p>
-</div>
-
-<div id="translations">
-<h4>Translations of this page</h4>
-
-<!-- Please keep this list alphabetical by language code. -->
-<!-- Comment what the language is for each type, i.e. de is German. -->
-<!-- Write the language name in its own language (Deutsch) in the text. -->
-<!-- If you add a new language here, please -->
-<!-- advise address@hidden and add it to -->
-<!-- - /home/www/html/server/standards/README.translations.html -->
-<!-- - one of the lists under the section "Translations Underway" -->
-<!-- - if there is a translation team, you also have to add an alias -->
-<!-- to mail.gnu.org:/com/mailer/aliases -->
-<!-- Please also check you have the language code right; see: -->
-<!-- http://www.loc.gov/standards/iso639-2/php/code_list.php -->
-<!-- If the 2-letter ISO 639-1 code is not available, -->
-<!-- use the 3-letter ISO 639-2. -->
-<!-- Please use W3C normative character entities. -->
-
-<ul class="translations-list">
-<!-- English -->
-<li><a href="/doc/gnupresspub.html">English</a> [en]</li>
-<!-- Spanish -->
-<li><a href="/doc/gnupresspub.es.html">español</a> [es]</li>
-</ul>
-</div>
-</div>
-</body>
-</html>
Index: potentialauthors.html
===================================================================
RCS file: potentialauthors.html
diff -N potentialauthors.html
--- potentialauthors.html 29 May 2010 16:10:04 -0000 1.19
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,126 +0,0 @@
-<!--#include virtual="/server/header.html" -->
-<title>Documentation of the GNU project - Information for Potential
Authors</title>
-<!--#include virtual="/server/banner.html" -->
-<h2>Information for Potential Authors</h2>
-
-<p>
-The FSF always has a need for technical documentation writers. We
-have many programs that have yet to be properly documented or lack
-tutorials.</p>
-
-<p>
-Check the
-<a href="https://savannah.gnu.org/projects/tasklist">tasklist</a> and
-<a href="http://savannah.gnu.org/people/">help wanted</a> lists at
-<a href="http://savannah.gnu.org">Savannah</a> to which projects are
-currently seeking help with documentation.
-</p>
-
-<p>
-GNU Press is also actively looking for books on general computer science,
-as well as potential manuscripts to develop into titles for our
-<i>Philosophy of Software Freedom Series</i>. PhD candidates and
-post-docs are encouraged to send in their thesis, or a proposal based
-on their thesis, for consideration for this series. If you are
-interested in being published by GNU Press, please send email
-to <a href="mailto:address@hidden"><address@hidden></a>.
-</p>
-
-<h3>Documentation Standards</h3>
-<p>
-The Free Software Foundation actively promotes the use and development
-of free software for documentation. Our preferred standard for
-documentation formatting is the simple but powerful
-language <a href="/software/texinfo/">Texinfo</a>;
-<a href="http://www.docbook.org">DocBook</a> may also be used.
-Graphic illustrations may be created
-with <a href="http://www.gimp.org">GIMP</a>.
-</p>
-
-<ul>
-<li><a href="/prep/standards/">GNU Coding/Documentation
-Standards</a></li>
-
-<li>A section from the GNU
-Project <a href="/prep/maintain/">Information for Maintainers</a>
-Manual</li>
-
-<li>A Draft GNU Press Style Guide
-(<a href="/doc/GNU-Press-styleguide.texi">Texinfo
-source</a>, <a href="/doc/GNU-Press-styleguide.pdf">PDF</a>)</li>
-
-<li><a href="/software/texinfo/manual/texinfo/">Texinfo
-Manual</a></li>
-
-<li><a href="http://www.docbook.org">DocBook</a></li>
-
-<li><a href="http://www.gimp.org">The GIMP</a></li>
-
-<li><a href="/licenses/fdl.html">The GNU Free Documentation
-License</a></li>
-</ul>
-
-</div>
-<!--#include virtual="/server/footer.html" -->
-<div id="footer">
-
-<p>
-Please send FSF & GNU inquiries to
-<a href="mailto:address@hidden"><em>address@hidden</em></a>.
-There are also <a href="/contact/">other ways to contact</a>
-the FSF.
-<br />
-Please send broken links and other corrections or suggestions to
-<a href="mailto:address@hidden"><em>address@hidden</em></a>.
-</p>
-
-<p>
-Please see the
-<a href="/server/standards/README.translations.html">Translations
-README</a> for information on coordinating and submitting
-translations of this article.
-</p>
-
-<p>
-Copyright © 2010 Free
-Software Foundation, Inc.</p>
-<p>
-Verbatim copying and distribution of this entire article is permitted
-in any medium, provided this notice is preserved.</p>
-
-<p>
-Updated:
-<!-- timestamp start -->
-$Date: 2010/05/29 16:10:04 $
-<!-- timestamp end -->
-</p>
-</div>
-
-<div id="translations">
-<h4>Translations of this page</h4>
-
-<!-- Please keep this list alphabetical by language code. -->
-<!-- Comment what the language is for each type, i.e. de is German. -->
-<!-- Write the language name in its own language (Deutsch) in the text. -->
-<!-- If you add a new language here, please -->
-<!-- advise address@hidden and add it to -->
-<!-- - /home/www/html/server/standards/README.translations.html -->
-<!-- - one of the lists under the section "Translations Underway" -->
-<!-- - if there is a translation team, you also have to add an alias -->
-<!-- to mail.gnu.org:/com/mailer/aliases -->
-<!-- Please also check you have the language code right; see: -->
-<!-- http://www.loc.gov/standards/iso639-2/php/code_list.php -->
-<!-- If the 2-letter ISO 639-1 code is not available, -->
-<!-- use the 3-letter ISO 639-2. -->
-<!-- Please use W3C normative character entities. -->
-
-<ul class="translations-list">
-<!-- English -->
-<li><a href="/doc/potentialauthors.html">English</a> [en]</li>
-<!-- Spanish -->
-<li><a href="/doc/potentialauthors.es.html">español</a> [es]</li>
-</ul>
-</div>
-</div>
-</body>
-</html>
Index: small-gnupress.png
===================================================================
RCS file: small-gnupress.png
diff -N small-gnupress.png
Binary files /tmp/cvsOkWXbn and /dev/null differ
Index: teachingprofessionals.html
===================================================================
RCS file: teachingprofessionals.html
diff -N teachingprofessionals.html
--- teachingprofessionals.html 23 Mar 2009 14:29:08 -0000 1.11
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,86 +0,0 @@
-<!--#include virtual="/server/header.html" -->
-<title>Documentation of the GNU project - Information for Teaching
Professionals</title>
-<!--#include virtual="/server/banner.html" -->
-<h2>Information for Teaching Professionals</h2>
-
-<p>
-The GNU Press is committed to producing well-written, authoritative
-books on computer science and related legal issues at prices that are
-affordable to students. We are currently in the process of creating
-supportive teaching materials for classroom use for existing and new
-manuals. If you would like to help with this process, please contact
-<a href="mailto:address@hidden"><address@hidden></a>.</p>
-
-<h3>Examination and Desk Copy Policy</h3>
-
-<p>Examination copies for course adoption are available at 50% off
-list price. Desk copies of GNU Press titles adopted for classroom use
-as required texts are available gratis. All requests should be made
-on department letterhead and include a bookstore purchase order.</p>
-
-<h4><a href="/doc/bibliography.html">Bibliography of Legal writings on
-the GPL</a></h4>
-
-</div>
-<!--#include virtual="/server/footer.html" -->
-<div id="footer">
-
-<p>
-Please send FSF & GNU inquiries to
-<a href="mailto:address@hidden"><em>address@hidden</em></a>.
-There are also <a href="/contact/">other ways to contact</a>
-the FSF.
-<br />
-Please send broken links and other corrections or suggestions to
-<a href="mailto:address@hidden"><em>address@hidden</em></a>.
-</p>
-
-<p>
-Please see the
-<a href="/server/standards/README.translations.html">Translations
-README</a> for information on coordinating and submitting
-translations of this article.
-</p>
-
-<p>
-Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2009 Free
-Software Foundation, Inc.</p>
-<p>
-Verbatim copying and distribution of this entire article is permitted
-in any medium, provided this notice is preserved.
-</p>
-
-<p>
-Updated:
-<!-- timestamp start -->
-$Date: 2009/03/23 14:29:08 $
-<!-- timestamp end -->
-</p>
-</div>
-
-<div id="translations">
-<h4>Translations of this page</h4>
-
-<!-- Please keep this list alphabetical by language code. -->
-<!-- Comment what the language is for each type, i.e. de is German. -->
-<!-- Write the language name in its own language (Deutsch) in the text. -->
-<!-- If you add a new language here, please -->
-<!-- advise address@hidden and add it to -->
-<!-- - /home/www/html/server/standards/README.translations.html -->
-<!-- - one of the lists under the section "Translations Underway" -->
-<!-- - if there is a translation team, you also have to add an alias -->
-<!-- to mail.gnu.org:/com/mailer/aliases -->
-<!-- Please also check you have the language code right; see: -->
-<!-- http://www.loc.gov/standards/iso639-2/php/code_list.php -->
-<!-- If the 2-letter ISO 639-1 code is not available, -->
-<!-- use the 3-letter ISO 639-2. -->
-<!-- Please use W3C normative character entities. -->
-
-<ul class="translations-list">
-<!-- English -->
-<li><a href="/doc/teachingprofessionals.html">English</a> [en]</li>
-</ul>
-</div>
-</div>
-</body>
-</html>
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- www/doc GNU-Press-styleguide.pdf GNU-Press-styl...,
Matt Lee <=