@keynote2k was the first to point out that the in-page anchor links in
the Guide failed to function properly, due to Bootstrap's fixed navbar.
This mixed solution of CSS and Javascript is the best solution I've been
able to come up with for the problem. The CSS solution is obviously
preferable, and is used herein for those anchor id attributes in the
Guide that have no href of their own.
Due to problems with using a pure CSS solution where the anchor includes
both an href and a id attribute. The Javascript solution is specific
for those cases. I took care not to have them both happen at once, as
they would undoubtedly conflict.
I did a inordinate amount of research about this issue. Bootstrap's own
page about the fixed navbar:
http://getbootstrap.com/examples/navbar-fixed-top/
doesn't discuss this issue at all, but there is a bug in Booststrap's
bugtracker:
https://github.com/twitter/bootstrap/issues/1768
which discusses the issue. (However, I don't understand why that bug is
closed, since none of the solutions I implement herein truly solve it).
The most useful page I found regarding this issue is this one:
http://nicolasgallagher.com/jump-links-and-viewport-positioning/demo
which offers several pure CCS solutions (each with drawbacks and
advantages). Unfortunately, none of those solutions consider the
question of anchor links that have both href and id attributes, and none
of them work properly in that situation.
In the HTML rendered versions of the guide, the quoted text, using the
previous CSS herein include, seemed to prominent.
Hopefully, this change will resolve that issue.
There was one minor change to the title page on master that isn't
represented on 'next'. While I could have rebased, I chose to merge so
I didn't have delete the publicly published 'next' branch on gitorious
like I have to do when I rebase.
I think this sounds better. While "enforcement" is a noun and therefore
it seems it should be "pluralizable", "enforcements" wasn't in my
dictionary as a correctly spelled word, and that made me realize I'd
never heard "enforcements" used in a plural before, and it immediately
sounded weird. So, I changed it.
The unicode ’ was introduced by the pasted text mention in the previous
commits. While I believe LaTeX can be configured to accept Unicode
quote equivalents, it seems simpler to me merely to replace the
character with an appropriate version that LaTeX expects in this
situation by default.
Much of the pasted text here was useful. However, some of the claims
were broad reaching, I've reigned those in. (e.g., saying "Taken
together, these provisions mean:" was a bit strong).
Also, in that specific spot, the conclusions made in the text were
described as applying to LGPLv2.1, but are clearly conclusions about
LGPLv3. I've corrected that herein.
Finally, I had to write a bunch of next text to make the pasted text
work, and also added one FIXME for later of where things could be
improved further.
Often, the PDF file is separated fully from copyleft and distributed.
As such, the title page should not only include a link to the sources
for patches, but also for the main copyleft.org site for the Guide.
This text was mostly useful as is. However, it failed to make a key
point I've often made: that the combinations created by comingling
AGPLv3'd code with GPLv3'd code may be difficult to disentangle, and
thus in practice, it may turn out that such a combination effectively
must be licensed as a whole under AGPLv3, even if technically some
copyrights included therein are GPLv3'd.
In practice, this nuance is only a technical barrier, since complying
fully with AGPLv3 automatically complies with GPLv3.
This text was (on the whole) useful as introductory text to this
tutorial's existing extensive section on GPLv3§11.
The example, however, belonged further down in the section, so I've
placed it there.
Most of this text was useful, particularly since there was a previous
FIXME here that GPLv3§10 was not extensively discussed.
However, the same footnote regarding Jaeger's opinion under German
copyright law applies to this text, so a reference back to it has herein
been added.
The pasted text, most of which was useful, is now integrated as the
desired laundry-list of GPLv3§7 subsection explanations.
This also allowed for easy integration of some of the older
commented-out text that originally came from GPLv3 rationale documents.
Meanwhile, however, I discovered, upon more careful examination of the
pasted text, a serious and grave error regarding GPLv3§7(d).
Specifically, GPLv3§7(d) makes the modern "third clause" of the 3-Clause
BSD compatible with the GPL, *not* the problematic old-school BSD
advertising clause (from the 4-Clause BSD).
I'm amazed that anyone versed in licensing could make this error,
frankly, and readers should be told, since other materials are now
disseminated by others, that the point is incorrect. Therefore, I've
not only noted the correct compatibility conclusion, but also
affirmatively identified the incorrectness of the wrong conclusion that
was previously added via the pasted text from SFLC's "Guide".
Finally, on a LaTeX formatting note, the enumitem package is now needed
since I'm using that for the list of GPLv3§7 subsections.
This change perhaps is somewhat controversial, but reflects honest
reality of this history of additional requirements on GPL. The
additional requirements that GPLv3 permits mostly represent historically
known situations where GPLv2 permitted license compatibility with Free
Software licenses containing such requirements.
Orthodox compatibility theory demands that such additional requirements
have explicit codification in a copyleft license, which hints at why
GPLv3 needed to include this section.
However, historical copyright holder toleration of these sorts of
requirements placed on GPLv2 works is well-documented, and failure to
mention it here is a disservice to the reader.
