PEP 639: Move description of status quo to Motivation & tweak text

pep-0639.rst

@@ -121,8 +121,10 @@ binary distribution packages don't have :ref:`the same licenses
 Motivation
 ==========
 
-All software is licensed, and providing accurate license information to Python
-package users is an important matter. Today, there are multiple fields where
+Software must be licensed in order for anyone other than its creator to
+download, use, share and modify it, so providing accurate license information
+to Python package users is an important matter.
+Today, there are multiple fields where
 licenses are documented in core metadata, and there are limitations to what
 can be expressed in each of them. This often leads to confusion and a lack of
 clarity, both for package authors and end users.
@@ -137,6 +139,29 @@ including on `outdated and ambiguous PyPI classifiers <classifierissue_>`__,
 `limited support for license files in the Wheel project <wheelfiles_>`__, and
 `the lack of clear, precise and standardized license metadata <pepissue_>`__.
 
+The current license classifiers address some common cases, and could
+theoretically be extended to include the full range of current SPDX
+identifiers while deprecating the many ambiguous classifiers (including some
+extremely popular and particularly problematic ones, such as
+``License :: OSI Approved :: BSD License``). However, this both requires a
+substantial amount of effort to duplicate the SPDX license list and keep
+it in sync, and is effectively a hard break in backward compatibility,
+forcing a huge proportion of package authors to immediately update to new
+classifiers (in most cases, with many possible choices that require closely
+examining the project's license) immediately when PyPI deprecates the old ones.
+
+Furthermore, this only covers simple packages entirely under a single license;
+it doesn't address the substantial fraction of common projects that vendor
+dependencies (e.g. Setuptools), offer a choice of licenses (e.g. Packaging)
+or were relicensed, adapt code from other projects or contain fonts, images,
+examples, binaries or other assets under other licenses. It also requires
+both authors and tools understand and implement the PyPI-specific bespoke
+classifier system, rather than using short, easy to add and standardized
+SPDX identifiers in a simple text field, as increasingly widely adopted by
+most other packaging systems to reduce the overall burden on the ecosystem.
+Finally, this does not provide as clear an indicator that a package
+has adopted the new system, and should be treated accordingly.
+
 On average, Python packages tend to have more ambiguous and missing license
 information than other common ecosystems (such as npm, Maven or
 Gem). This is supported by the `statistics page <cdstats_>`__ of the
@@ -158,7 +183,8 @@ and license documentation in a variety of other packaging systems,
 Linux distros, languages ecosystems and applications is surveyed in
 :ref:`another appendix <639-license-doc-other-projects>`.
 
-There are a few takeaways from the survey:
+There are a few takeaways from the survey, which have guided the design
+and recommendations of this PEP:
 
 - Most package formats use a single ``License`` field.
 
@@ -174,31 +200,6 @@ There are a few takeaways from the survey:
   Open Source Software licenses require package authors to include their full
   text in a distribution.
 
-These considerations have guided the design and recommendations of this PEP.
-
-The current license classifiers cover some common cases, and could
-theoretically be extended to include the full range of current SPDX
-identifiers while deprecating the many ambiguous classifiers (including some
-extremely popular and particularly problematic ones, such as
-``License :: OSI Approved :: BSD License``). However, this both requires a
-substantial amount of effort to duplicate the SPDX license list and keep
-it in sync, and is effectively a hard break in backward compatibility,
-forcing a huge proportion of package authors to immediately update to new
-classifiers (in most cases, with many possible choices that require closely
-examining the project's license) immediately when PyPI deprecates the old ones.
-
-Furthermore, this only covers simple packages entirely under a single license;
-it doesn't address the substantial fraction of common projects that vendor
-dependencies (e.g. Setuptools), offer a choice of licenses (e.g. Packaging)
-or were relicensed, adapt code from other projects or contain fonts, images,
-examples, binaries or other assets under other licenses. It also requires
-both authors and tools understand and implement the PyPI-specific bespoke
-classifier system, rather than using short, easy to add and standardized
-SPDX identifiers in a simple text field, as increasingly widely adopted by
-most other packaging systems to reduce the overall burden on the ecosystem.
-Finally, this does not provide as clear an indicator that a package
-has adopted the new system, and should be treated accordingly.
-
 The use of a new ``License-Expression`` field will provide an intuitive,
 structured and unambiguous way to express the license of a
 package using a well-defined syntax and well-known license identifiers.