Add missing nicknames
Use SPDX ID if no customary nickname (eg GNU GPLv3) exists
This ensures that a relatively compact name is always available
I may be missing some obvious customary names, e.g., is "Eclipse
1.0" customary? For now I've used the SPDX ID, EPL-1.0.
- primarily functional
- drop self-naming
- minimize requiring significant understanding of other licenses or
copyright
- should be excruciatingly bland for anyone who already knows the licenses
well; newcomers shouldn't have to deal with baggage immediately
Probably a few more words should be added to the xGPLv3s about their
stronger patent terms.
Licenses not listed on /licenses could be described in similar style.
There's a strong argument they have implied patent licenses, but
this site doesn't annotate any other implied patent licenses, as
one would expect given the description of the patent-use field "This
license provides an express grant of patent rights from the contributor
to the recipient."
- remove descrption of v2 v3 difference
- add to description v3 express patent grant
- update example projects to only include v3 ones
- move v2 projects to gplv2 license using property
partially addresses feedback in #335
and are structured
grant (permissions)
conditioned on (conditions)
with limitations
Permissions coming first combats mistaken but apparently widespread
impression that licenses impose conditions, even such that without
a license, there would be no conditions/work would be in the public
domain.
Requirements->Conditions emphasizes that they are pertinent if one
wants to take advantage of permissions.
Forbiddens->Limitations is more accurate: in most cases licenses
don't give permission to hold licensors liable, in some cases to
use licensors' trademarks or patents, but a licensee does not lose
the permissions granted by the license if the licensee holds licensor
liable, etc. Also emphasizes that there are limitatations on the
license grant, not that the license imposes prohibitions.
The most concise place to see both the rename and reorder is in
_includes/license-overview.html
I did not reorder the appearance of the groups of properties in
license source files (.txt files in _licenses) as those orderings
are not used to render anything on the webiste. Might do so later.
- don't require knowledge of 'new' or 'simplified' relative to *what*
- rm nickname for BSD 3-clause Clear License which is hidden and
deserves to remain little known
The last meaningful change to this tag was c4c48d49 (Change nonstatic
to library usage, 2013-07-10), but I'm not sure where that discussion
happened. In any case, that commit changed some "must" wording to
"may" wording, which seems like it should move the label from required
to permitted. However, a library-usage permission would also apply to
many other licenses (e.g. folks are free to link MIT-licensed work
from a proprietary program), and adding library-usage to almost all
the licenses seems like the wrong way to make this distinction [1].
The limitations that the LGPL and OSL place on disclose-source scoping
are already covered in the disclose-source description, so the
library-usage label doesn't seem to be adding anything meaningful.
The OSL gets at this distinction by tightly scoping derivative works
[2], and the LGPL talks about combined works as a special subset of
derivative works [3,4]. The MPL makes a similar distinction between
"Covered Software" and "Larger Work" [5], and the EPL makes a similar
distinction between "derivative works" and "the Program" [6]. Whether
the location of those distinctions, or the requirements placed on
combined works can be neatly summarized in a boolean label remains to
be seen, but we're pretty sure that library-usage is not that label
[7].
Subsequent commits may replace the caveat in the disclose-source
description with wording in the license description themselves or by
adding a new label that summarizes the issue. Until then, the
disclose-source description more clearly covers the information that
library-usage was intended to convey, so this commit removes the
less-clear label to avoid redundancy.
[1]: https://github.com/github/choosealicense.com/pull/343#issuecomment-179532710
[2]: http://rosenlaw.com/OSL3.0-explained.htm#_Toc187293087
[3]: https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html
[4]: https://www.gnu.org/licenses/lgpl.html
[5]: https://www.mozilla.org/en-US/MPL/2.0/
[6]: http://www.eclipse.org/legal/epl-v10.html
[7]: https://github.com/github/choosealicense.com/pull/343#issuecomment-179557468
non-grant of trademark rights.
Generalize description of trademark a bit to 'or' include other
marks, as some licenses include others, though trademark the only
universal among such licenses.
The GPL v3 is an improvement over v2 fixing several issues and
increasing compatibility with other free software licenses. As such
there is no reason to feature v2 prominently rather than v3. See
http://www.gnu.org/licenses/rms-why-gplv3.en.html for more rationale.
Per the discussion in #168, the consumers of the softare are granted the right to use patents. So "Patent Use" makes more sense from a consumer perspective than "Patent Grant".
From Section 10:
> Each time you convey a covered work, the recipient automatically
> receives a license from the original licensors, to run, modify and
> propagate that work, subject to this License.
Sublicensing is technically forbidden, but the copyleft makes the ability to sublicense irrelevant.
Properties are now consistently sorted across all license files,
appearing in the following order:
**title**
nickname
tab-slug
redirect_from
category
variant
featured
hidden
**source**
**description**
**how**
note
using
**required**
**permitted**
**forbidden**
The LGPL v3 does not include the boilerplate notice. One should use a modified variant of the boilerplate notice at the end of GPL v3, see https://www.gnu.org/licenses/gpl-howto.en.html
> When using the Lesser GPL, insert the word “Lesser” before “General” in all three places. When using the GNU AGPL, insert the word “Affero” before “General” in all three places.
