Fix formatting and line lengths in section 1.
Revise Corresponding Source definition.

To some degree this commit moves the Corresponding Source definition a
bit further away from the GPLv3 definition and back towards the GPLv2
definition.

The reference to interface definition files is moved up (similar to
GPLv2) and the term 'associated' (found in GPLv2) replaces 'relevant'.

A more significant change is the replacement of "all scripts,
instructions and information known to you necessary for a skilled
developer to build, compile, generate and modify the Covered Work"
with "all scripts, instructions and similar information that were used
to build such Source Code". "Similar" is added to avoid a potential
open-ended reading of unmodified "information". "Known to you" is
deleted to avoid arguments about what sort of knowledge is meant
(e.g., in an organizational context). Instead of referring to what is
objectively necessary for a skilled developer to compile and modify,
we revert to a GPLv2-like approach of speaking of what was actually
used to generate the binary. Which of these approaches is better may
still be debatable; it seems to be a basic policy question that should
be informed by practical experiences in GPL enforcement. A side-effect
of this change is that the 'expansive set of verbs' definitional
approach associated with GPLv3, which admittedly has some benefits, is
now gone.

bkuhn's 'list requirement', a novel addition to the definition, is
retained with some greater conciseness.

Finally, I have decided to delete the GPLv3-derived "Source Code of
shared libraries that the Covered Work is specifically designed to
require, such as by intimate data communication or control flow
between those libraries and parts of the Covered Work". I do this with
significant regret and reluctance, as I like that phrase in the GPLv3
definition for multiple reasons. On the copyleft-next mailing list,
Ted Ts'o suggests it, or part of it, may suffer from vagueness. My
question is whether, if it should be preserved, should it not be
better placed in the definition of Covered Work (or Derived Work) (in
which case it would by implication be caught by the definition of
Corresponding Source)? One value of this language is that it
demonstrates that simplistic views of FSF strong copyleft doctrine are
incorrect. However, the FSF handled this matter well in the pre-GPLv3
era through public commentary. I am vaguely concerned that, in
copyleft-next, there is some logical problem with its placement in the
Corresponding Source definition. I cannot quite articulate that well
without some discussion from someone (e.g. Bradley?) who might wish to
argue for its retention. (I am not at all so concerned that the
meaning of 'intimate' (also used in the FSF GNU Licenses FAQ) may be
argued by some to be insufficiently clear; I find it helpfully
suggestive as legal language.)

Essentially, I wish to understand what this language accomplishes that
is frustrated by its removal.

If I distribute object code Foo, and there is some shared library Bar
that Foo is specifically designed to require, then perhaps I should be
required to include the Source Code of Bar in some cases, but why
shouldn't that be a clarification to the definition of Covered
Work/Derived Work? If I am already distributing Bar with (in some
sense) Foo, why isn't it already captured by the existing definitions?
If I am not distributing Bar, why does strong copyleft policy care
whether I provide its Source Code? (This is not a rhetorical question;
there may be a good answer.) It seems best to start over with this
one, sadly.