diff --git a/LDP/howto/docbook/Software-Proj-Mgmt-HOWTO.sgml b/LDP/howto/docbook/Software-Proj-Mgmt-HOWTO.sgml
index b1a0b37a..95ea659d 100644
--- a/LDP/howto/docbook/Software-Proj-Mgmt-HOWTO.sgml
+++ b/LDP/howto/docbook/Software-Proj-Mgmt-HOWTO.sgml
@@ -700,7 +700,7 @@
Source Definition. Examples of free licenses given by the
DFSG are the GPL, the
BSD, and the Artistic License. As ESR mentions
- in his his HOWTO, don't write your own
+ in his HOWTO, 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
@@ -1320,7 +1320,7 @@ pages for more information and options.
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
+ speak English or not confident in your skills, ask a friend
for help. Like it or not, fair or unfair, English is
the language of free software. However, this does not
mean you should limit your documentation to only English. If you
@@ -1402,7 +1402,7 @@ pages for more information and options.
possible. Remember: While these binaries packages are
nice, getting the source packaged and released should always be
your priority. Your users or fellow developers can and will do
- the the binary packages for you.
+ the binary packages for you.
@@ -1794,7 +1794,7 @@ pages for more information and options.
The answers to these questions are never straightforward and its
very possible (and even likely) that the person who submitted the
patch may feel differently about the answer to these questions
- than you do. However, if you feel that that the answer to either
+ than you do. However, if you feel that the answer to either
of those questions is no,
it is your responsibility
to reject the change. If you fail to do this, the project will
become unwieldy and unmaintainable and many ultimately fail.
@@ -2877,7 +2877,7 @@ pages for more information and options.
Although I have to honestly say that I am not the ESR fan that
I used to be, this book proved invaluable in getting me where I
am today. The essay that gives the book its title does a good
- job of sketching the free software process and does an an
+ job of sketching the free software process and does an
amazing job of making an argument for free software/open source
development as a road to better software. The rest of the book
has other of ESR's articles, which for the most part are posted
@@ -2943,7 +2943,7 @@ pages for more information and options.
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 you will be be placing yourself at the
+ that you will be placing yourself at the
center of in your capacity as maintainer of a free software
project.