--- a/xml/en/docs/faq/accept_failed.xml
+++ b/xml/en/docs/faq/accept_failed.xml
@@ -1,8 +1,8 @@
-<!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
+<!DOCTYPE article SYSTEM "../../../../dtd/article.dtd">
 
 <article name="What does the following error mean:
-                accept() failed (53: Software caused connection abort)
-                while accepting new connection on 0.0.0.0:80 ?"
+               accept() failed (53: Software caused connection abort)
+               while accepting new connection on 0.0.0.0:80?"
          link="/en/docs/faq/accept_failed.html"
          lang="en">
 
@@ -24,10 +24,10 @@ connection on 0.0.0.0:80"?
 Such errors stem from the connections that the clients managed
 to close before nginx was able to process them. For instance, this can
 happen in a situation when the user didn't wait for a page
-heavily populated with graphics to load fully, and clicked on
-a different link. In this case user's browser would close all of
-the prior connections which aren't longer necessary. It is a non-critical
-error.
+heavily populated with images to load fully, and clicked on a
+different link. In this case user's browser would close all of
+the prior connections which aren't longer necessary.
+It is a non-critical error.
 </para>
 
 </section>

--- a/xml/en/docs/faq/chunked_encoding_from_backend.xml
+++ b/xml/en/docs/faq/chunked_encoding_from_backend.xml
@@ -29,9 +29,9 @@ 0
 
 <para>
 <initial>A:</initial>
-Your backend violates HTTP/1.0 specification (see
+Your backend violates HTTP specification (see
 <a href="http://tools.ietf.org/html/rfc2616#section-3.6">RFC 2616,
-"3.6 Transfer Codings"</a>
+"3.6 Transfer Codings"</a>).
 The "chunked" transfer-codings must not be used with HTTP/1.0.
 You'd need to either fix your backend application or upgrade
 to nginx version 1.1.4 and newer, where an additional code

--- a/xml/en/docs/faq/daemon_master_process_off.xml
+++ b/xml/en/docs/faq/daemon_master_process_off.xml
@@ -1,4 +1,4 @@
-<!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
+<!DOCTYPE article SYSTEM "../../../../dtd/article.dtd">
 
 <article name="Can I run nginx with daemon off or
                master_process off settings
@@ -10,7 +10,7 @@
 
 <para>
 <initial>Q:</initial>
-Can I run nginx with daemon off or master_process off settings
+Can I run nginx with "daemon off" or "master_process off" settings
 in a production environment?
 </para>
 
@@ -21,24 +21,24 @@ in a production environment?
 <para>
 <initial>A:</initial>
 First of all, both "daemon on|off" and "master_process on|off" directives were
-intended to be used for nginx code develpment.
+intended to be used primarily for nginx code develpment.
 </para>
 
 <para>
-While many people use daemon off in production it wasn't really meant for
+While many people use "daemon off" in production it wasn't really meant for
 that. Since version 1.0.9 it is now quite safe to run nginx in production
-with daemon off, though. Bear in mind that non-stop upgrade is not an
-option with daemon off.
+with "daemon off", though. Bear in mind that non-stop upgrade is not an
+option with "daemon off".
 </para>
 
 <para>
-In a development environment, using master_process off, nginx can run in
+In a development environment, using "master_process off", nginx can run in
 the foreground without the master process and can be terminated simply
 with ^C (SIGINT). This is somewhat similar to running Apache with
-an 'X' commandline option. However you should never run nginx in production
-with master_process off.
+an 'X' commandline option. However you should NEVER run nginx in production
+with "master_process off".
 </para>
 
 </section>
 
-</article>
\ No newline at end of file
+</article>

--- a/xml/en/docs/faq/license_copyright.xml
+++ b/xml/en/docs/faq/license_copyright.xml
@@ -21,7 +21,12 @@ when using nginx as part of a proprietar
 
 <para>
 <initial>A:</initial>
-The section of text below should be added to your license descriptions.
+The text below should be added to your license conditions,
+followed by the text of the applicable 2-clause BSD license described
+<a href="http://nginx.org/LICENSE">here</a>.
+</para>
+
+<para>
 Also, if your build of nginx includes any of the following 3rd party
 products: zlib, PCRE, OpenSSL &#8212; it's worth including their
 copyright acknowledgements and disclaimers as well.
@@ -29,29 +34,6 @@ copyright acknowledgements and disclaime
 
 <programlisting>
 This product contains software provided by Nginx, Inc. and its contributors.
-
-Copyright (c) 2002-2011, Igor Sysoev. All rights reserved.
-Copyright (c) 2011, Nginx, Inc. All rights reserved.
-
-Redistribution and use in source and binary forms, with or without modification, are
-permitted provided that the following conditions are met:
-1. Redistributions of source code must retain the above copyright
-notice, this list of conditions and the following disclaimer.
-2. Redistributions in binary form must reproduce the above copyright
-notice, this list of conditions and the following disclaimer in the
-documentation and/or other materials provided with the distribution.
-
-THIS SOFTWARE IS PROVIDED BY NGINX, INC. AND CONTRIBUTORS AS IS AND
-ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-ARE DISCLAIMED. IN NO EVENT SHALL NGINX, INC. OR CONTRIBUTORS BE LIABLE
-FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
-OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
-LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
-OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
-SUCH DAMAGE.
 </programlisting>
 
 </section>

--- a/xml/en/docs/faq/variables_in_config.xml
+++ b/xml/en/docs/faq/variables_in_config.xml
@@ -1,4 +1,4 @@
-<!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
+<!DOCTYPE article SYSTEM "../../../../dtd/article.dtd">
 
 <article name="Is there a proper way to use nginx variables to
                make sections of the configuration shorter,
@@ -26,10 +26,10 @@ Variables should not be used as template
 evaluated in the run-time during the processing of each
 request, so they are rather costly compared to plain static
 configuration. Using variables to store static strings is also
-a bad idea. Instead, a macro expansion should be used to
-generate configs more easily and it can be done with the
-external tools, e.g. sed + make or any other common template
-mechanism.
+a bad idea. Instead, a macro expansion and "include" directives
+should be used to generate configs more easily and it can be
+done with the external tools, e.g. sed + make or any other
+common template mechanism.
 </para>
 
 </section>