Source: https://thomasalspaugh.org/pub/osl-sps/index.html
Timestamp: 2019-04-18 20:26:42+00:00

Document:
The Open Source Initiative provides standard texts for each license it has certified as Open Source. However, because the licenses are organized and formatted in a variety of ways (and because a few licenses have apparent formatting problems), it is difficult to make an unambiguous reference to a section, paragraph, sentence, or word in a license.
Here are a selection of prominent open-source software (OSS) licenses and a few others, with sections, paragraphs, sentences, and words numbered for unambiguous reference. The numbering has been done by a program, guided occasionally by me (see Mapping §¶s markup to a document).
Each word in the licenses has been given its own HTML id based on its §-¶-sentence-word position. Hover the cursor over a word to see its HTML id and full §¶sw location. For example, this has HTML id 'S1p8s3w3' indicating it is section 1, paragraph 8, sentence 3, word 3 (hover the cursor over it to verify for yourself), and a hyperlink like this one can be set up to jump to that specific word.
Sections, paragraphs, and sentences have their own HTML ids that can be used to hyperlink to them. §1¶9ṣ2 Sentence ids are visible (like the one at the beginning of this sentence), and paragraph and section ids can be inferred from them; ṣ2.1 this sentence's id is S1¶9ṣ2, so this paragraph's id is S1p9 and this section's is S1. Hyperlinks can be set up to the sentence, paragraph, and section.
Where the license text gives section or list item numbers, or uses letters or Roman numerals, the §-¶-sentence numbers match them. If the section numbers begin at 0 rather than 1, and the §-¶-sentence numbers match this also.
Each document is modelled as a title, zero or more enumerated paragraphs, and zero or more enumerated sections. Each section is recursively modelled the same way, with a heading as its title and subsections as its sections. The recursion continues down as deep as HTML supports (h6). At this writing, the deepest level required by a license is the h5 level used in the Sun Community Source License (SCSL) v2.8.
Each paragraph comprises one or more sentences; each sentence comprises one or more words. A sentence is divided into clauses (for lack of a more widely-accepted term) at semicolons and colons, and at inline list item markers such as (i) or (1) .
If needed for list items, the latter part of a paragraph may be divided into enumerated subparagraphs, and the latter part of each subparagraph into enumerated subsubparagraphs; the division points need not be between sentences. At this writing the deepest paragraph subdivisions are into subsubparagraphs. The LGPLv3.0 license, for example, utilizes subsubparagraphs in a nested list. Paragraphs are only divided into subparagraphs and subsubparagraphs if required for list elements.
If needed for list items, the latter part of a clause may be divided into enumerated subclauses. At this writing, for example, the MPL 1.1 license utilizes subclauses in a nested list. Clauses are only divided into subclauses if required for list elements.
Commas, quotation marks, and other punctuation not affecting the markup may appear anywhere.
The overwhelming majority of text in licenses has proved to fit this model. However, there are some exceptions.
Headings that do not influence the section depth.
A few licenses contain no-effect headings, text with the appearance and feel of headings but that does not appear to start a new section based on the section numbering in the license.
For example, the Artistic 2.0 license has a sequence of numbered subsections with no-effect headings interspersed, but through which the numbering sequence of the subsections continues unaffected. An example is Permissions for Redistribution of the Standard Version.
In such cases, the no-effect heading is modelled as the last paragraph of the preceding subsection, but formatted as a heading at its supposed level, except in a dark gray font.
In a few licenses, the section depth (as indicated by section numbering in the license) changes without a heading.
For example, the Artistic 2.0 license (again), after two top-level section headings, begins numbering sections or subsections starting with (1) . The meaning of the apparent heading that precedes this only applies to the first subsection (1), not to the later ones numbered (2) and so forth.
In this case, a ghost heading is placed where the new group of subsections begins, with a descriptive phrase in light gray and enclosed in square brackets. The words in ghost headings are not counted in the numbering.
At this writing, the example in the Artistic 2.0 license is the only ghost heading that has been inserted.
§1¶1ṣ1 Figure 2 illustrates how §¶s markup is mapped to a document.
§1¶2ṣ1 The document title is not numbered.
§1¶3ṣ1 Paragraphs not in a section are numbered in sequence and have no section number (like the initial paragraph of this document). §1¶3ṣ2 Top-level paragraphs in a section at whatever level are numbered in sequence within that section, as are the paragraphs in this section. §1¶3ṣ2 A subsection at whatever level restarts the paragraph numbering within that subsection. §1¶4ṣ3 Within each paragraph, sentences are numbered in sequence (as are the sentences of this paragraph); ṣ3.1 clauses after the initial one of a sentence are numbered in sequence beginning with 1.
§1¶4ṣ1 Each heading begins a new section at some level: ṣ1.1 a top-level heading begins a top-level section such as §1, a second-level heading a subsection such as §1.1, and so forth. §1¶4ṣ2 Within each section, the paragraphs are numbered (1-origin), and within each paragraph the sentences are numbered (also 1-origin). §1¶4ṣ3 A dot, bang, or hook (.!?) is intepreted as marking the end of a sentence. §1¶4ṣ4 Within each sentence, a colon or semicolon (:;) is interpreted as marking the end of each clause (for lack of a more widely-accepted term): ṣ4.1 the second and later clauses of each sentence are numbered beginning with 1 for the second clause, as the marker illustrates.
§1¶5ṣ1 If the text contains no headings, or in paragraphs before the first section heading, the markers and ids begin with the paragraph number (for example ¶4ṣ1 p4 for the fourth paragraph of a document without section headings).
§1.1¶1ṣ1 In some cases, the characters that mark the ends of sentences and clauses appear for other purposes. §1.1¶1ṣ2 A common example is the abbreviation U.S. , which contains two dots but is not two sentences. §1.1¶1ṣ3 I have identified these and marked the license source up accordingly so that the dots etc. are present in the text but do not affect the §¶sw numbering.
The licenses display section and list numbering with arabic and Roman numerals and letters, and the §¶s numbering follows their format, both in markers and HTML ids. For example, a section whose heading is numbered 1.a.i will have marker §1.a.i and HTML id S1.a.i; its first paragraph will have marker §1.a.i¶1 and HTML id S1.a.ip1, and so forth. Each use of non-arabic numbering was individually set by me.
In some cases, section numbering or list item numbering begins at 0 in the license text, in which case the §¶s numbering matches it.
Where the license contains a list, the appropriate §¶s numbering is not always obvious. The following rules, chosen with the goal of producing §¶s numbering that is both consistent and minimally arbitrary, were followed in manually determining the numbering for each list.
If at least one item consists of one or more sentences, then the list items are numbered as paragraphs or subparagraphs. Paragraphs are used if the list begins a section, subsection, etc. Subparagraphs are used if the preceding paragraph ends with a colon, or if the list items are numbered.
No list items are numbered as sentences, even if each item is a single sentence, because the resulting numbering has not seemed to express the structure of the text. Lists of single-sentence items are numbered as subparagraphs instead.
If each item is a clause of the sentence preceding the list, then the list items are numbered as clauses of that sentence.
If none of these is the case (for example if some items are clauses and others are full sentences or paragraphs), then the numbering is chosen to match the structure as appropriately as possible, in my judgement.
For nested lists, the numbering is often problematic, and is chosen to match every level as appropriately as possible.
In all cases (such as AGPL §1¶4) where the license contains an inline enumerated list of items (often a lengthy list) within a single paragraph, the license is presented here with the inline list formatted with each item set out separately. Each list item is numbered as a separate clause (or subclause if nested). Inline lists are presented with a faint identifying background.
Each license is presented with a list of links to its defined terms and section headings (if any), floating on the right margin. Note that some licenses, for example BSD, define no terms and are not divided into sections. Others define so many terms and have so many sections (AGPLv3, GPLv3) that you must choose which you wish to see at any one time.
I have added editorial notes where these seemed helpful. The notes are of course not part of the license text.
Each license has a note giving its source.
By default the notes are shown; hide (and show them again) by clicking the Hide/show notes box at the top of each license page.
There is an analogous Hide/show §¶s box at the top of each license page if you wish to hide (or re-show) the §¶s markers.
The texts are marked up to indicate where they are identical and where they are different. Showing/hiding the editorial notes also shows/hides this markup.
The licenses discussed by Rosen: BSD, MIT, Apache [1.1], Artistic [1.0], GPLv2, LGPLv2.1, MPL 1.1, CPL 1.0, and his own licenses AFL [2.0] and OSL [2.0]. Where a license has been superseded by a newer version (indicated by [ ]), the newer version appears here.
The licenses discussed by St. Laurent: MIT, BSD, Apache [1.1], Apache 2.0, AFL [2.0], GPLv2, LGPLv2.1, MPL 1.1, QPL (superseded by GPL), Artistic, CC-BY-SA[1.0], the author's Classic Proprietary License (here we use CTL as an example proprietary license), SCSL, and the MSSI licenses (represented here by Ms-PL). Where a license has been superseded by a newer version, the newer version appears here.
All the licenses listed by the Open Source Initiative under the category License[s] that are popular and widely used or with strong communities over the span of this research project: Apache 2.0, BSD, GPLv2, GPLv3, LGPLv2.1, LGPLv3, MIT, MPL 1.1, CDDL 1.0, and EPL 1.0.
All the licenses listed by the Open Source Initiative under the category Other/Miscellaneous licenses over the span of this research project: APL, Artistic 2.0, OSL 3.0, QPL 1.0, and zlib/libpng.
All of the licenses listed under the category Special purpose licenses : ECL, IPA Font, NASA 1.3, and OFL 1.1.
All the licenses that have appeared on Black Duck Software's list of the twenty most commonly used OSS licenses over the span of this research project: GPLv2, LGPLv2.1, Artistic, BSD, GPLv3, MIT, Apache 2.0, CPOL 1.02, Ms-PL, MPL 1.1, CPL 1.0, EPL 1.0, LGPLv3, zlib/libpng, AFL 3.0, CDDL 1.0, OSL 3.0, MPL 1.0, PHP 3.0, Ruby, and Ms-RL.
AGPLv3 is included because of its distinctive provisions for software services.
The CC0 Waiver is included as an example of a public-domain dedication.
The obsolete BSD 4-clause license is included because it is often referred to even if now rarely used.
The Google Apps Agreement is included as an example of an agreement for the use of software services as opposed to the software itself.
GFDL 1.3 is included as an example of an OSS documentation license.
The UDK License is included as an example of a license with many third-party licenses, and because of its unusual licensing terms.
License texts are the approved texts from the Open Source Initiative web site, or (for non-OSI-approved licenses) the most authoritative available text. Each license page has a link to its original text.
Each license text is an accurate copy verified as thoroughly as possible, except for the small number of cases (identified by editorial notes) in which I found strong reason to believe there had been a typographical or formatting error. In those cases, text in this web directory proposes a reasonable correction (for research and educational purposes only). The verification is done automatically using software tools. From time to time as I examine the licenses in new ways and as I improve the verification software, I find new problems and correct them, so the license texts presented here are not completely static. Please contact me if you find any error in the licenses.
The licenses presented in this web directory are not the work of this researcher, and their use here is a fair use for educational purposes without commercial gain.
The annotations added to the licenses by Thomas A. Alspaugh are published under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
Lawrence Rosen. Open Source Licensing: Software Freedom and Intellectual Property Law. Prentice Hall, 2005.
Andrew M. St. Laurent. Understanding Open Source and Free Software Licensing. O’Reilly Media, Inc., 2004.
If you’ve held back from developing open source or free software projects because you don’t understand the implications of the various licenses, you’re not alone. Many developers believe in releasing their software freely, but have hesitated to do so because they’re concerned about losing control over their software. Licensing issues are complicated, and both the facts and fallacies you hear word-of-mouth can add to the confusion. Understanding Open Source and Free Software Licensing helps you make sense of the different options available to you. This concise guide focuses on annotated licenses, offering an in-depth explanation of how they compare and interoperate, and how license choices affect project possibilities. Written in clear language that you don’t have to be a lawyer to understand, the book answers such questions as: What rights am I giving up? How will my use of OS/FS licensing affect future users or future developers? Does a particular use of this software–such as combining it with proprietary software–leave me vulnerable to lawsuits? Following a quick look at copyright law, contracts, and the definition of “open source,” the book tackles the spectrum of licensing, including: The MIT (or X), BSD, Apache and Academic Free licensesThe GPL, LGPL, and Mozilla licensesThe QT, Artistic, and Creative Commons licensesClassic Proprietary licensesSun Community Source license and Microsoft Shared Source project The book wraps up with a look at the legal effects–both positive and negative–of open source/free software licensing. Licensing is a major part of what open source and free software are all about, but it’s still one of the most complicated areas of law. Even the very simple licenses are tricky. Understanding Open Source and Free Software Licensing bridges the gap between the open source vision and the practical implications of its legal underpinnings. If open source and free software licenses interest you, this book will help you understand them. If you’re an open source/free software developer, this book is an absolute necessity.

References: §1

§1

§1

§1
 §1
 §1
 §1

§1
 §1
 §1
 §1
 §1
 §1

§1

§1
 §1
 §1
 §1
 §1
 §1