The existing paragraph on this issue was inadequate, since it punted
entirely to GPLv2§11 for dealing with critics' claims of
unenforceability. That left a mistaken impression of validity of such
claims.
The commit herein adds reference to CIGS, which likely permits GPL's
sort of warranty disclaimer in most jurisdictions, and also bolsters the
reference to the UCC earlier in the section.
However, given academic debate about the applicability of CIGS to
software licenses, this commit includes a footnote referencing the two
sides of that debate.
Tony Sebro and I co-drafted these changes together.
Signed-Off-By: Tony Sebro <tony@sfconservancy.org>
Signed-Off-By: Bradley M. Kuhn <bkuhn@ebb.org>
While most USA lawyers will know this as simple fact, the tutorial wants
to welcome an international audience and non-lawyers too. As such, this
dependent clause is worth adding.
The intent of this text was to point out that most users don't actually
believe they get warranties, which is still surely correct, given that
GPL disclaims warranties in the same manner nearly every software
license -- proprietary or free -- does anyway.
Also, the forward-reference to the later section's discussion of UCC
should be hinted at here. There is no explicit reference to UCC made
here, but it is encompassed in "many local laws", since the later
section mentions the specific section of UCC involved.
Meanwhile, the reference to UCITA is dropped, but perhaps it should be
reintroduced in other text in the main warranty section. UCITA has had
much less policy impact than was expected when the original version of
this text was written. It might be useful to ask policy folks and
attorneys from Maryland and Virginia who might be able to help explain
what impact UCITA has had being on the books only there.
CCS ultimately wasn't mentioned until much later in the GPLv3 sections,
where, ironically, we have to point out that GPLv3 defined the term as
"Corresponding Source" [0], not CCS, and explain why GPL enforcement
wonks still say CCS.
This rework now introduces the acronym at the natural moment: while
describing GPLv2§3's use of the words "complete" and "corresponding".
Adding that made the section even more disjoint than it already was. I
put in some \subsection's to make it slightly less so, and did some
wordsmith work on surrounding text.
[0] I wish some GPLv3 drafter had asked me what to call the defined term
so that I could point out what fit standard parlance. :)
The existing text of the Guide hints at this point but doesn't discuss
it directly. This FIXME is merely a reminder note to investigate this
issue in further detail and perhaps add text here on the question.
Integration of text from third-party works is complicated, since the
text must be incorporated to flow properly with the rest of the Guide.
Also, historical archiving commits are particularly useful in such
situations. This tutorial explains how to contribute such additions for
this project.
Historically, this project used (more-or-less) a file-by-file copyright
inventory. This commit ends that practice. The project now has a
single toplevel copyright inventory, stored exclusively in
comprehensive-gpl-guide.tex (so that it appears also in compiled
versions of the Guide as well).
The side-effect of this commit is that the parts may no longer be easily
publishable separably without (at least) the additional work of
copyright notice reconstruction. This may in particular create a
challenge for the FSF, who has historically selectively published
sections of this Guide as materials for its CLE classes.
However, without this change, this Guide will eventually suffer from the
inherent problems in maintaining file-by-file copyright inventory.
Circumstances simply dictate a single, top-level copyright and license
notice for the entire Guide.
In addition to consolidation of copyright notices, I've also herein
updated my historical copyright notices to properly credit me for my own
work done in 2003 through 2005.
I've also updated the license notice to reflect the changes made by the
previous commit and related issues.
As alluded to in 2ea19b71d4 's commit
message on 2014-12-17 19:52:15 -0500, keeping any information on a
part-by-part basis is difficult and error-prone, since there exists no
reliable way to auto-generate such information accurately.
Therefore, citations to third-party works, in addition to remaining
fully documented in the commit log as they always have been, are now
placed in specifically one location in the body of the text itself: a
single appendix specifically designed for that purpose.
In this manner, contributors have no house-keeping work regarding
citations. Contributors need only list third party works and links in
one place: third-party-citations.tex.
Documentation in CONTRIBUTING.md for making contributions of third-party
works is left as a TODO.
I think Fontana's change a few commits back which s/it/such software/ in
this sentence is a useful one. However, the entire sentence reads even
worse because "such software Free Software" looks so strange as a string
of words in the middle of the sentence.
This change is the best rework I could find that resolved the problem.
It's probably not the best option but is certainly an improvement.
My personal comment here, which I wrote on 2003-05-26 (see
f05ce6c657 ), is probably not particularly
useful. I still tend to use the phrasing as original stated in the
removed text herein; however, I'm admittedly the only one. I don't deny
that I hope to coin some terminology usage through my work on this
Guide, but this particular use of "nonfree software" to mean
"noncommercially proprietary" is not so important IMO that this Guide
must coin it.
The FSF's page on this doesn't make that distinction, and has much more
detail on this issue than this section does. Therefore, the
personal statement is removed, and the organizational statement on the
FSF's site is instead linked to.
Commenting on one: the initial-caps stylistic preference for "Free
Software" (though it contradicts prevailing usage, including that of RMS
and the FSF) ought to be respected, but I think it is confusing to
capitalize the 'S' when referring to nonfree software as "non-Free
Software". So I changed this to "non-Free software" and also implicitly
acknowledged that the preference for "non-Free" over "nonfree" is the
editor-in-chief's stylistic idiosyncrasy.
Upstream in the copyleft.org tutorial repository, the next branch is
sometimes rebased against the master branch. (For example, this occurs
when there have been quick fixes done on 'master' while new drafting
occurs on 'next'.)
This procedure, while convoluted, is the best way I've found to
compensate for this problem. Hosting sites like Gitorious really aren't
designed for rebased branches.
Ultimately, users will probably pick either 'master' or 'next' to submit
changes anyway, so just leave the instructions to refer to 'next' and
note that they could replace 'next' with 'master'.
Most Gitorious users know this procedure, but it seems useful to
document it in great detail here, since copyleft.org seeks contributions
from those who might be knew to Git, and those who are more familiar
with procedures of other collaboration sites.
