From 30cdf93d0c3791a2463f99963daf253f3d093fb1 Mon Sep 17 00:00:00 2001
From: Scott Rifenbark <scott.m.rifenbark@intel.com>
Date: Tue, 26 Mar 2013 16:54:32 -0700
Subject: [PATCH] ref-manual: Edits to the license flag matching section.

Partial edits.

(From yocto-docs rev: 32c1d40eff9a3e27d5ec09bde57e2c344bb2ded9)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 .../ref-manual/technical-details.xml          | 66 +++++++++++--------
 1 file changed, 39 insertions(+), 27 deletions(-)

diff --git a/documentation/ref-manual/technical-details.xml b/documentation/ref-manual/technical-details.xml
index 1f3901358b..d66d7050a1 100644
--- a/documentation/ref-manual/technical-details.xml
+++ b/documentation/ref-manual/technical-details.xml
@@ -902,48 +902,60 @@
             <title>License Flag Matching</title>
 
             <para>
-		        The definition of "matching" in reference to a
-		        recipe's <filename>LICENSE_FLAGS</filename> setting is simple.
-                However, some things exist that you should know about in order to
-                correctly and effectively use it.
+		        In general, license flag matching is simple.
+                However, understanding some concepts will help you 
+                correctly and effectively use matching.
             </para>
 
             <para>
                 Before a flag
                 defined by a particular recipe is tested against the
                 contents of the <filename>LICENSE_FLAGS_WHITELIST</filename> variable, the
-                string <filename>_${PN}</filename> (with
-                <link linkend='var-PN'><filename>PN</filename></link> expanded of course) is
-                appended to the flag, thus automatically making each
-                <filename>LICENSE_FLAGS</filename> value recipe-specific.
-                That string is
-                then matched against the whitelist.
-                So if you specify <filename>LICENSE_FLAGS = "commercial"</filename> in recipe
-		        "foo" for example, the string <filename>"commercial_foo"</filename>
-                would normally be what is specified in the whitelist in order for it to
-                match.
+                expanded string <filename>_${PN}</filename> is
+                appended to the flag.
+                This expansion makes each <filename>LICENSE_FLAGS</filename> 
+                value recipe-specific.
+                After expansion, the string is then matched against the 
+                whitelist.
+                Thus, specifying <filename>LICENSE_FLAGS = "commercial"</filename> 
+                in recipe "foo" for example, results in the string 
+                <filename>"commercial_foo"</filename>.
+                And that string would normally be appears in the whitelist
+                in order for a match to occur.
             </para>
 
             <para>
-                You can broaden the match by
-                putting any "_"-separated beginning subset of a
-                <filename>LICENSE_FLAGS</filename> flag in the whitelist, which will also
-                match.
-                For example, simply specifying "commercial" in
-                the whitelist would match any expanded <filename>LICENSE_FLAGS</filename>
-                definition starting with "commercial" such as
-                "commercial_foo" and "commercial_bar", which are the
-                strings that would be automatically generated for
-                hypothetical "foo" and "bar" recipes assuming those
-                recipes had simply specified the following:
+                Judicious use of the <filename>LICENSE_FLAGS</filename> 
+                strings and the contents of the 
+                <filename>LICENSE_FLAGS_WHITELIST</filename> variable
+                allows you a lot of flexibility for matching license
+                flags.
+                For example, you can broaden the matching capabilities by 
+                using string subsets from the <filename>LICENSE_FLAGS</filename> 
+                variables in the whitelist.
+                <note>Be sure to use the part of the expanded  
+                    string that precedes
+                    the underscore character (e.g.   
+                    <filename>usethispart_1.3</filename>,
+                    <filename>usethispart_1.4</filename>, and so forth).
+                </note>
+                For example, simply specifying the string "commercial" in
+                the whitelist matches any expanded 
+                <filename>LICENSE_FLAGS</filename> definition that starts with 
+                the string "commercial" such as "commercial_foo" and 
+                "commercial_bar", which are the strings the build system 
+                automatically generates for hypothetical recipes named
+                "foo" and "bar" assuming those recipes simply specify the 
+                following:
                 <literallayout class='monospaced'>
      LICENSE_FLAGS = "commercial"
                 </literallayout>
             </para>
 
             <para>
-                Broadening the match allows for a range of specificity for the items
-                in the whitelist, from more general to perfectly
+                Judicious use of the strings with the 
+                <filename>LICENSE_FLAGS</filename> variable and the Broadening the match allows for a range of specificity for the 
+                items in the whitelist, from more general to perfectly
                 specific.
                 So you have the choice of exhaustively
                 enumerating each license flag in the whitelist to