+
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
<article>
<author>
<firstname>Benjamin</firstname>
- <othername>"Mako"</othername>
+ <othername>Mako</othername>
<surname>Hill</surname>
<affiliation>
<address>
- <email>mako@debian.org</email>
+ <email>mako@atdot.cc</email>
</address>
</affiliation>
</author>
<revhistory>
+ <revision>
+ <revnumber>v0.3.3</revnumber>
+ <date>22 August 2008</date>
+ <authorinitials>bmh</authorinitials>
+ </revision>
+ <revision>
+
+ <revnumber>v0.3.2</revnumber>
+ <date>15 April 2002</date>
+ <authorinitials>bmh</authorinitials>
+ </revision>
+
<revision>
<revnumber>v0.3.1</revnumber>
<date>18 June 2001</date>
- <authorinitials>bch</authorinitials>
+ <authorinitials>bmh</authorinitials>
</revision>
<revision>
<revnumber>v0.3</revnumber>
<date>5 May 2001</date>
- <authorinitials>bch</authorinitials>
+ <authorinitials>bmh</authorinitials>
</revision>
<revision>
<revnumber>v0.2.1</revnumber>
<date>10 April 2001</date>
- <authorinitials>bch</authorinitials>
+ <authorinitials>bmh</authorinitials>
</revision>
<revision>
<revnumber>v0.2</revnumber>
<date>8 April 2001</date>
- <authorinitials>bch</authorinitials>
+ <authorinitials>bmh</authorinitials>
</revision>
<revision>
<revnumber>v0.01</revnumber>
<date>27 March 2001</date>
- <authorinitials>bch</authorinitials>
+ <authorinitials>bmh</authorinitials>
<revremark>Initial Release</revremark>
</revision>
</revhistory>
<title>Copyright Information</title>
<para>
- This document is copyrighted (c) 2000 Benjamin (Mako) Hill and is
+ This document is copyrighted (c) 2000-2008 Benjamin Mako Hill and is
distributed under the terms of the <citetitle>GNU Free
Documentation License</citetitle>.
</para>
Permission is granted to copy, distribute and/or modify this
document under the terms of the <link
linkend="fdl"><citetitle>GNU Free Documentation
- License</citetitle></link>, Version 1.1 or any later version
+ License</citetitle></link>, Version 1.2 or any later version
published by the Free Software Foundation with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy
of the license can be found in <xref linkend="fdl">.
<para>
This version is the part of the third pre-release cycle of this
HOWTO. It is written to be released to developers for critique and
- brainstorming. Please keep in mind that this version of the HOWTO
- is still in an infant stage and will continue to be revised
- extensively.
+ brainstorming. While the HOWTO is now several years old, please keep
+ in mind that this version of the HOWTO is still in an "early" stage
+ and will continue to be revised extensively.
</para>
<para>
The latest version number of this document should always be listed
- on <ulink url="http://yukidoke.org/~mako/projects/howto">the projects
- homepage </ulink> hosted by <ulink url="http://yukidoke.org">yukidoke.org.</ulink>
+ on <ulink url="http://mako.cc/projects/howto">the projects
+ homepage</ulink>.
</para>
<para>
<listitem>
<para>
- <ulink url="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO/t1.html">HTML</ulink>.
+ <ulink url="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO/t1.html">HTML</ulink>.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO.html">HTML (single page)</ulink>.
+ <ulink url="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO.html">HTML (single page)</ulink>.
</para>
</listitem>
<listitem>
<para>
- <ulink URL="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO.txt">plain text</ulink>.
+ <ulink URL="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO.txt">plain text</ulink>.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO.ps.gz">Compressed postscript</ulink>.
+ <ulink url="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO.ps.gz">Compressed postscript</ulink>.
</para>
</listitem>
<listitem>
<para>
- <ulink url="http://yukidoke.org/~mako/projects/howto/FreeSoftwareProjectManagement-HOWTO.sgml.gz">Compressed SGML source</ulink>.
+ <ulink url="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO.sgml.gz">Compressed SGML source</ulink>.
</para>
</listitem>
</itemizedlist>
In this version I have the pleasure of acknowledging:
</para>
- <para>
- Anyone who gave me an idea for a better name and everyone who
- assured me that a <citetitle>Project Management HOWTO</citetitle>
- didn't necessary sound corporate.
- </para>
+ <para>Fellow Debian developers Martin Michlmayr and Vivek
+ Venugopalan who sent me information and links to extremely
+ interesting articles. I've added both to the bibliography and I've
+ added information from each into the HOWTO. Thanks to Andrew Shugg
+ who pointed out several errors in the document. Also, a big thanks
+ to Sung Wook Her (AKA RedBaron) who is doing the first translation
+ of the HOWTO into Korean. I've been happy to see that people have
+ enjoyed and benefited from the HOWTO so far.</para>
<para>
- Josh Crawford, Andy King, and Jaime Davila who all read through
- this in entirety and gave me feedback that has helped me make
- changes and improvements to this document. I can't thank you guys
- enough for your help. An extra <quote>Thank You</quote> goes to
- Andy King who who read through this several times and submitted
- patches to make life easier for me.
+ Older thanks that I don't want to take out yet include: Josh
+ Crawford, Andy King, and Jaime Davila who all read through this in
+ entirety and gave me feedback that has helped me make changes and
+ improvements to this document. I can't thank you guys enough for
+ your help. An extra <quote>Thank You</quote> goes to Andy King who
+ who read through this several times and submitted patches to make
+ life easier for me.
</para>
<para>
Also providing support material, and inspiration for this HOWTO is
Eric S. Raymond for his prolific, consistent, and carefully
crafted arguments and Lawrence Lessig for reminding me of the
- importance of Free Software. Additionaly, I want to thank every
+ importance of Free Software. Additionally, I want to thank every
user and developer involved with the <ulink
url="http://www.debian.org">Debian Project</ulink>. The project
has provided me with a home, a place to practice free software
Above all, I want to thank <emphasis>Richard Stallman</emphasis>
for his work at the Free Software Foundation and for never giving
up. Stallman provides and articulates the philosophical basis that
- attracts me to free software and that drives me towards writing a
+ attracts me to free software and that drives me toward writing a
document to make sure it succeeds. RMS can always be emailed at
<email>rms (at) gnu (dot) org</email>.
</para>
and I believe that its ultimate success will be rooted in its
ability to do this. Please send your additions, comments, and
criticisms to the following email address:
- <email>mako@debian.org</email>.
+ <email>mako@atdot.cc</email>.
</para>
</sect2>
</para>
<para>
- However, this HOWTO is still young and I have to yet to be
- contacted about a translation so English is all that is currently
- available. If you would like to help with or do a translation, you
- will gain my utmost respect and admiration and you'll get to be
- part of a cool process. If you are at all interested, please don't
- hesitate to contact me at: <email>mako@debian.org</email>.
+ This HOWTO has graciously translated into German by Robert F.
+ Schmitt. That copy is accessible in the following formats:
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ <ulink url="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO.DE.html">HTML (single page)</ulink>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <ulink url="http://mako.cc/projects/howto/FreeSoftwareProjectManagement-HOWTO.DE.rstl">Restructured Text Source</ulink>.
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ If you would like to help with or do a translation, you will gain my
+ utmost respect and admiration and you'll get to be part of a cool
+ process. If you are at all interested, please don't hesitate to
+ contact me at: <email>mako@atdot.cc</email>.
</para>
</sect2>
</sect1>
<para>
With very little argument, the beginning is the most difficult
period in a project's life to do successful free software project
- managment. Laying a firm foundation will determine whether your
+ management. Laying a firm foundation will determine whether your
project flourishes or withers away and dies. It is also the subject
that is of most immediate interest to anyone reading this document
as a tutorial.
It is in these dangerous initial moments that anyone working to
start a free software project must try and strike a balance along
these lines. One of the most important ways that someone trying to
- start a project can work towards this balance is by establishing a
+ start a project can work toward this balance is by establishing a
solid framework for the development process through some of the
suggestions mentioned in this section.
</para>
<para>
If you are reading this document, there's a good chance you
already have an idea for a project in mind. Chances are also
- pretty good that it fills a percieved gap by doing something that
+ pretty good that it fills a perceived gap by doing something that
no other free software project does or by doing something in a way
that is unique enough to necessitate a brand new piece of
software.
<para>
Eric S. Raymond writes about how free software projects start in
his essay, <ulink
- url="http://www.tuxedo.org/~esr/writings/cathedral-bazaar/"><quote>The
+ url="http://catb.org/~esr/writings/cathedral-bazaar/"><quote>The
Cathedral and the Bazaar,</quote></ulink> which comes as required
reading for any free software developer. It is available online .
</para>
<para>
For many developers this may be the single most difficult aspect
- of free software project managment, but it is an essential one. It is
+ of free software project management, but it is an essential one. It is
easy to become fired up by an idea and get caught up in the
momentum and excitement of a new project. It is often extremely
difficult to do, but it is important that any free software
project is worth giving a bit of thought. Leslie Orchard tackles
this issue in an <ulink
url="http://www.advogato.org/article/67.html">Advogato
- article</ulink>. His article is short and definately worth looking
+ article</ulink>. His article is short and definitely worth looking
over quickly.
</para>
He makes a good point though. There are companies whose only job
is to make names for pieces of software. They make
<emphasis>ridiculous</emphasis> amount of money doing it and are
- supposedly worth it. While you probably can't aford a company like
- this, you can afford to learn from their existance and think a
+ supposedly worth it. While you probably can't afford a company like
+ this, you can afford to learn from their existence and think a
little bit about the name you are giving your project because it
<emphasis>does</emphasis> matter.
</para>
url="http://www.opensource.org/docs/definition_plain.html">Open
Source Definition.</ulink> Examples of free licenses given by the
<acronym>DFSG</acronym> are the <acronym>GPL</acronym>, the
- <acronym>BSD</acronym>, and the Artistic License.
+ <acronym>BSD</acronym>, and the Artistic License. As ESR mentions
+ in his his HOWTO<xref linkend="esrhowto">, don't write your own
+ license if at all possible. The three licenses I mention all have
+ long interpretive traditions. They are also definitely free
+ software (and can therefore be distributed as part of Debian and
+ in other places that permit the transfer of free software).
</para>
<para>
uphold, <quote>users' freedom to run, copy, distribute, study,
change and improve the software.</quote> There are plenty of
other licenses that also conform to the <acronym>DFSG</acronym>
- but sticking with a more well-known license will offer the advantage
- of immediate recognition and understanding.
+ but sticking with a more well-known license will offer the
+ advantage of immediate recognition and understanding. Many
+ people write three or four sentences in a COPYING file and assume
+ that they have written a free software license--as my long
+ experience with the debian-legal mailing professes, this is very
+ often not the case.
</para>
<para>
some, it is a major drawback.
</para>
+ <para>
+ Many people write three or four sentences in a COPYING file and
+ assume that they have written a free software license--as my long
+ experience with the debian-legal mailing professes, this is very
+ often not the case. It may not protect you, it may not protect
+ your software, and it may make things very difficult for people
+ that want to use your software but who pay a lot of attention to
+ the subtle legal points of licenses. If you are passionate about
+ a home-brewed license, run it by either people at <ulink
+ url="http://www.opensource.org">OSI</ulink> or the <ulink
+ url="mailto:debian-devel@lists.debian.org">debian-legal mailing
+ list</ulink> first protect yourself from unanticipated
+ side-effects of your license.
+ </para>
+
<para>
The three major licenses can be found at the following locations:
</para>
<para>
<itemizedlist>
+ <listitem>
+ <para>Make yourself or the FSF the copyright holder for the
+ work. In a few rare cases, you might want to make a sponsoring
+ organization (if it's big and powerful enough) the copyright
+ holder instead. Doing this is as simple as putting the name in
+ the blank when you modify the notice of copyright
+ below. Contrary to popular belief, you don't need to file with
+ any organization. The notice alone is enough to copyright your
+ work.</para>
+ </listitem>
+
<listitem>
<para>If at all possible, attach and distribute a full copy of
the license with the source and binary by including a separate
time. The first number is the major number and it signifies major
changes or rewrites. The second number is the minor number and it
represents added or tweaked functionality on top of a largely
- coherant structure. The third number is the patch number and it
+ coherent structure. The third number is the patch number and it
usually will only refer to releases fixing bugs.
</para>
<para>
The widespread use of this scheme is why I know the nature and
relative degree in the differences between a 2.4.12 release of the
- Linux kernel and a 2.4.11, 2.2.12, and 1.2.12 without knowning
+ Linux kernel and a 2.4.11, 2.2.12, and 1.2.12 without knowing
anything about any of the releases.
</para>
<term>Wine version numbering:</term>
<listitem>
<para>Because of the unusual nature of wine's development where
- the not-emulator is constantly improving but not working towards
+ the not-emulator is constantly improving but not working toward
any immediately achievable goal, wine is released every three
weeks. Wine does this by labeling their releases in <quote>Year
Month Day</quote> format where each release might be labeled
<ulink url="http://www.mozilla.org/roadmap.html">road
maps</ulink>. Major points and achievements along these
road-maps were marked as milestones. Therefore, although
- mozilla was built and distributed nightly as <quote>nightly
+ Mozilla was built and distributed nightly as <quote>nightly
builds,</quote> on a day when the goals of a milestone on the
road-map had been reached, that particular build was marked as
a <quote>milestone release.</quote>
through the Linux Documentation project <acronym>(LDP)</acronym>
and is written by Jens Schweikhardt. It is available <ulink
url="http://www.schweikhardt.net/man_page_howto.html">from
- Schweikhardt's site</ulink> or <ulink
- url="http://www.linuxdoc.org/HOWTO/mini/Man-Page.html">from the
- <acronym>LDP</acronym></ulink>.
+ Schweikhardt's site</ulink>.
</para>
<para>
<para>A NEWS file and a ChangeLog are similar. Unlike a
CHANGELOG, a NEWS file is not typically updated with new
versions. Whenever new features are added, the developer
- responisble will make a note in the NEWS file. NEWS files
+ responsible will make a note in the NEWS file. NEWS files
should not have to be changed before a release (they should be
kept up to date all along) but it's usually a good idea to
check first anyway because often developers just forget to
<sect3>
<title>Other documentation hints</title>
- <para>
- All your documentation should be in plaintext, or, in cases where
- it is on your website primarily, in HTML. Everyone can cat a
- file, everyone has a pager, (almost) everyone can render
- HTML. <emphasis>You are welcome to distribute information in PDF,
- PostScript, RTF, or any number of other widely used formats but
- this information must also be available in plaintext or HTML or
- people will be very angry at you.</emphasis>
- </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ All your documentation should be in plaintext, or, in cases
+ where it is on your website primarily, in HTML. Everyone can
+ cat a file, everyone has a pager, (almost) everyone can render
+ HTML. <emphasis>You are welcome to distribute information in
+ PDF, PostScript, RTF, or any number of other widely used
+ formats but this information must also be available in
+ plaintext or HTML or people will be very angry at
+ you.</emphasis> In my opinion, info falls into this category
+ as well. There is plenty of great GNU documentation that
+ people simply don't read because it only in info. And this
+ <emphasis>does</emphasis> make people angry. It's not a
+ question of superior formats; it is a question of
+ accessability and the status quo plays a huge role in this
+ determination.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ It doesn't hurt to distribute any documentation for your
+ program from your website (FAQs etc) with your program. Don't
+ hesitate to throw any of this in the program's tarball. If
+ people don't need it, they will delete it. I can repeat it over
+ and over: <emphasis>Too much documentation is not a
+ sin.</emphasis>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>Unless your software is particular to a non-English
+ language (a Japanese language editor for example), please
+ distribute it with English language documentation. If you don't
+ speak English or not not confident in your skills, ask a friend
+ for help. Like it or not, fair or unfair, <emphasis>English is
+ the language of free software</emphasis>. However, this does not
+ mean you should limit your documentation to only English. If you
+ speak another language, distribute translations of documentation
+ with your software if you have the time and energy to do
+ so. They will invariably be useful to someone.</para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Finally, <emphasis>please spell-check your
+ documentation.</emphasis> Misspellings in documentation are
+ bugs. I'm very guilty of committing this error and it's
+ extremely easy to do. If English is not your first language,
+ have a native speaker look over or edit your documentation or
+ web pages. Poor spelling or grammar goes a long way to making
+ your code look unprofessional. In code comments, this type of
+ thing is less important but in man pages and web pages these
+ mistakes are not acceptable.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
- <para>
- It doesn't hurt to distribute any documentation for your program
- from your website (FAQs etc) with your program. Don't hesitate to
- throw any of this in the program's tarball. If people don't need
- it, they will delete it. I can repeat it over and over:
- <emphasis>Too much documentation is not a sin.</emphasis>
- </para>
</sect3>
</sect2>
may remind a developer of something they may have forgotten.
</para>
+ <sect3>
+ <title>Package File Names</title>
+ <para>
+ I agree with ESR when he says that: <quote> It's helpful to
+ everybody if your archive files all have GNU-like names --
+ all-lower-case alphanumeric stem prefix, followed by a dash,
+ followed by a version number, extension, and other
+ suffixes.</quote> There is more info (including lots of examples
+ of what <emphasis>not</emphasis> to do in his <citetitle>Software
+ Release Practices HOWTO</citetitle> which is included in this
+ HOWTO's bibliography and can be found through the LDP.
+ </para>
+ </sect3>
+
<sect3>
<title>Package formats</title>
<para>
about a version control system because it provides an automated
way of solving many of the problems described by this HOWTO. I
am not aware of any free version control systems for Windows or
- MacOS but I know that CVS clients exist for both
+ Mac OS but I know that CVS clients exist for both
platforms. Websites like <ulink
url="http://sourceforge.net">SourceForge</ulink> do a great job
as well with a nice, easy-to-use web interface to CVS.
<para>
I'd love to devote more space in this HOWTO to CVS because I love
it (I even use CVS to keep versions straight on this HOWTO!) but
- I think it falls outside the scope of this document and should have
- (already has) its own HOWTO.
+ I think it falls outside the scope of this document and already
+ has its own HOWTOs. Most notably is the <citetitle>CVS Best
+ Practices HOWTO</citetitle><xref linkend="cvsbestpractices">
+ which I've included in the attached bibliography.
</para>
</sect3>
<quote>yourprojectname-latest</quote> that is always pointing
to the most recent released or development version of your
free software application. Keep in mind that this location
- will recieve many requests for downloads around releases so
+ will receive many requests for downloads around releases so
make sure that the server you choose has adequate bandwidth.
</para>
</listitem>
<para>
In a bit of a disclaimer, delegation need not mean rule by
- comittee. In many cases it does and this has been proven to
+ committee. In many cases it does and this has been proven to
work. In other cases this has created problems. <ulink
url="http://news.linuxprogramming.com/news_story.php3?ltsn=2000-10-31-001-05-CD">Managing
Projects the Open Source Way</ulink> argues that <quote>OSS
yourself. In a sentence: <emphasis>Keep an eye out for other
qualified developers who show an interest and sustained
involvement with your project and try and shift responsibility
- towards them.</emphasis> The following ideas might be good places
+ toward them.</emphasis> The following ideas might be good places
to start or good sources of inspiration:
</para>
<sect4>
<title>Allow a larger group of people to have write access to your CVS
- repository and make real efforts towards rule by a
+ repository and make real efforts toward rule by a
committee</title>
<para>
to you by other developers.
</para>
+ <sect3>
+ <title>Encouraging Good Patching</title>
+
+ <para>As the person managing or maintaining the project, you
+ aren't the person who is going to be making a lot of
+ patches. However, it's worth knowing about ESR's section on
+ <citetitle>Good Patching Practice</citetitle> in the
+ <citetitle>Software Release Practices HOWTO</citetitle><xref
+ linkend="esrhowto">. I don't agree with ESR's claim that most ugly
+ or undocumented patches are probably worth throwing out at first
+ sight--this just hasn't been my experience, especially when
+ dealing with bug fixes that often don't come in the form of
+ patches at all. Of course, this doesn't mean that I
+ <emphasis>like</emphasis> getting poorly done patches. If you get
+ ugly -e patches, if you get totally undocumented patches, and
+ especially if they are anything more than trivial bug-fixes, it
+ might be worth judging the patch by some of the criteria in ESR's
+ HOWTO and then throwing people the link to the document so they
+ can do it the <quote>right way.</quote>
+ </para>
+
+ </sect3>
+
<sect3>
<title>Technical judgment</title>
<listitem>
<para>The necessity to avoid digressions that might expand the
scope of the program too much and result and push the project
- towards an early death under its own weight and
+ toward an early death under its own weight and
unwieldiness.</para>
</listitem>
difficult decisions to a development mailing list where they can
be discussed and debated. There will be some patches (bug fixes,
etc.) which will definitely be accepted and some that you feel
- are so offbase that they do not even merit further
- discussion. It is those that fall into the grey area between
+ are so off base that they do not even merit further
+ discussion. It is those that fall into the gray area between
these two groups that might merit a quick forward to a mailing
list.
</para>
<sect4>
<title>Technical issues are not always good justification</title>
<para>
- Especially towards the beginning of your project's life, you
+ Especially toward the beginning of your project's life, you
will find that many changes are difficult to implement,
introduce new bugs, or have other technical problems. Try to see
past these. Especially with added functionality, good ideas do
In addition to your users being your developers, they are also
(and perhaps more commonly) your testers. Before I get flamed, I
should rephrase my sentence: <emphasis>some of your
- users</emphasis> (those who explicityly volunteer) are your
+ users</emphasis> (those who explicitly volunteer) are your
testers.
</para>
</para>
<para>
- CVS comes with a bourne shell script called sanity.sh that is
+ CVS comes with a Bourne shell script called sanity.sh that is
worth looking at. Debian uses a program called lintian that
checks Debian packages for all of the most common errors. While
use of these scripts may not be helpful, there is a host of other
The second most difficult part of testing is
<emphasis>keeping</emphasis> your testers and keeping them
actively involved in the testing process. Fortunately, there are
- some tried and true tactics that can applied towards this end:
+ some tried and true tactics that can applied toward this end:
</para>
<para>
</para>
</sect3>
- <sect3>
+ <sect3 id="mailinglists">
<title>Mailing lists</title>
<para>
Aside from documentation, effective mailing lists will be your
<para>
There are other things you want to take into consideration in
setting up your list. If it is possible to gate your mailing
- lists to USENET and provide it in digest form as well as
+ lists to Usenet and provide it in digest form as well as
making them accessible on the web, you will please some users
and work to make the support infrastructure slightly more
accessible.
url="http://bugs.debian.org">Debian Bug Tracking System</ulink>
(<acronym>BTS</acronym>) although it may not be best choice for
every project (it seems to currently be buckling under its own
- weight) As well as a damn good web browser, the mozilla project
+ weight) As well as a damn good web browser, the Mozilla project
has spawned a sub-project resulting in a bug tracking system
called <ulink
url="http://www.mozilla.org/projects/bugzilla/">bugzilla</ulink>
</para>
<sect3>
- <title>Mailing lists and USENET</title>
+ <title>Mailing lists and Usenet</title>
+
+ <para>Announce your software on Usenet's <ulink
+ url="news:comp.os.linux.announce">comp.os.linux.announce</ulink>. If
+ you only announce your software in two places, have it be c.o.l.a
+ and freshmeat.</para>
+
<para>
- Email is still the way that most people on the Internet get their
- information. Its a good idea to send a message announcing your
- program to any relevant mailing list you know of and any relevant
- USENET discussion group. Karl Fogel recommends that use you
- simple subject describing the fact that the message is an
- announcement, the name of the program, the version, and a
- half-line long description of its functionality. This way, any
- interested user or developer will be immediately attracted to
- your announcement. Fogel's example looks like:
+ However, email is still the way that most people on the Internet
+ get their information. Its a good idea to send a message
+ announcing your program to any relevant mailing list you know of
+ and any other relevant Usenet discussion groups.</para>
+
+ <para>Karl Fogel recommends that use you simple subject
+ describing the fact that the message is an announcement, the name
+ of the program, the version, and a half-line long description of
+ its functionality. This way, any interested user or developer
+ will be immediately attracted to your announcement. Fogel's
+ example looks like:
</para>
- <screen>Subject: ANN: aub 1.0, a program to assemble USENET binaries</screen>
+ <screen>Subject: ANN: aub 1.0, a program to assemble Usenet binaries</screen>
<para>
The rest of the email should describe the programs functionality
quickly and concisely in no more than two paragraphs and should
provide links to the projects webpage and direct links to
- downloads for those that want to try it right away.
+ downloads for those that want to try it right away. This form
+ will work for both Usenet and mailing list posts.
</para>
<para>
interesting new releases).
</para>
</sect3>
+
+ <sect3>
+ <title>Project Mailing List</title>
+
+ <para>If you've gone ahead and created mailing lists for your
+ project, you should always announce new versions on these
+ lists. I've found that for many projects, users request a very
+ low-volume announce only mailing list to be notified when new
+ versions are released. freshmeat.net now allows users to subscribe
+ to a particular project so they receive emails every time a new
+ version is announced through their system. It's free and it can
+ stand in for an announce-only mailing list. In my opinion, it
+ can't hurt.</para>
+ </sect3>
</sect2>
</sect1>
<abstract>
<para>
Fogel's <quote>guide to using CVS in the free software
- world</quote> is much more than its subitle. In the publisher's
+ world</quote> is much more than its subtitle. In the publisher's
own words: <quote><emphasis>Open Source Development with
CVS</emphasis> is one of the first books available that teaches
you development and implementation of Open Source
important and useful. Please check it or buy it if you can and
are seriously interested in running a free software project.
</para>
+
+ <para>In May of 2003, the entire book under the GPL. You can
+ find the full text of the book <ulink
+ url="http://cvsbook.red-bean.com/">here</ulink>.</para>
</abstract>
</biblioset>
</biblioentry>
While it only briefly talks about free software (and does it by
tiptoeing around the free software/open source issue with the
spineless use of the term <quote>open code</quote> that only a
- laywer could coin), Lessig's book is brilliant. Written by a
+ lawyer could coin), Lessig's book is brilliant. Written by a
lawyer, it talks about how regulation on the Internet is not
done with law, but with the code itself and how the nature of
the code will determine the nature of future freedoms. In
</bibliodiv>
<bibliodiv>
- <title>Web-Accessable Resources</title>
+ <title>Web-Accessible Resources</title>
<para>
This is a list of the web resources pertaining to this HOWTO that
I've found most helpful in compiling this information. If you know
of others that would help, please don't hesitate to email me at
- <email>mako@debian.org</email> and we can look into getting it
+ <email>mako@atdot.cc</email> and we can look into getting it
added to the list and represented in the HOWTO.
</para>
<para>
I'd recommend that any free software developer (or potential one)
- skim through these sites becaue they have each have a lot to say.
+ skim through these sites because they have each have a lot to say.
</para>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Dafermos</surname>
+ <firstname>George</firstname>
+ <othername>N</othername>
+ </author>
+
+ <title><ulink url="http://firstmonday.org/issues/issue6_11/dafermos/">Management and Virtual Decentralized Networks: The Linux Project</ulink></title>
+
+ <abstract>
+ <para>Since the paper includes its own abstract, I thought I
+ would include it here verbatim:</para>
+
+ <para><blockquote><para>This paper examines the latest of
+ paradigms - the Virtual Network(ed) Organisation - and whether
+ geographically dispersed knowledge workers can virtually
+ collaborate for a project under no central
+ planning. Co-ordination, management and the role of knowledge
+ arise as the central areas of focus. The Linux Project and its
+ development model are selected as a case of analysis and the
+ critical success factors of this organisational design are
+ identified. The study proceeds to the formulation of a
+ framework that can be applied to all kinds of virtual
+ decentralised work and concludes that value creation is
+ maximized when there is intense interaction and uninhibited
+ sharing of information between the organisation and the
+ surrounding community. Therefore, the potential success or
+ failure of this organisational paradigm depends on the degree
+ of dedication and involvement by the surrounding
+ community.</para></blockquote></para>
+
+ <para>This paper was referred to me in my capacity as author of
+ this HOWTO and I was very impressed. It's written by a graduate
+ student in management and I think it succeeds at evaluating the
+ Linux project as an example of a new paradigm in management--one
+ that <emphasis>you</emphasis> will be be placing yourself at the
+ center of in your capacity as maintainer of a free software
+ project.</para>
+
+ <para>As a developer trying to control an application and guide
+ it to success in the free software world, I'm not sure how
+ useful Dafermos's argument is. It does however, provide a
+ theoretical justification for my HOWTO--free software project
+ management <emphasis>is</emphasis> a different creature than
+ proprietary software project management. If you are interested
+ in the conceptual and theoretical ways that free software
+ project management differs from other types of management, this
+ is a great paper to read. If this paper answers questions of
+ <quote>how?</quote>, Dafermos answers the (more difficult to
+ defend) questions of <quote>why?</quote> and does a very good
+ job.</para>
+
+
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
+ <biblioentry>
+ <biblioset>
+ <author>
+ <surname>Gabriel</surname>
+ <firstname>Richard</firstname>
+ </author>
+
+ <title><ulink
+ url="http://www.jwz.org/doc/worse-is-better.html">The Rise of
+ <quote>Worse is Better</quote></ulink></title>
+
+ <abstract>
+ <para>
+ A well written article although I think the title may have
+ confused as many people as the rest of the essay helped. It
+ offers a good description of how to design programs that will
+ succeed and stay maintainable as they grow.
+ </para>
+ </abstract>
+ </biblioset>
+ </biblioentry>
+
<biblioentry>
<biblioset>
<author>
<para>
In one of the better articles on the subject that I've read,
Monty sums up some of the major points I touch on including:
- starting a project, testing, documenation, organizing a team and
- leadership, and several other topics. While more opiniated that
+ starting a project, testing, documentation, organizing a team and
+ leadership, and several other topics. While more opinionated that
I try to be, I think its an important article that I found very
helpful in writing this HOWTO. I've tried to cite him in
the places where I borrowed from him most.
</biblioset>
</biblioentry>
- <biblioentry>
+ <biblioentry id="esrhowto">
<biblioset>
<author>
- <surname>Gabriel</surname>
- <firstname>Richard</firstname>
+ <surname>Raymond</surname>
+ <firstname>Eric</firstname>
+ <othername>Steven</othername>
</author>
-
- <title><ulink
- url="http://www.jwz.org/doc/worse-is-better.html">The Rise of
- <quote>Worse is Better</quote></ulink></title>
+
+ <title><ulink url="http://www.tldp.org/HOWTO/Software-Release-Practice-HOWTO/index.html">Software Release Practice HOWTO</ulink></title>
<abstract>
- <para>
- A well written article although I think the title may have
- confused as many people as the rest of the essay helped. It
- offers a good description of how to design programs that will
- succeed and stay maintainable as they grow.
- </para>
+
+ <para>At first glance, ESR's release practice HOWTO seems to
+ share a lot of terrain with this document. Upon closer
+ examination, the differences become apparent but they are
+ closely related. His document, read in conjunction with mine,
+ will give a reader a good picture of how to go about managing a
+ project. ESR's HOWTO goes into a bit more detail on how to write
+ and what languages to write in. He tends to give more specific
+ instructions and checklists (<quote>name this file this, not
+ this</quote>) while this HOWTO speaks more conceptually. There
+ are several sections that are extremely similar. It's also
+ <emphasis>much</emphasis> shorter.</para>
+
+ <para>My favorite quote from his HOWTO is: <quote>"Managing a
+ project well when all the participants are volunteers presents
+ some unique challenges. This is too large a topic to cover in a
+ HOWTO.</quote> Oh really? Perhaps I just do a poor job.</para>
+ </abstract>
+
+ </biblioset>
+ </biblioentry>
+
+
+ <biblioentry id="cvsbestpractices">
+ <biblioset>
+ <author>
+ <surname>Venugopalan</surname>
+ <firstname>Vivek</firstname>
+ </author>
+
+ <title><ulink url="http://www.magic-cauldron.com/cm/cvs-bestpractices/index.html">CVS Best Practices</ulink></title>
+
+ <abstract>
+
+ <para>Venugopalan provides one of the best essays on
+ effective use of CVS that I've come across. It is written for
+ people who already have a good knowledge of CVS. In the chapter
+ on branching, he describes when and how to branch but gives no
+ information on what CVS commands you should use to do this. This
+ is fine (technical CVS HOWTO have been written) but CVS newbies
+ will want to spend some time with Fogel's reference before they
+ will find this one very useful.</para>
+
+ <para>Venugopalan creates checklists of things to do before,
+ after, and around releases. It's definitely worth a read through
+ as most of his ideas will save tons of developer head aches over
+ any longer period of time.</para>
+
</abstract>
</biblioset>
</biblioentry>
+
</bibliodiv>
<bibliodiv>
</para>
<para>
- I have spent a huge amount of time on advogato and I've gone
+ I have spent a huge amount of time on Advogato and I've gone
through and provided links to the articles that I think might be
of particular interest to anyone reading this HOWTO. I think that
- skimming through these links can be helfpul and I promise that if
+ skimming through these links can be helpful and I promise that if
you do, you'll learn a lot. You will learn that my idea of how a
free software project should be run is not the
<emphasis>only</emphasis> idea. I think that's important.
If nothing else, there is <emphasis>way</emphasis> more
information on that website than I could ever fit into, or
reference from this HOWTO. I have listed what I think are the most
- relavant articles here with short descriptions that I've written.
+ relevant articles here with short descriptions that I've written.
</para>
<para>
Touching mostly on programming practice (as most articles on
the subject usually do), the article talks a little about
- project managment (<quote>Use it!</quote>) and a bit about
+ project management (<quote>Use it!</quote>) and a bit about
communication within a free software project.
</para>
</abstract>
<abstract>
<para>
While the article is little more than a question, reading the
- answers to this question offered by advogato's readers can
+ answers to this question offered by Advogato's readers can
help. In a lot of ways, this HOWTO acts as my answer to the
questions posed in this article but there are others, many of
which might take issue with whats is in this HOWTO. It's worth
<abstract>
<para>
This document was written as a response to <ulink
- url="http://www.advogato.org/article/72.html">another advogato
+ url="http://www.advogato.org/article/72.html">another Advogato
article</ulink>. Although not about running a project, this
describes some of the ways that you can get started with free
software development without starting a project. I think this
<surname>Moorman</surname>
<firstname>Jacob</firstname>
</author>
-
- <title><ulink
- url="http://www.advogato.org/article/72.html"></ulink>Importance
- of Non-Developer Supporters in Free Software</title>
-
+
+ <title><ulink url="http://www.advogato.org/article/72.html">Importance of
+ Non-Developer Supporters in Free Software</ulink><title></title>
+
<publisher>
<publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
</publisher>
<publisher>
<publishername><ulink url="http://www.advogato.org">Advogato</ulink></publishername>
</publisher>
- <pubdate>Februrary 28, 2000</pubdate>
+ <pubdate>February 28, 2000</pubdate>
<abstract>
<para>
- In this article, David Allen challengs the whole
+ In this article, David Allen challenges the whole
<quote>Major.Minor.Patch</quote> version numbering scheme. Its
good to read this as you read <xref
linkend="chooseversioning">. I liked the article and it
describes some of the projects that I bring up in my discussion
- of verion numbering.
+ of version numbering.
</para>
</abstract>
</biblioset>
</bibliodiv>
</bibliography>
-<!--
- The GNU Free Documentation License 1.1 in DocBook
- Markup by Eric Baudais <baudais@okstate.edu>
- Maintained by the GNOME Documentation Project
- http://developer.gnome.org/projects/gdp
- Version: 1.0.1
- Last Modified: Nov 16, 2000
--->
-
-<appendix id="fdl">
- <docinfo>
- <releaseinfo>
- Version 1.1, March 2000
- </releaseinfo>
- <copyright>
- <year>2000</year><holder>Free Software Foundation, Inc.</holder>
- </copyright>
- <legalnotice id="fdl-legalnotice">
- <para>
- <address>Free Software Foundation, Inc. <street>59 Temple Place,
- Suite 330</street>, <city>Boston</city>, <state>MA</state>
- <postcode>02111-1307</postcode> <country>USA</country></address>
- Everyone is permitted to copy and distribute verbatim copies of this
- license document, but changing it is not allowed.
- </para>
- </legalnotice>
- </docinfo>
+ <appendix id="fdl">
<title>GNU Free Documentation License</title>
-
- <sect1 id="fdl-preamble">
- <title>0. PREAMBLE</title>
- <para>
- The purpose of this License is to make a manual, textbook, or
- other written document <quote>free</quote> in the sense of
- freedom: to assure everyone the effective freedom to copy and
- redistribute it, with or without modifying it, either
- commercially or noncommercially. Secondarily, this License
- preserves for the author and publisher a way to get credit for
- their work, while not being considered responsible for
- modifications made by others.
- </para>
-
- <para>
- This License is a kind of <quote>copyleft</quote>, which means
- that derivative works of the document must themselves be free in
- the same sense. It complements the GNU General Public License,
- which is a copyleft license designed for free software.
- </para>
-
- <para>
- We have designed this License in order to use it for manuals for
- free software, because free software needs free documentation: a
- free program should come with manuals providing the same
- freedoms that the software does. But this License is not limited
- to software manuals; it can be used for any textual work,
- regardless of subject matter or whether it is published as a
- printed book. We recommend this License principally for works
- whose purpose is instruction or reference.
- </para>
- </sect1>
- <sect1 id="fdl-section1">
- <title>1. APPLICABILITY AND DEFINITIONS</title>
- <para id="fdl-document">
- This License applies to any manual or other work that contains a
- notice placed by the copyright holder saying it can be
- distributed under the terms of this License. The
- <quote>Document</quote>, below, refers to any such manual or
- work. Any member of the public is a licensee, and is addressed
- as <quote>you</quote>.
- </para>
-
- <para id="fdl-modified">
- A <quote>Modified Version</quote> of the Document means any work
- containing the Document or a portion of it, either copied
- verbatim, or with modifications and/or translated into another
- language.
- </para>
-
- <para id="fdl-secondary">
- A <quote>Secondary Section</quote> is a named appendix or a
- front-matter section of the <link
- linkend="fdl-document">Document</link> that deals exclusively
- with the relationship of the publishers or authors of the
- Document to the Document's overall subject (or to related
- matters) and contains nothing that could fall directly within
- that overall subject. (For example, if the Document is in part a
- textbook of mathematics, a Secondary Section may not explain any
- mathematics.) The relationship could be a matter of historical
- connection with the subject or with related matters, or of
- legal, commercial, philosophical, ethical or political position
- regarding them.
- </para>
-
- <para id="fdl-invariant">
- The <quote>Invariant Sections</quote> are certain <link
- linkend="fdl-secondary"> Secondary Sections</link> whose titles
- are designated, as being those of Invariant Sections, in the
- notice that says that the <link
- linkend="fdl-document">Document</link> is released under this
- License.
- </para>
-
- <para id="fdl-cover-texts">
- The <quote>Cover Texts</quote> are certain short passages of
- text that are listed, as Front-Cover Texts or Back-Cover Texts,
- in the notice that says that the <link
- linkend="fdl-document">Document</link> is released under this
- License.
- </para>
-
- <para id="fdl-transparent">
- A <quote>Transparent</quote> copy of the <link
- linkend="fdl-document"> Document</link> means a machine-readable
- copy, represented in a format whose specification is available
- to the general public, whose contents can be viewed and edited
- directly and straightforwardly with generic text editors or (for
- images composed of pixels) generic paint programs or (for
- drawings) some widely available drawing editor, and that is
- suitable for input to text formatters or for automatic
- translation to a variety of formats suitable for input to text
- formatters. A copy made in an otherwise Transparent file format
- whose markup has been designed to thwart or discourage
- subsequent modification by readers is not Transparent. A copy
- that is not <quote>Transparent</quote> is called
- <quote>Opaque</quote>.
- </para>
-
- <para>
- Examples of suitable formats for Transparent copies include
- plain ASCII without markup, Texinfo input format, LaTeX input
- format, SGML or XML using a publicly available DTD, and
- standard-conforming simple HTML designed for human
- modification. Opaque formats include PostScript, PDF,
- proprietary formats that can be read and edited only by
- proprietary word processors, SGML or XML for which the DTD
- and/or processing tools are not generally available, and the
- machine-generated HTML produced by some word processors for
- output purposes only.
- </para>
-
- <para id="fdl-title-page">
- The <quote>Title Page</quote> means, for a printed book, the
- title page itself, plus such following pages as are needed to
- hold, legibly, the material this License requires to appear in
- the title page. For works in formats which do not have any title
- page as such, <quote>Title Page</quote> means the text near the
- most prominent appearance of the work's title, preceding the
- beginning of the body of the text.
- </para>
- </sect1>
-
- <sect1 id="fdl-section2">
- <title>2. VERBATIM COPYING</title>
- <para>
- You may copy and distribute the <link
- linkend="fdl-document">Document</link> in any medium, either
- commercially or noncommercially, provided that this License, the
- copyright notices, and the license notice saying this License
- applies to the Document are reproduced in all copies, and that
- you add no other conditions whatsoever to those of this
- License. You may not use technical measures to obstruct or
- control the reading or further copying of the copies you make or
- distribute. However, you may accept compensation in exchange for
- copies. If you distribute a large enough number of copies you
- must also follow the conditions in <link
- linkend="fdl-section3">section 3</link>.
- </para>
-
- <para>
- You may also lend copies, under the same conditions stated
- above, and you may publicly display copies.
- </para>
- </sect1>
-
- <sect1 id="fdl-section3">
- <title>3. COPYING IN QUANTITY</title>
- <para>
- If you publish printed copies of the <link
- linkend="fdl-document">Document</link> numbering more than 100,
- and the Document's license notice requires <link
- linkend="fdl-cover-texts">Cover Texts</link>, you must enclose
- the copies in covers that carry, clearly and legibly, all these
- Cover Texts: Front-Cover Texts on the front cover, and
- Back-Cover Texts on the back cover. Both covers must also
- clearly and legibly identify you as the publisher of these
- copies. The front cover must present the full title with all
- words of the title equally prominent and visible. You may add
- other material on the covers in addition. Copying with changes
- limited to the covers, as long as they preserve the title of the
- <link linkend="fdl-document">Document</link> and satisfy these
- conditions, can be treated as verbatim copying in other
- respects.
- </para>
-
- <para>
- If the required texts for either cover are too voluminous to fit
- legibly, you should put the first ones listed (as many as fit
- reasonably) on the actual cover, and continue the rest onto
- adjacent pages.
- </para>
-
- <para>
- If you publish or distribute <link
- linkend="fdl-transparent">Opaque</link> copies of the <link
- linkend="fdl-document">Document</link> numbering more than 100,
- you must either include a machine-readable <link
- linkend="fdl-transparent">Transparent</link> copy along with
- each Opaque copy, or state in or with each Opaque copy a
- publicly-accessible computer-network location containing a
- complete Transparent copy of the Document, free of added
- material, which the general network-using public has access to
- download anonymously at no charge using public-standard network
- protocols. If you use the latter option, you must take
- reasonably prudent steps, when you begin distribution of Opaque
- copies in quantity, to ensure that this Transparent copy will
- remain thus accessible at the stated location until at least one
- year after the last time you distribute an Opaque copy (directly
- or through your agents or retailers) of that edition to the
- public.
- </para>
-
- <para>
- It is requested, but not required, that you contact the authors
- of the <link linkend="fdl-document">Document</link> well before
- redistributing any large number of copies, to give them a chance
- to provide you with an updated version of the Document.
- </para>
- </sect1>
-
- <sect1 id="fdl-section4">
- <title>4. MODIFICATIONS</title>
- <para>
- You may copy and distribute a <link
- linkend="fdl-modified">Modified Version</link> of the <link
- linkend="fdl-document">Document</link> under the conditions of
- sections <link linkend="fdl-section2">2</link> and <link
- linkend="fdl-section3">3</link> above, provided that you release
- the Modified Version under precisely this License, with the
- Modified Version filling the role of the Document, thus
- licensing distribution and modification of the Modified Version
- to whoever possesses a copy of it. In addition, you must do
- these things in the Modified Version:
- </para>
-
- <itemizedlist mark="opencircle">
- <listitem>
- <formalpara>
- <title>A</title>
- <para>
- Use in the <link linkend="fdl-title-page">Title
- Page</link> (and on the covers, if any) a title distinct
- from that of the <link
- linkend="fdl-document">Document</link>, and from those of
- previous versions (which should, if there were any, be
- listed in the History section of the Document). You may
- use the same title as a previous version if the original
- publisher of that version gives permission.
- </para>
- </formalpara>
- </listitem>
-
- <listitem>
- <formalpara>
- <title>B</title>
- <para>
- List on the <link linkend="fdl-title-page">Title
- Page</link>, as authors, one or more persons or entities
- responsible for authorship of the modifications in the
- <link linkend="fdl-modified">Modified Version</link>,
- together with at least five of the principal authors of
- the <link linkend="fdl-document">Document</link> (all of
- its principal authors, if it has less than five).
- </para>
- </formalpara>
- </listitem>
-
- <listitem>
- <formalpara>
- <title>C</title>
- <para>
- State on the <link linkend="fdl-title-page">Title
- Page</link> the name of the publisher of the <link
- linkend="fdl-modified">Modified Version</link>, as the
- publisher.
- </para>
- </formalpara>
- </listitem>
-
- <listitem>
- <formalpara>
- <title>D</title>
- <para>
- Preserve all the copyright notices of the <link
- linkend="fdl-document">Document</link>.
- </para>
- </formalpara>
- </listitem>
-
- <listitem>
- <formalpara>
- <title>E</title>
- <para>
- Add an appropriate copyright notice for your modifications
- adjacent to the other copyright notices.
- </para>
- </formalpara>
- </listitem>
-
- <listitem>
- <formalpara>
- <title>F</title>
- <para>
- Include, immediately after the copyright notices, a
- license notice giving the public permission to use the
- <link linkend="fdl-modified">Modified Version</link> under
- the terms of this License, in the form shown in the
- Addendum below.
- </para>
- </formalpara>
- </listitem>
-
- <listitem>
- <formalpara>
- <title>G</title>
- <para>
- Preserve in that license notice the full lists of <link
- linkend="fdl-invariant"> Invariant Sections</link> and
- required <link linkend="fdl-cover-texts">Cover
- Texts</link> given in the <link
- linkend="fdl-document">Document's</link> license notice.
- </para>
- </formalpara>
- </listitem>
-
- <listitem>
- <formalpara>
- <title>H</title>
- <para>
- Include an unaltered copy of this License.
- </para>
- </formalpara>
- </listitem>
-
- <listitem>
- <formalpara>
- <title>I</title>
- <para>
- Preserve the section entitled <quote>History</quote>, and
- its title, and add to it an item stating at least the
- title, year, new authors, and publisher of the <link
- linkend="fdl-modified">Modified Version </link>as given on
- the <link linkend="fdl-title-page">Title Page</link>. If
- there is no section entitled <quote>History</quote> in the
- <link linkend="fdl-document">Document</link>, create one
- stating the title, year, authors, and publisher of the
- Document as given on its Title Page, then add an item
- describing the Modified Version as stated in the previous
- sentence.
- </para>
- </formalpara>
- </listitem>
-
- <listitem>
- <formalpara>
- <title>J</title>
- <para>
- Preserve the network location, if any, given in the <link
- linkend="fdl-document">Document</link> for public access
- to a <link linkend="fdl-transparent">Transparent</link>
- copy of the Document, and likewise the network locations
- given in the Document for previous versions it was based
- on. These may be placed in the <quote>History</quote>
- section. You may omit a network location for a work that
- was published at least four years before the Document
- itself, or if the original publisher of the version it
- refers to gives permission.
- </para>
- </formalpara>
- </listitem>
-
- <listitem>
- <formalpara>
- <title>K</title>
- <para>
- In any section entitled <quote>Acknowledgements</quote> or
- <quote>Dedications</quote>, preserve the section's title,
- and preserve in the section all the substance and tone of
- each of the contributor acknowledgements and/or
- dedications given therein.
- </para>
- </formalpara>
- </listitem>
-
- <listitem>
- <formalpara>
- <title>L</title>
- <para>
- Preserve all the <link linkend="fdl-invariant">Invariant
- Sections</link> of the <link
- linkend="fdl-document">Document</link>, unaltered in their
- text and in their titles. Section numbers or the
- equivalent are not considered part of the section titles.
- </para>
- </formalpara>
- </listitem>
-
- <listitem>
- <formalpara>
- <title>M</title>
- <para>
- Delete any section entitled
- <quote>Endorsements</quote>. Such a section may not be
- included in the <link linkend="fdl-modified">Modified
- Version</link>.
- </para>
- </formalpara>
- </listitem>
-
- <listitem>
- <formalpara>
- <title>N</title>
- <para>
- Do not retitle any existing section as
- <quote>Endorsements</quote> or to conflict in title with
- any <link linkend="fdl-invariant">Invariant
- Section</link>.
- </para>
- </formalpara>
- </listitem>
- </itemizedlist>
-
- <para>
- If the <link linkend="fdl-modified">Modified Version</link>
- includes new front-matter sections or appendices that qualify as
- <link linkend="fdl-secondary">Secondary Sections</link> and
- contain no material copied from the Document, you may at your
- option designate some or all of these sections as invariant. To
- do this, add their titles to the list of <link
- linkend="fdl-invariant">Invariant Sections</link> in the
- Modified Version's license notice. These titles must be
- distinct from any other section titles.
- </para>
-
- <para>
- You may add a section entitled <quote>Endorsements</quote>,
- provided it contains nothing but endorsements of your <link
- linkend="fdl-modified">Modified Version</link> by various
- parties--for example, statements of peer review or that the text
- has been approved by an organization as the authoritative
- definition of a standard.
- </para>
-
- <para>
- You may add a passage of up to five words as a <link
- linkend="fdl-cover-texts">Front-Cover Text</link>, and a passage
- of up to 25 words as a <link
- linkend="fdl-cover-texts">Back-Cover Text</link>, to the end of
- the list of <link linkend="fdl-cover-texts">Cover Texts</link>
- in the <link linkend="fdl-modified">Modified Version</link>.
- Only one passage of Front-Cover Text and one of Back-Cover Text
- may be added by (or through arrangements made by) any one
- entity. If the <link linkend="fdl-document">Document</link>
- already includes a cover text for the same cover, previously
- added by you or by arrangement made by the same entity you are
- acting on behalf of, you may not add another; but you may
- replace the old one, on explicit permission from the previous
- publisher that added the old one.
- </para>
-
- <para>
- The author(s) and publisher(s) of the <link
- linkend="fdl-document">Document</link> do not by this License
- give permission to use their names for publicity for or to
- assert or imply endorsement of any <link
- linkend="fdl-modified">Modified Version </link>.
- </para>
- </sect1>
-
- <sect1 id="fdl-section5">
- <title>5. COMBINING DOCUMENTS</title>
- <para>
- You may combine the <link linkend="fdl-document">Document</link>
- with other documents released under this License, under the
- terms defined in <link linkend="fdl-section4">section 4</link>
- above for modified versions, provided that you include in the
- combination all of the <link linkend="fdl-invariant">Invariant
- Sections</link> of all of the original documents, unmodified,
- and list them all as Invariant Sections of your combined work in
- its license notice.
- </para>
-
- <para>
- The combined work need only contain one copy of this License,
- and multiple identical <link linkend="fdl-invariant">Invariant
- Sections</link> may be replaced with a single copy. If there are
- multiple Invariant Sections with the same name but different
- contents, make the title of each such section unique by adding
- at the end of it, in parentheses, the name of the original
- author or publisher of that section if known, or else a unique
- number. Make the same adjustment to the section titles in the
- list of Invariant Sections in the license notice of the combined
- work.
- </para>
-
- <para>
- In the combination, you must combine any sections entitled
- <quote>History</quote> in the various original documents,
- forming one section entitled <quote>History</quote>; likewise
- combine any sections entitled <quote>Acknowledgements</quote>,
- and any sections entitled <quote>Dedications</quote>. You must
- delete all sections entitled <quote>Endorsements.</quote>
- </para>
- </sect1>
-
- <sect1 id="fdl-section6">
- <title>6. COLLECTIONS OF DOCUMENTS</title>
- <para>
- You may make a collection consisting of the <link
- linkend="fdl-document">Document</link> and other documents
- released under this License, and replace the individual copies
- of this License in the various documents with a single copy that
- is included in the collection, provided that you follow the
- rules of this License for verbatim copying of each of the
- documents in all other respects.
- </para>
-
- <para>
- You may extract a single document from such a collection, and
- dispbibute it individually under this License, provided you
- insert a copy of this License into the extracted document, and
- follow this License in all other respects regarding verbatim
- copying of that document.
- </para>
- </sect1>
-
- <sect1 id="fdl-section7">
- <title>7. AGGREGATION WITH INDEPENDENT WORKS</title>
- <para>
- A compilation of the <link
- linkend="fdl-document">Document</link> or its derivatives with
- other separate and independent documents or works, in or on a
- volume of a storage or distribution medium, does not as a whole
- count as a <link linkend="fdl-modified">Modified Version</link>
- of the Document, provided no compilation copyright is claimed
- for the compilation. Such a compilation is called an
- <quote>aggregate</quote>, and this License does not apply to the
- other self-contained works thus compiled with the Document , on
- account of their being thus compiled, if they are not themselves
- derivative works of the Document. If the <link
- linkend="fdl-cover-texts">Cover Text</link> requirement of <link
- linkend="fdl-section3">section 3</link> is applicable to these
- copies of the Document, then if the Document is less than one
- quarter of the entire aggregate, the Document's Cover Texts may
- be placed on covers that surround only the Document within the
- aggregate. Otherwise they must appear on covers around the whole
- aggregate.
- </para>
- </sect1>
-
- <sect1 id="fdl-section8">
- <title>8. TRANSLATION</title>
- <para>
- Translation is considered a kind of modification, so you may
- distribute translations of the <link
- linkend="fdl-document">Document</link> under the terms of <link
- linkend="fdl-section4">section 4</link>. Replacing <link
- linkend="fdl-invariant"> Invariant Sections</link> with
- translations requires special permission from their copyright
- holders, but you may include translations of some or all
- Invariant Sections in addition to the original versions of these
- Invariant Sections. You may include a translation of this
- License provided that you also include the original English
- version of this License. In case of a disagreement between the
- translation and the original English version of this License,
- the original English version will prevail.
- </para>
- </sect1>
-
- <sect1 id="fdl-section9">
- <title>9. TERMINATION</title>
- <para>
- You may not copy, modify, sublicense, or distribute the <link
- linkend="fdl-document">Document</link> except as expressly
- provided for under this License. Any other attempt to copy,
- modify, sublicense or distribute the Document is void, and will
- automatically terminate your rights under this License. However,
- parties who have received copies, or rights, from you under this
- License will not have their licenses terminated so long as such
- parties remain in full compliance.
- </para>
- </sect1>
-
- <sect1 id="fdl-section10">
- <title>10. FUTURE REVISIONS OF THIS LICENSE</title>
- <para>
- The <ulink type="http"
- url="http://www.gnu.org/fsf/fsf.html">Free Software
- Foundation</ulink> may publish new, revised versions of the GNU
- Free Documentation License from time to time. Such new versions
- will be similar in spirit to the present version, but may differ
- in detail to address new problems or concerns. See <ulink
- type="http"
- url="http://www.gnu.org/copyleft">http://www.gnu.org/copyleft/</ulink>.
- </para>
-
- <para>
- Each version of the License is given a distinguishing version
- number. If the <link linkend="fdl-document">Document</link>
- specifies that a particular numbered version of this License
- <quote>or any later version</quote> applies to it, you have the
- option of following the terms and conditions either of that
- specified version or of any later version that has been
- published (not as a draft) by the Free Software Foundation. If
- the Document does not specify a version number of this License,
- you may choose any version ever published (not as a draft) by
- the Free Software Foundation.
- </para>
- </sect1>
-
- <sect1 id="fdl-using">
- <title>Addendum</title>
+ <para>
+ Copyright (C) 2000, 2001, 2002 Free Software Foundation,
+ <abbrev>Inc.</abbrev> 51 Franklin <abbrev>St</abbrev>, Fifth Floor,
+ Boston, <abbrev>MA</abbrev> 02110-1301 <abbrev
+ role="initialism">USA</abbrev>. Everyone is permitted to copy and
+ distribute verbatim copies of this license document, but changing it is
+ not allowed.
+ </para>
+ <bridgehead id="Preamble" renderas="sect1">
+ 0. PREAMBLE
+ </bridgehead>
+ <para>
+ The purpose of this License is to make a manual, textbook, or other
+ functional and useful document "free" in the sense of freedom: to assure
+ everyone the effective freedom to copy and redistribute it, with or
+ without modifying it, either commercially or noncommercially.
+ Secondarily, this License preserves for the author and publisher a way to
+ get credit for their work, while not being considered responsible for
+ modifications made by others.
+ </para>
+ <para>
+ This License is a kind of "copyleft", which means that derivative works of
+ the document must themselves be free in the same sense. It complements
+ the GNU General Public License, which is a copyleft license designed for
+ free software.
+ </para>
+ <para>
+ We have designed this License in order to use it for manuals for free
+ software, because free software needs free documentation: a free program
+ should come with manuals providing the same freedoms that the software
+ does. But this License is not limited to software manuals; it can be used
+ for any textual work, regardless of subject matter or whether it is
+ published as a printed book. We recommend this License principally for
+ works whose purpose is instruction or reference.</para>
+ <bridgehead id="Definitions" renderas="sect1">
+ 1. APPLICABILITY AND DEFINITIONS
+ </bridgehead>
+ <para>
+ This License applies to any manual or other work, in any medium, that
+ contains a notice placed by the copyright holder saying it can be
+ distributed under the terms of this License. Such a notice grants a
+ world-wide, royalty-free license, unlimited in duration, to use that work
+ under the conditions stated herein. The "Document", below, refers to any
+ such manual or work. Any member of the public is a licensee, and is
+ addressed as "you". You accept the license if you copy, modify or
+ distribute the work in a way requiring permission under copyright
+ law.
+ </para>
+ <para>
+ A "Modified Version" of the Document means any work containing the
+ Document or a portion of it, either copied verbatim, or with modifications
+ and/or translated into another language.
+ </para>
+ <para>
+ A "Secondary Section" is a named appendix or a front-matter section of the
+ Document that deals exclusively with the relationship of the publishers or
+ authors of the Document to the Document's overall subject (or to related
+ matters) and contains nothing that could fall directly within that overall
+ subject. (Thus, if the Document is in part a textbook of mathematics, a
+ Secondary Section may not explain any mathematics.) The relationship
+ could be a matter of historical connection with the subject or with
+ related matters, or of legal, commercial, philosophical, ethical or
+ political position regarding them.
+ </para>
+ <para>
+ The "Invariant Sections" are certain Secondary Sections whose titles are
+ designated, as being those of Invariant Sections, in the notice that says
+ that the Document is released under this License. If a section does not
+ fit the above definition of Secondary then it is not allowed to be
+ designated as Invariant. The Document may contain zero Invariant
+ Sections. If the Document does not identify any Invariant Sections then
+ there are none.
+ </para>
+ <para>
+ The "Cover Texts" are certain short passages of text that are listed, as
+ Front-Cover Texts or Back-Cover Texts, in the notice that says that the
+ Document is released under this License. A Front-Cover Text may be at
+ most 5 words, and a Back-Cover Text may be at most 25 words.
+ </para>
+ <para>
+ A "Transparent" copy of the Document means a machine-readable copy,
+ represented in a format whose specification is available to the general
+ public, that is suitable for revising the document straightforwardly with
+ generic text editors or (for images composed of pixels) generic paint
+ programs or (for drawings) some widely available drawing editor, and that
+ is suitable for input to text formatters or for automatic translation to a
+ variety of formats suitable for input to text formatters. A copy made in
+ an otherwise Transparent file format whose markup, or absence of markup,
+ has been arranged to thwart or discourage subsequent modification by
+ readers is not Transparent. An image format is not Transparent if used
+ for any substantial amount of text. A copy that is not "Transparent" is
+ called "Opaque".
+ </para>
+ <para>
+ Examples of suitable formats for Transparent copies include plain ASCII
+ without markup, Texinfo input format, LaTeX input format, SGML or XML
+ using a publicly available DTD, and standard-conforming simple HTML,
+ PostScript or PDF designed for human modification. Examples of
+ transparent image formats include PNG, XCF and JPG. Opaque formats
+ include proprietary formats that can be read and edited only by
+ proprietary word processors, SGML or XML for which the DTD and/or
+ processing tools are not generally available, and the machine-generated
+ HTML, PostScript or PDF produced by some word processors for output
+ purposes only.
+ </para>
+ <para>
+ The "Title Page" means, for a printed book, the title page itself, plus
+ such following pages as are needed to hold, legibly, the material this
+ License requires to appear in the title page. For works in formats which
+ do not have any title page as such, "Title Page" means the text near the
+ most prominent appearance of the work's title, preceding the beginning of
+ the body of the text.
+ </para>
+ <para>
+ A section "Entitled XYZ" means a named subunit of the Document whose title
+ either is precisely XYZ or contains XYZ in parentheses following text that
+ translates XYZ in another language. (Here XYZ stands for a specific
+ section name mentioned below, such as "Acknowledgements", "Dedications",
+ "Endorsements", or "History".) To "Preserve the Title" of such a section
+ when you modify the Document means that it remains a section "Entitled
+ XYZ" according to this definition.
+ </para>
+ <para>
+ The Document may include Warranty Disclaimers next to the notice which
+ states that this License applies to the Document. These Warranty
+ Disclaimers are considered to be included by reference in this License,
+ but only as regards disclaiming warranties: any other implication that
+ these Warranty Disclaimers may have is void and has no effect on the
+ meaning of this License.
+ </para>
+ <bridgehead id="VerbatimCopying" renderas="sect1">
+ 2. VERBATIM COPYING
+ </bridgehead>
+ <para>
+ You may copy and distribute the Document in any medium, either
+ commercially or noncommercially, provided that this License, the copyright
+ notices, and the license notice saying this License applies to the
+ Document are reproduced in all copies, and that you add no other
+ conditions whatsoever to those of this License. You may not use technical
+ measures to obstruct or control the reading or further copying of the
+ copies you make or distribute. However, you may accept compensation in
+ exchange for copies. If you distribute a large enough number of copies
+ you must also follow the conditions in section 3.
+ </para>
+ <para>
+ You may also lend copies, under the same conditions stated above, and you
+ may publicly display copies.
+ </para>
+ <bridgehead id="QuantityCopying" renderas="sect1">
+ 3. COPYING IN QUANTITY
+ </bridgehead>
+ <para>
+ If you publish printed copies (or copies in media that commonly have
+ printed covers) of the Document, numbering more than 100, and the
+ Document's license notice requires Cover Texts, you must enclose the
+ copies in covers that carry, clearly and legibly, all these Cover Texts:
+ Front-Cover Texts on the front cover, and Back-Cover Texts on the back
+ cover. Both covers must also clearly and legibly identify you as the
+ publisher of these copies. The front cover must present the full title
+ with all words of the title equally prominent and visible. You may add
+ other material on the covers in addition. Copying with changes limited to
+ the covers, as long as they preserve the title of the Document and satisfy
+ these conditions, can be treated as verbatim copying in other
+ respects.
+ </para>
+ <para>
+ If the required texts for either cover are too voluminous to fit legibly,
+ you should put the first ones listed (as many as fit reasonably) on the
+ actual cover, and continue the rest onto adjacent pages.
+ </para>
+ <para>
+ If you publish or distribute Opaque copies of the Document numbering more
+ than 100, you must either include a machine-readable Transparent copy
+ along with each Opaque copy, or state in or with each Opaque copy a
+ computer-network location from which the general network-using public has
+ access to download using public-standard network protocols a complete
+ Transparent copy of the Document, free of added material. If you use the
+ latter option, you must take reasonably prudent steps, when you begin
+ distribution of Opaque copies in quantity, to ensure that this Transparent
+ copy will remain thus accessible at the stated location until at least one
+ year after the last time you distribute an Opaque copy (directly or
+ through your agents or retailers) of that edition to the public.
+ </para>
+ <para>
+ It is requested, but not required, that you contact the authors of the
+ Document well before redistributing any large number of copies, to give
+ them a chance to provide you with an updated version of the
+ Document.
+ </para>
+ <bridgehead id="Modifications" renderas="sect1">
+ 4. MODIFICATIONS
+ </bridgehead>
+ <para>
+ You may copy and distribute a Modified Version of the Document under the
+ conditions of sections 2 and 3 above, provided that you release the
+ Modified Version under precisely this License, with the Modified Version
+ filling the role of the Document, thus licensing distribution and
+ modification of the Modified Version to whoever possesses a copy of it.
+ In addition, you must do these things in the Modified Version:
+ </para>
+ <orderedlist numeration="upperalpha">
+ <listitem>
+ <simpara>
+ Use in the Title Page (and on the covers, if any) a title distinct
+ from that of the Document, and from those of previous versions (which
+ should, if there were any, be listed in the History section of the
+ Document). You may use the same title as a previous version if the
+ original publisher of that version gives permission.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ List on the Title Page, as authors, one or more persons or entities
+ responsible for authorship of the modifications in the Modified
+ Version, together with at least five of the principal authors of the
+ Document (all of its principal authors, if it has fewer than five),
+ unless they release you from this requirement.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ State on the Title page the name of the publisher of the Modified
+ Version, as the publisher.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Preserve all the copyright notices of the Document.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Add an appropriate copyright notice for your modifications adjacent to
+ the other copyright notices.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Include, immediately after the copyright notices, a license notice
+ giving the public permission to use the Modified Version under the
+ terms of this License, in the form shown in the Addendum below.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Preserve in that license notice the full lists of Invariant Sections
+ and required Cover Texts given in the Document's license notice.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Include an unaltered copy of this License.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Preserve the section Entitled "History", Preserve its Title, and add
+ to it an item stating at least the title, year, new authors, and
+ publisher of the Modified Version as given on the Title Page. If
+ there is no section Entitled "History" in the Document, create one
+ stating the title, year, authors, and publisher of the Document as
+ given on its Title Page, then add an item describing the Modified
+ Version as stated in the previous sentence.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Preserve the network location, if any, given in the Document for
+ public access to a Transparent copy of the Document, and likewise the
+ network locations given in the Document for previous versions it was
+ based on. These may be placed in the "History" section. You may omit
+ a network location for a work that was published at least four years
+ before the Document itself, or if the original publisher of the
+ version it refers to gives permission.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ For any section Entitled "Acknowledgements" or "Dedications", Preserve
+ the Title of the section, and preserve in the section all the
+ substance and tone of each of the contributor acknowledgements and/or
+ dedications given therein.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Preserve all the Invariant Sections of the Document, unaltered in
+ their text and in their titles. Section numbers or the equivalent are
+ not considered part of the section titles.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Delete any section Entitled "Endorsements". Such a section may not be
+ included in the Modified Version.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Do not retitle any existing section to be Entitled "Endorsements" or
+ to conflict in title with any Invariant Section.
+ </simpara>
+ </listitem>
+ <listitem>
+ <simpara>
+ Preserve any Warranty Disclaimers.
+ </simpara>
+ </listitem>
+ </orderedlist>
+ <para>
+ If the Modified Version includes new front-matter sections or appendices
+ that qualify as Secondary Sections and contain no material copied from the
+ Document, you may at your option designate some or all of these sections
+ as invariant. To do this, add their titles to the list of Invariant
+ Sections in the Modified Version's license notice. These titles must be
+ distinct from any other section titles.
+ </para>
+ <para>
+ You may add a section Entitled "Endorsements", provided it contains
+ nothing but endorsements of your Modified Version by various parties--for
+ example, statements of peer review or that the text has been approved by
+ an organization as the authoritative definition of a standard.
+ </para>
+ <para>
+ You may add a passage of up to five words as a Front-Cover Text, and a
+ passage of up to 25 words as a Back-Cover Text, to the end of the list of
+ Cover Texts in the Modified Version. Only one passage of Front-Cover Text
+ and one of Back-Cover Text may be added by (or through arrangements made
+ by) any one entity. If the Document already includes a cover text for the
+ same cover, previously added by you or by arrangement made by the same
+ entity you are acting on behalf of, you may not add another; but you may
+ replace the old one, on explicit permission from the previous publisher
+ that added the old one.
+ </para>
+ <para>
+ The author(s) and publisher(s) of the Document do not by this License give
+ permission to use their names for publicity for or to assert or imply
+ endorsement of any Modified Version.
+ </para>
+ <bridgehead id="Combining" renderas="sect1">
+ 5. COMBINING DOCUMENTS
+ </bridgehead>
+ <para>
+ You may combine the Document with other documents released under this
+ License, under the terms defined in section 4 above for modified versions,
+ provided that you include in the combination all of the Invariant Sections
+ of all of the original documents, unmodified, and list them all as
+ Invariant Sections of your combined work in its license notice, and that
+ you preserve all their Warranty Disclaimers.
+ </para>
+ <para>
+ The combined work need only contain one copy of this License, and multiple
+ identical Invariant Sections may be replaced with a single copy. If there
+ are multiple Invariant Sections with the same name but different contents,
+ make the title of each such section unique by adding at the end of it, in
+ parentheses, the name of the original author or publisher of that section
+ if known, or else a unique number. Make the same adjustment to the
+ section titles in the list of Invariant Sections in the license notice of
+ the combined work.
+ </para>
+ <para>
+ In the combination, you must combine any sections Entitled "History" in
+ the various original documents, forming one section Entitled "History";
+ likewise combine any sections Entitled "Acknowledgements", and any
+ sections Entitled "Dedications". You must delete all sections Entitled
+ "Endorsements".
+ </para>
+ <bridgehead id="Collections" renderas="sect1">
+ 6. COLLECTIONS OF DOCUMENTS
+ </bridgehead>
+ <para>
+ You may make a collection consisting of the Document and other documents
+ released under this License, and replace the individual copies of this
+ License in the various documents with a single copy that is included in
+ the collection, provided that you follow the rules of this License for
+ verbatim copying of each of the documents in all other respects.
+ </para>
+ <para>
+ You may extract a single document from such a collection, and distribute
+ it individually under this License, provided you insert a copy of this
+ License into the extracted document, and follow this License in all other
+ respects regarding verbatim copying of that document.
+ </para>
+ <bridgehead id="Aggregation" renderas="sect1">
+ 7. AGGREGATION WITH INDEPENDENT WORKS
+ </bridgehead>
+ <para>
+ A compilation of the Document or its derivatives with other separate and
+ independent documents or works, in or on a volume of a storage or
+ distribution medium, is called an "aggregate" if the copyright resulting
+ from the compilation is not used to limit the legal rights of the
+ compilation's users beyond what the individual works permit. When the
+ Document is included in an aggregate, this License does not apply to the
+ other works in the aggregate which are not themselves derivative works of
+ the Document.
+ </para>
+ <para>
+ If the Cover Text requirement of section 3 is applicable to these copies
+ of the Document, then if the Document is less than one half of the entire
+ aggregate, the Document's Cover Texts may be placed on covers that bracket
+ the Document within the aggregate, or the electronic equivalent of covers
+ if the Document is in electronic form. Otherwise they must appear on
+ printed covers that bracket the whole aggregate.
+ </para>
+ <bridgehead id="Translation" renderas="sect1">
+ 8. TRANSLATION
+ </bridgehead>
+ <para>
+ Translation is considered a kind of modification, so you may distribute
+ translations of the Document under the terms of section 4. Replacing
+ Invariant Sections with translations requires special permission from
+ their copyright holders, but you may include translations of some or all
+ Invariant Sections in addition to the original versions of these Invariant
+ Sections. You may include a translation of this License, and all the
+ license notices in the Document, and any Warranty Disclaimers, provided
+ that you also include the original English version of this License and the
+ original versions of those notices and disclaimers. In case of a
+ disagreement between the translation and the original version of this
+ License or a notice or disclaimer, the original version will prevail.
+ </para>
+ <para>
+ If a section in the Document is Entitled "Acknowledgements",
+ "Dedications", or "History", the requirement (section 4) to Preserve its
+ Title (section 1) will typically require changing the actual title.
+ </para>
+ <bridgehead id="Termination" renderas="sect1">
+ 9. TERMINATION
+ </bridgehead>
+ <para>
+ You may not copy, modify, sublicense, or distribute the Document except as
+ expressly provided for under this License. Any other attempt to copy,
+ modify, sublicense or distribute the Document is void, and will
+ automatically terminate your rights under this License. However, parties
+ who have received copies, or rights, from you under this License will not
+ have their licenses terminated so long as such parties remain in full
+ compliance.
+ </para>
+ <bridgehead id="FutureRevisions" renderas="sect1">
+ 10. FUTURE REVISIONS OF THIS LICENSE
+ </bridgehead>
+ <para>
+ The Free Software Foundation may publish new, revised versions of the GNU
+ Free Documentation License from time to time. Such new versions will be
+ similar in spirit to the present version, but may differ in detail to
+ address new problems or concerns. See <ulink
+ url="http://www.gnu.org/copyleft/">http://www.gnu.org/copyleft/</ulink>.
+ </para>
+ <para>
+ Each version of the License is given a distinguishing version number. If
+ the Document specifies that a particular numbered version of this License
+ "or any later version" applies to it, you have the option of following the
+ terms and conditions either of that specified version or of any later
+ version that has been published (not as a draft) by the Free Software
+ Foundation. If the Document does not specify a version number of this
+ License, you may choose any version ever published (not as a draft) by the
+ Free Software Foundation.
+ </para>
+ <bridgehead id="HowToUse" renderas="sect1">
+ ADDENDUM: How to use this License for your documents
+ </bridgehead>
+ <para>
+ To use this License in a document you have written, include a copy of the
+ License in the document and put the following copyright and license
+ notices just after the title page:
+ </para>
+ <blockquote>
<para>
- To use this License in a document you have written, include a copy of
- the License in the document and put the following copyright and
- license notices just after the title page:
+ Copyright (C) YEAR YOUR NAME.
</para>
-
- <blockquote>
- <para>
- Copyright © YEAR YOUR NAME.
- </para>
- <para>
- Permission is granted to copy, distribute and/or modify this
- document under the terms of the GNU Free Documentation
- License, Version 1.1 or any later version published by the
- Free Software Foundation; with the <link
- linkend="fdl-invariant">Invariant Sections</link> being LIST
- THEIR TITLES, with the <link
- linkend="fdl-cover-texts">Front-Cover Texts</link> being LIST,
- and with the <link linkend="fdl-cover-texts">Back-Cover
- Texts</link> being LIST. A copy of the license is included in
- the section entitled <quote>GNU Free Documentation
- License</quote>.
- </para>
- </blockquote>
-
<para>
- If you have no <link linkend="fdl-invariant">Invariant
- Sections</link>, write <quote>with no Invariant Sections</quote>
- instead of saying which ones are invariant. If you have no
- <link linkend="fdl-cover-texts">Front-Cover Texts</link>, write
- <quote>no Front-Cover Texts</quote> instead of
- <quote>Front-Cover Texts being LIST</quote>; likewise for <link
- linkend="fdl-cover-texts">Back-Cover Texts</link>.
+ Permission is granted to copy, distribute and/or modify this document
+ under the terms of the GNU Free Documentation License, Version 1.2 or
+ any later version published by the Free Software Foundation; with no
+ Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A
+ copy of the license is included in the section entitled "GNU Free
+ Documentation License".
</para>
-
+ </blockquote>
+ <para>
+ If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
+ replace the "with...Texts." line with this:
+ </para>
+ <blockquote>
<para>
- If your document contains nontrivial examples of program code,
- we recommend releasing these examples in parallel under your
- choice of free software license, such as the <ulink type="http"
- url="http://www.gnu.org/copyleft/gpl.html"> GNU General Public
- License</ulink>, to permit their use in free software.
+ with the Invariant Sections being LIST THEIR TITLES, with the
+ Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
</para>
- </sect1>
-</appendix>
+ </blockquote>
+ <para>
+ If you have Invariant Sections without Cover Texts, or some other
+ combination of the three, merge those two alternatives to suit the
+ situation.
+ </para>
+ <para>
+ If your document contains nontrivial examples of program code, we
+ recommend releasing these examples in parallel under your choice of free
+ software license, such as the GNU General Public License, to permit their
+ use in free software.
+ </para>
+</appendix>
</article>
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
--->
\ No newline at end of file
+-->
projects / fspm_howto / blobdiff