Add existing project situation, leave 1 permissive, 1 copyleft choice

[mlinksva]

This is a draft, probably will be controversial, definitely needs
wordsmithing.

Fixes #493 criticism of Apache-2.0 description on home page

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. Screenshot:

[waldyrious]

Overall I like this change. The only objection I'd raise is regarding the "feeling" language. I'd favor something that suggests at least a little analysis. The current headings ("I want it simple and permissive" / "I care about sharing improvements") work better, but something along those lines would work too (unless there's reason not to follow those lines).

[benbalter]

I'm contributing to an existing project?

I'm honestly a bit confused here. Can you talk through the user story, a bit, about how someone contributing to an existing project would land on choosealicense.com's home page and why?

I'm feeling reciprocal

If I'm creating my first open source project, how do I learn what that term means in this context? Should I have to? Can we demystify the legal jargon a bit more?

See #260 and the cross-linked issues for some more context here, this has come up a handful of times before.

[benbalter]

Why a lightbulb?

[mlinksva]

Because that's what the sprite includes now; it's a placeholder. If we go ahead with some version of this change, probably makes sense to change to some other graphic. Though a small part of me wants to insinuate that it's a bright idea to contribute to an existing project.

[waldyrious]

Probably a "community"/"group" icon would work well to illustrate this concept.

[mlinksva]

@waldyrious @benbalter thanks for your feedback!

"I'm feeling..." is definitely not great, probably worse than what's on the site now. I changed in order to try to get some better suggestions/or just motivate me to come up with something better. Happy to just stick with current language if nobody including me does. #260 and linked issues make some good points; when I have some time I'll try to synthesize.

Can you talk through the user story, a bit, about how someone contributing to an existing project would land on choosealicense.com's home page and why?

Good question. I have in mind a few cases:

1. User gets pointed to the site to learn about open source licensing rather than specifically at the point of choosing a license for their project. Contributing to existing projects is far more common than starting a new one, so put something prominent on the site relevant to the most common case. It's possible that nearly all visitors are linked from the (i) on github.com/new in which case this use case is not very relevant.
2. User wants to suggest a license for a project that isn't their own. First column in this PR has help for them. I really want to help this user be helpful, eventually to the point of New feature: Suggest license directly from site to third-party repository? #401 but admittedly I don't have a theory as to how this user gets to the site other than as a subset of (1).
3. User who is coming to the site to choose a license for their project. The existing project option is (or should be, with tweaking) educational for them -- how will others treat the license (or lack thereof) of their project, separate from the variations of permissions etc. It gives a sense of how licenses work end-to-end, without directly explaining that.
4. User who is coming to the site to choose a license for their project, part II. Tiny hint that their project may be part of an ecosystem with preferred licenses, without listing out those licenses in the main flow of the site.
5. User who doesn't actually need the site but feels good about it because they see the site is recommending what all experts recommend, to use the license of existing project/community. This user links to site creating more (1) users.

Criticism of any/all of above most welcome.

[benbalter]

I have in mind a few cases... User gets pointed to the site to learn about open source licensing rather than specifically at the point of choosing a license for their project... User wants to suggest a license for a project that isn't their own... User who doesn't actually need the site

I'd just caution, that if we want to be excellent at what we do, we can't be everything to everyone. We need to have a narrowly defined goal in mind and stick to it, and I don't think "open source licensing 101" is that, at least not as currently stated. "Anything added dilutes everything else" and all that.

Specifically, our stated goal is:

Our goal is to help you find a license

If we're shifting or expanding focus, that's fine (and healthy), but we should explicitly have that discussion, and update the goal's stated in the readme. Should we create a separate opensourcelicensing101.com? A suggestinganopensourcelicenseforsomeoneelsesproject.com? Probably not, but we should have the "what we're solving for" discussion, if that's changed, before we go about solving for use cases other than "I want to choose a license for my project".

It's possible that nearly all visitors are linked from the (i) on github.com/new in which case this use case is not very relevant.

I checked Google Analytics (let me know if you don't have/want access). The plurality of traffic (35%) is referral traffic, of which 75% comes from GitHub.com.

[mlinksva]

I'm going to revisit this after going over the project README and goals, just haven't gotten to that. In the meantime @Alhadis asked a relevant question at db18b5d#commitcomment-18104802

I may be reading far too into this, but is the word "concerned" used in the sense of "I'm interested in patenting my idea" or "I'm worried/anxious about somebody patenting my software and finding some way to sue me over my own creation"...?

Probably closer to the latter. For the usual case of patenting (to extract money from others using the idea), an open source license with an express patent grant is not what you want...unless you want to commit to not extracting money for use of that particular software. But if you're (generic "you") thinking of patenting, you're getting your licensing information from the wrong place - you actually do need an attorney. If you're concerned about another patent holder extracting money from you for your creation, an open source license with a patent grant gives protects you from one of the ways they could do this...

It's possible I've completely misconstrued the wording, but the FSF's description of the Expat license has me worried:

For substantial programs it is better to use the Apache 2.0 license since it blocks patent treachery.

Do they mean treachery from consumers of the software, patenting it against their author...? Or... the other way around?

...they probably have in mind any case in which a contributor to software (could be the main author, or any other contributor) holds patents that they can later use to extract money from other users or contributors. This behavior is commonplace in the development of standards - contribute to development of a standard ensuring that implementations will use your patented method that you don't tell anyone about, then collect money from everyone once they're depending on the standard - so many standards groups now require contributors to grant a license for any patents they hold to anyone for the purposes of implementing the standard. Patent grants from contributors to other contributors and users in open source licenses like Apache 2.0 are a translation of the standards patent peace mechanism to a particular software program. In neither the standards nor software case is anyone protected from patent holders who don't directly contribute to the standard or software, and thus haven't licensed their patents to implementors/contributors/users.

Another wrinkle is that while older open source software licenses don't mention patents, one can argue they have an implicit patent license. It's not clear to me that express open source patent licenses have made a big difference, as I wrote above: "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?" ... or if could still have happened under Apache-2.0, could not under GPLv3 (which has broader anti-patent-treachery provisions than Apache-2.0)?

Hopefully this explanation made some sense (and I'd love to be corrected where wrong). Whether it did or not (and especially if it did not) your question confirms my suspicion that someone new to open source licensing (someone coming to choosealicense.com, I imagine) shouldn't be asked to factor how open source licenses differently address patents into their choice of an open source license.

[Alhadis]

My impetus for asking is an idea I've been dwelling over for a while, which, were it to take off, would almost certainly be at risk of exploitation from a heartless corporate body. Some mixed answers regarding patentability convinced me that computer algorithms are a potential target for patents.

Would Expat shield a developer from something as, say, a corporation trying to "seize control" of a novel/unusual text-processing algorithm that proved extremely effective?

(The world would be a much nicer place if people weren't selfish, greedy, materialistic dicks. J/S)

[mlinksva]

@Alhadis "seize control" is too general to comment on. If you're concerned about an entity contributing to your project and then threatening you or other contributors or users with patents held by said entity, MIT/Expat might give you some shielding but you may as well use something with an explicit patent grant from contributors such as Apache-2.0, though if you're really worried and have such a world view you might feel better with LGPLv3 (or GPLv3 or AGPLv3 if patents aren't your only exploitation concern).

To bring this back to the changes proposed in this PR: why not make Apache-2.0 rather than MIT the default and sole permissive choice, given that one may as well give/get an explicit patent license from contributors? To more or less repeat what I wrote in the PR description, people seem to have a strong revealed preference for simplicity, and the systemic benefits of an explicit patent license have not been revealed through evidence I'm aware of.

[Alhadis]

Heh, from your tone, it sounds like I'm spewing a load of crap. That's the reality check I needed, because I feel I've probably been reading the wrong articles lately...

people seem to have a strong revealed preference for simplicity

I think the perceived simplicity of a license should also be taken into consideration, as well as the effective legal simplicity. Apache 2.0 isn't exactly terse, and I've seen an amusing number of licenses where the author hasn't even bothered signing off the bottom. Exempli gratia, and also look how long that's been sitting there for.

Conversely, the MIT license has the blanks-that-must-be-filled at the top of the file, and the entire body is reasonably easy to get through (the ISC license even more so).

[mlinksva]

You're actually not supposed to fill in the bottom of Apache-2.0, see #417 (comment) But yes confusion over this is an example of the cost of a relatively complex license. 😄

[adamvoss]

FWIW, I would rather not see the information about patents removed. I think it is an important issue that choosealicense.com currently helps educate about.

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

This is not a direct match, but shows how patent concerns can have negative community impact: I know some MIT licensed projects that were concerned about patents so required a CLA that granted patent rights to the controlling organization. An active contributor terminated their CLA making all un-merged pull requests unusable, the code was still published and MIT licensed but could not be merged because of patent concerns.

Perhaps there is a implicit grant, but there seem to be enough FUD on the subject that it seems safer to assume there is not.

[mlinksva]

patent concerns can have negative community impact

Indeed. 😄 So I doubt it is something someone new to open source licensing should be wracking their brains about. But there's not an objectively correct answer.

I know some MIT licensed projects that were concerned about patents so required a CLA that granted patent rights to the controlling organization. An active contributor terminated their CLA making all un-merged pull requests unusable, the code was still published and MIT licensed but could not be merged because of patent concerns.

If they're public and you recall, I'd be curious to read these interactions.

...

I do plan to come back to this PR, in case anyone's wondering why I'm keeping it open. I just noticed a semi-recent issue about the home page description of Apache-2.0 that it would also resolve that I somehow overlooked when it was filed: #493

[adamvoss]

@mlinksva I don't have much at easy access. I replied on gitter with what I could get at easily.

[apotheon]

I said this to @mlinksva elsewhere, but think it might be worth saying here:

There are things that could possibly be improved about this, but I believe it is, on the whole, an improvement over the state of the site's homepage as it is now, and should perhaps be wrapped up with whatever improvements can be decided and applied quickly for deployment in production. Further discussion about additional improvement can then be discussed as needed, and applied as they reach a state of acceptability.

I believe the desire for perfection in the long run should not stand in the way of improvement right now, especially when improvement right now does not prohibit or even delay long-term perfection.

[mlinksva]

Alright another take, emphasizing "community" over "existing" and reverting the "I'm feeling..." language:

The "community" icon I started from https://openclipart.org/detail/282576/about-icon
(CC0-1.0).

Some related motivation...

In a recent podcost at 43 minutes in Karl Fogel and James Vasile make very similar recommendations, roughly consider dependencies, community prevalence, [A]GPLv3 if you want copyleft, BSD-2-Clause (of course practically the same as MIT) if you want permissive.

On not putting the mind-melting subject of patents front and center for someone who just wants to choose an open source license:

• Curious that many entities that are concerned about patents continue to use MIT and similar; glad to see writing on one of the reasons https://opensource.com/article/18/3/patent-grant-mit-license
• Some of the ways one might be concerned have been somewhat mitigated over the last 10 years, one writeup
• Of course some communities strongly want to create a patent no fly zone and indeed anyone who wishes to participate should take their advice; that's covered here by fitting in with a community, rather than individual concern
• Even more of a tangent: looking forward to seeing how much traction UPL-1.0 gets (realizing significant changes in license adoption take many years)

Overall I'm not incredibly thrilled with this PR, but licenses are just an ugly topic, and I think this change better serves someone choosing an open source license without any existing background in the topic than the current home page does. In short: do consider the ecosystem for your project, don't bother thinking about patents.

[apotheon]

I feel like "I care about sharing improvements." does not exactly fit. It seems likely that people in both the other categories in that row of options would also "care about sharing improvements". I'm sorry if this seems nitpicky, but it seems imprecise and inaccurate as a description of a differentiating motive. Perhaps some variation on that language can be used, such as "I require others to share improvements."

[mlinksva]

Oh I agree, that's why I proposed "I'm feeling...permissive...reciprocal". Turns out the same nitpick made extensively in #51 but it seems closed due to no conclusion. I'm just going to go ahead and merge this now, feel free to comment on #51 if one of the suggestions made there seems compelling or if a better variation occurs to you!

[apotheon]

Thanks.