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.
Based on feeedback from people looking for BSD licenses and wanting to
use site as a reference.
I'm not thrilled with any distraction from flow of choices that
work for most on home page through spectrum covering range of open
source licenses without redundant ones, but obviously some people
prefer seeing everything in a table, so let them find it, accommodate
use as reference and people whose learning style involes poring
over a reference rather than being guided.
I made some suggestions to this documentation today because I have been wondering about these ambiguities for years and am recently, trying to convince a repo maintainer to add a license to his repo which has over 1000 regular users; but this document (even the section: "Ask the maintainers nicely to add a license") offers nothing convincing to that end. In fact, it is barely self-consistent, and the GitHub TOS is so terse on the topic that it is not at all clear what this document implies specifically for GitHub users.
The one paragraph states that GitHub public repos are forkable (and actually download-able) regardless of the license or lack thereof. Then the very next paragraph states that without a license users may not use the material in ANY way. This avoids blatant contradiction only by omitting that, strictly speaking, without a license the rights do not exist to copy or fork either.
I hope this edit will serve to inform users until perhaps GitHub more clearly defines the limits of the permissions granted in section F1 of the TOS. Until then, I hope that the drafters of the GitHub TOS would read this PR mindfully and note that it raises some important issues.
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.
It may be relevant to add a link to SPDX as even though SPDX is referenced is many other places in the repo, it does not show up in the about.md.
That would a nice addition! (disclaimer: I am on of the SPDX co-founders)
