- document criteria for whether a license is hidden
- needed for license spectrum on /licenses OR
- on 'popular' list at https://opensource.org/licenses (some other list could be used in the future)
- adjust license properties and tests accordingly
This gets non-hidden list back close to what it was before #386 and (pending licensee vendoring this change, licensee release, and github.com licensee dependency version bump) some commonly requested licenses (eg #413#449) will reappear in the github.com license drop-down.
* same-license is not a limitation and doesn't apply in any way to BSL-1.0
* other licenses with a per-file notice recommendation get that added to the note field
* have the description mention the reason for this license existing, binary distribution without notices (IIUC)
* remove using: pending an example that can be followed by others and detected eg on GitHub, see https://github.com/github/choosealicense.com/blob/gh-pages/README.md#optional-fields and see #358#372#377
This is a **draft**, probably will be controversial, definitely needs
wordsmithing.
Fixes#380 "No clear message on why to choose an open source license"
-- added line under heading
Fixes#335 "Feedback from John Sullivan talk on license choosers"
-- remaining items were (roughly) to not surface patents at this
level, and to surface choice between allowing proprirary/closed
source or not
Fixes#239 "Consider discussing ecosystems with an already predominant
license" (well, it doesn't *discuss* but there's a page for that,
unlinked til now) and makes the default recommendation of just about
everyone -- use exisitng project/community's license if applicable
-- prominent on the site
Closes#48 "Proposed modified workflow: make permissive/copyleft
and patents orthogonal" though probably not in way submitter would
favor. I could be convinced that Apache-2.0 should be featured
rather than MIT because of the former's express patent grant, but
as it stands I'm not sure the complexity of Apache-2.0 (and for a
weak grant, relative to GPLv3) is worth it relative to MIT. There's
some value in the first license a user looks at being really easy
to understand. The continued popularity of MIT and simialar ISC and
BSD-2/3 seems to indicate people want that simplicity. And where
are the holdups based on patents supposedly infringed by open source
projects under licenses without an express patent grant that could
not have happened had those projects been under Apache-2.0? Please
educate me! :)
Any and all feedback most welcome.
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."
