* added initial draft of bsd4clause-openssl.tex file * grafted as new section of "Special Topics in Compliance" chapter * added reference to "GPLv3 §7: Understanding License Compatibility" section of "GPL Version 3" chapter
The Gitorious URLs are now dead. A few Gitorious URLs continued to appear in the front matter of the Guide itself. This fixes those links to with k.copyleft.org equivalents.
The Gitorious URLs will disappear in the next few hours. The canonical hosting location of this project is now on copyleft.org. Specific gitorious URLs are generally replaced with k.copyleft.org, which is copyleft.org's self-hosted Kallithea instance.
The fragment is indeed large enough to be fair to state its license. I'd suggest however to not say that quotations are licensable. Not every quotation is 'licensed' or needs to be. In theory, anyway. While in this case it's okay, I'd suggest to call it, for example, 'fragment'.
From public domain to copyleft, insert a couple phrases about permissive licensing, as alternative for public domain and as intention to enforce certain conditions.
Nitpicking, there aren't only two types, those by the license and those breaking the license, but also those covered by limitations/exemptions in copyright law.
I'd suggest to avoid it. There is no need for it: Free Software offers all rights to enjoy the software in the privacy of one's home without doing anything special (arguably even when enjoying rights under copyright, but privately), it's distribution that triggers obligations.
There is a widespread assumption in free licensing work that permissions come from the copyright holders -always-. This assumption is not unwarranted; among other reasons, because there is a 'fundamental distinction in copyright law' (Nimmer) between material object and intellectual content. Even if the distribution chain would give rights (which is not the perception in free licensing), and even if someone on this chain would lose their rights (terminated), downstream (also) has the license from the (c) holder to get their rights from as long as they fulfill the conditions themselves.
Modified works are derivative works, they are under the scope of 106 (2) (while they are under 106 (1) as well). I assume the intention here was to clarify they're the easy case of derivative works? That seems important and correct.
Proposed a few tweaks to express this idea without implying that modified works are not derivative works.
Modify sentence that oversimplifies notion of completeness of software freedom. In reality the FSF (as chief guardians of what the definition of free software is) and the larger Free Software community have tolerated certain kinds of restrictions on software freedom. One example, called out in my change to this sentence, is that of copyleft requirements. To arch lax-permissive-license advocates copyleft requirements may be an undue restriction on software freedom, but the larger Free Software community considers copyleft (at least within limits recognized by the FSF) to be a tolerable deviation from maximum software freedom for a given user. In the case of copyleft, the justification is that the constraints on that user allow software freedom to be maximized among the larger set of present and future users.
Correct inconsistency in use/nonuse of definite article before non-attributive uses of *GPLvn by opting for typical present-day FSF usage (with no article). I believe the FSF tends to use "GPLvn" (rather than "the GPLvn") when the license is referred to by abbreviation and is not prefixed by "GNU". This can be confirmed by analysis of usage on the fsf.org website.
Uncommented material on implied patent licenses and GPLv3 sec. 11 definition of "patent license", with added sentence noting final paragraph of sec. 11.
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>
Note that most USA states/commonwealths adopt UCC.
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. :)
I've set this to FIXME-URGENT as I will merge this into a public branch after this commit, and I want it clear that we cannot merge into next or master until this is resolved.
This footnote, co-drafted by me and Richard Fontana, explains the apparent uniqueness GPLv3's preservation clause for GPLv2's original implied patent license.
Fontana pointed out this distinction with commercial patent licensing. I noticed as a further point that even some copyleft licenses, let alone non-copyleft Free Software licenses, fail to include any clauses preserving implicit patent license grants. Such is certainly of concern for those licenses that contain explicit patent licensing provisions.
Fontana notes that during GPLv3 process, he was concerned that an explicit patent license in GPLv3 might provide a basis for some to later argue an implied patent license was no longer present. GPLv3§11's final paragraph assures its safety.
Upon consultation with Richard Fontana, we drafted together this rewrite of the original paragraph discussing this issue.
The original paragraph was tersely written and indeed accurate. However, it was likely comprehensible only to those already familiar with patent licensing regimes and systems. As such, it fit poorly in the tutorial, which is designed for all policy makers who care about copyleft, who may in fact be new to patent policy and licensing.
Please note: Richard Fontana <fontana@sharpeleven.org> dictated to me some of this text, and therefore he is likely a copyright and "creator" (per CC-BY-SA 4.0) of some of this text. In fact, since we wrote it collaboratively, I suspect Fontana and I are co-copyright holders and co-creators of this commit.
Uncommented material on implied patent licenses and GPLv3 sec. 11 definition of "patent license", with added sentence noting final paragraph of sec. 11.
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 2ea19b71d4a917babb29024f06acabfe73309f40 '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 f05ce6c657e07a5e6c6def3f7ff8cb2b2bcf6246 ), 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.
No instructions for 'master';just note possibility
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'.
Detailed merge request instructions for Gitorious.
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.