Update open-definition-approval-process.markdown

Update with recommendations from OD2.0dev before recommended section was pulled.

source/open-definition-approval-process.markdown

@@ -1,46 +1,40 @@
-##Removed from OD 2.0dev (3.3. Recommendations for Open Licenses)
+*Update for http://opendefinition.org/licenses/process/*
 
-    NB: This section is still completely a work in progress, and may or may not be adopted.
-
-Licenses with the following characteristics help the open ecosystem by maintaining interoperability and avoiding high costs. (If AC and approval are mentioned in this document, might say we don't approve licenses not following these recommendations.)
+This pages outlines the process for submitting a license so that it can be checked for conformance against the [Open Definition](/od), and hence listed on the [Conformant Licenses page](/licenses) in the appropriate category (see license categories below).
 
-#### Reusable
-
-Not specific to an organization or jurisdiction.
-
-#### Compatible
-
-With? Should some license(s) be baked in?
-
-#### Coverage
-
-Something about granting rights to something substantial and clear? eg not only game rules
-
-#### Understandable
-
-If AC has to debate what license really means, it isn't understandable. Is there some way to express this generally?
-
-
-##Source of http://opendefinition.org/licenses/process/
-
-This pages outlines the process for submitting a license so that it can be checked for conformance against the [Open Definition](/okd), and hence listed on [Conformant Licenses page](/licenses).
-
-The [Advisory Council](/advisory-council) will make the final decision on whether or not a license conforms to the Open Knowledge Definition, based on the Open Source Definition. This decision will typically follow the consensus reached via discussion on the mailing list.
+The [Advisory Council](/advisory-council) will make the final decision on whether or not a license conforms to the Open Definition and in which category to place the license. This decision will typically follow the consensus reached via discussion on the mailing list.
 
 ##Submitting The License
-Submit the license to the Open Definition [mailing list](/contact) for discussion. To do this:
+Submit the license to the Open Definition [mailing list](/contact) for discussion. **For a new license, this should occur before the license is finalized, so that you can revise based on the group's feedback.**
+
+To do this:
 
 * Sign up to the mailing list, so that you can participate in the discussion.
-* Send a link to the full text the license to the mailing list, along with answers to the following:
+* Send a link to the full text the license to the mailing list, along **all of the following information**:
   1. State the rationale for the new license.
   2. Is the license specific to an organization/place/jurisdiction? We generally frown on such licenses (see proliferation below), only making politically expedient exceptions (eg, the organization is a national government; and these are categorized as "non-reusable").
   3. Compare and contrast to any existing similar approved as [OD-conformant licenses](/licenses/).
   4. What benefit does the new license bring over already approved OD-conformant licenses which would outweigh the costs of [license proliferation](http://opensource.org/proliferation-report)? (Link is re software licenses, but the same principles and costs apply.)
   5. Is the license compatible with existing OD-conformant licenses? By alignment (permissions identical or a superset of existing license, conditions identical or a subset) and/or express permission to license the original and/or adaptations of the licensed work under an existing license?
   6. Provide a link to any public drafting process (e.g., conducted on a public communication forum of some sort; multiple drafts presented to that forum) for the license.
 
-Ideally, this should occur before the license is finalized, so that you can revise based on the group's feedback.
 
 ##What Will Happen
 
 After submission, the Open Definition community will discuss on the mailing list and reach consensus. The Open Definition Advisory Council chair will summarize the consensus to the Advisory Council on the mailing list. If after two weeks at least two Advisory Council members approve the consensus summary on-list, and at least 75% of Advisory Council members expressing an opinion on the summary if any dissent, the website will be updated, and announcements made to public and submitter, as appropriate.
+
+
+##License categories
+
+**Conformant and Recommended.** These licenses conform to the Open Definition **and** are:
+
+* Reusable: Not specific to an organization or jurisdiction.
+* Compatible: Must be compatible with at least one of GPL-3.0+, CC-BY-SA-4.0, and ODbL-1.0. Permissive/attribution-only licenses must be compatible with all 3 of the aforementioned licenses, and at least one of Apache-2.0, CC-BY-4.0, and ODC-BY-1.0.
+* Coverage: Must grant substantial and clear rights, e.g., anything covered by copyright.
+* Understandable: If the AC has to debate what license really means, it isn't understandable. A clear policy objective unabiguously reflected in the license text is necessary for the AC to avoid such debate. Additionally: Does the license follow [good drafting practices](http://lu.is/blog/2013/10/06/reviewing-the-manual-of-style-for-contract-drafting-by-editing-twitters-patent-agreement/)? How does it compare to other licenses' [automated readability metrics](http://gondwanaland.com/mlog/2013/09/22/license-readability/)?
+
+**Conformant and Old or Little Used.** These licenses conform to the Open Defintion and are reusable, compatible, offer significant coverage, and are understandable, but have been superceded by newer versions of the same license or newer licenses with similar use cases, or are little-used.
+
+**Conformant and Not Recommended.** These licenses conform to the Open Definition but are not one or more of reusable, compatible, offering significant coverage, or understandable. These licenses may be reasonable for the particular organization they were crafted for to use, or to use for legacy reasons, but should not be considered by an entity outside such a context for a fresh project.
+
+**Non-conformant.** These licenses are NOT OPEN and will be listed on http://opendefinition.org/licenses/nonconformant/