List all licenses in _licenses at bottom of /licenses (or /about?) for discoverability

[mlinksva]

I believe this has been suggested multiple times but the latest is #386 (comment)

This would simply be a list of links rather than an inline description of each license as done for select licenses on /licenses

[benbalter]

Are you suggesting we also list the hidden licenses? How does that fulfill the site goal:

Not comprehensive. Seems like an odd goal, but there are a bajillion licenses out there. We're going to have to filter that down to a small list of those that matter.

[mlinksva]

Yes, I am suggesting that. The filter happens mostly in presentation:

• only 3 on home page
• several more on /licenses
• the rest (that pass our criteria for adding to the repo, not all licenses) in some less visible but still discoverable on the web place

If licenses not on the home page or /licenses aren't ever going to be discoverable from the site anywhere, it seems we should tighten up the criteria for adding to the repo considerably, and delete a few licenses (and how I would love to delete the BSD-3 "Clear" license).

Now I recall where more or less this exact discussion happened before #320 (comment)

[ionas]

What about making it mostly/more a single page rather than a linked one. No reason to have so many sub pages aside hiding reasonable options.

Choose an open source license

{ Which of the following best describes your situation? }

CURRENT CONTENT

{ I want more choices } { What if none of these work for me? }

• Insert http://choosealicense.com/licenses/
• Still not found what you are looking for. See more (the rest)

{ My project isn’t software }

• Insert http://choosealicense.com/non-software

{ I don't want to chose a license }

• Insert http://choosealicense.com/no-license

[mlinksva]

A single page version of choosealicense.com would merit a bit more design than just stacking the current material, but it's something I'm thinking about.

[Kwpolska]

Also, where are all the licenses now? Why are BSD licenses and others hidden?

[ionas]

@Kwpolska there are already two licenses placed very prominently[1] that allow free-riding listed (MIT and Apache 2.0) - what would BSD offer over those?

However I did suggest to make it a single page (e.g. {I want more choices}), that would re-list many licenses like AGPL3, LGPL2, BSD, and others.

[1]: I'd swap Apache with GPL2 IMHO, to make that unbalance more even, just the positions... or add AGPL3 and GPL2 as those are the most interesting GPL licenses IMHO to have a 2x2 grid.

[benbalter]

Just a bit of context, on the historic vision, in case it's helpful, when the concept of hidden licenses was introduced, the idea was that for say, 60% of developers, they'd land on choosealicense.com and one of the three licenses on the home page would suit their needs, without having to drudge through an infinite list of licenses permutations. The idea was to demystifying licensing bike minimizing the risk of paralysis by choice. For the remaining, say 20%, we could have the next, 5-10 most popular licenses, but again, striving to satisfy for the vast majority (~80%) of use cases.

That's the philosophical difference between something like say, TLDR Legal. We can include more licenses on the home page, or on /licenses but for every license we add to get that 80% up to 81% or 82%, not only are there diminishing returns, but we actively harm our primary goal of demystifying license choices for the most common use cases (of which, those three licenses, or if need be, 5-10, should satisfy). If at the bottom of the page there's a "but this could be the wrong choice, make sure you don't want one of these other licenses first" button, developers are going to click it.

Hidden licenses came about as a means of solving two secondary use cases, arising out of license detection on GitHub.com:

1. Licensee (the tool we use to detect licenses of open source projects), relies on the licenses within choosealicense.com as the canonical license text. We wanted to keep things in the same place while increasing the number of licenses detected. For this use case, we don't gain anything by having a list of licenses on /licenses.
2. Once detected, we may want to link a code consumer (note: not a code publisher), to a single page, where they can learn what they can and can't do with a license. Again, if you're either googling "What can I Do with the MIT license" or getting linked from someplace in the GitHub UI or API, having that long list doesn't help you, because you only care about what you can do with that one license.

It's always going to easier (and more fun) to add Yet Another License, or to increase the visibility of the long tail of licenses (after all, pixels are free, right?), but the real challenge is nailing the experience for the vast majority of (aspiring) developers, the ones who most need our help, and the ones, for which, increasing the number of licenses accessible by navigating around choosealicense.com (a purposeful design choice), would arguable hinder the most.

[ionas]

Except that I don't agree. Reducing choice-in-your-face is not demystification but exactly(!) the opposite. It is mystification. The nature of things IS complex. Tiny differences may make you reconsider. Differentiating between so called "power users" and "edge cases" and "mainstream" is a strategy of mystification, already.

The article you linked shows that its not about demystification but about making choices for users ahead. That's like me saying: I like the AGPL because of a, b, c, and because of that I don't see much reason to present anything else (disclaimer: for the most part I don't) - so... I'll just show that. That is not demystification. It hides information to make educated guesses and choices about things. I'd rather explain what a feature is (say no-liability, say open-source, say share-back-enforcement, etc) and then someone can decide based upon that.

Hiding options has much more to do with marketing/education than with demystification. Demystification means you understand the array of factors to grasp the whole picture without a teacher telling you the truth (me telling you that the AGPL is all you want, after all).

Because of that, I do encourage you to read my suggestion again. A single page that is structured in an easy to complex way will make sure that those that can't stand 3 lines of consecutive text still get the basic picture of (F)(L)OSS licenses. The SP(A) should add more complexity down the line... eh page.

If you want to demystify, then having a filterable list/table/grid would be cool where you can filter by certain conditions in certain contexts. Something to help you make YOUR choice instead of eating the choice made for you - something that helps discovering options - a tool to one's disposal.

Think about the Foundation and TWBS customization pages. You click some stuff and filter some things and will get (a list/grid/table of) license(s).

[ionas]

So this would be my updated suggestion:

Choose an open source license

{ Which of the following best describes your situation? }

CURRENT CONTENT

{ Couldn't find what you are looking for? Select something that fits: }

FILTERABLE GRID/LIST (think Foundation / TWBS customization page)

{ My project isn’t software }

• Insert http://choosealicense.com/non-software

{ I want more choices } { What if none of these work for me? }

• Insert http://choosealicense.com/licenses/ HERE
• Still not found what you are looking for. See more (the rest)

{ I don't want to chose a license }

• Insert http://choosealicense.com/no-license

By doing so you can CTRL+F on one page. A screen reader can read all headers easily and you can jump to those sections and continue reading.

The single license pages are a good idea but should only be linked to show a summary per page (like the CC pages) and possibly link to license feature pages (where a feature is explained thoroughly, those features could be linked from the license grid filter suggested above)

[Kwpolska]

👍 for the above. Right now, the page shows 7 choices, three of which are variants of the GPL license, which stifles innovation and leads to wheel reinvention through limiting the use of all the open source software that chose the GPL license outside of code that uses a license approved by some weird RMS guy and his foundation (that certainly does not sound like freedom to me!)

The current site ignores a lot of choices — the BSD family of licenses, the Artistic License, or the ultra-permissive WTFPL, for example. It’s supposed to be “Non-judgmental” (or so claims the description), and yet it seems to push GPL and its variants above other licenses.

Also, what the hell is Unlicense? It seems to be problematic in some jurisdictions and much less popular than other licenses, even by a simple Google results count.

[mlinksva]

/ starts with permissive, /licenses starts with copyleft, together they're a compromise, see #386 (comment)

I find it humorous that @ionas who thinks AGPLv3 is what one wants, and @Kwpolska who thinks copyleft stifles innovation agree that showing all licenses on the single/home page would be a good thing. Frankly neither of you are in the target audience for choosealicense.com, nor is anyone who is likely to contribute to its development (thanks for your contributions).

understand the array of factors to grasp the whole picture

That's what / and with additional granularity /licenses attempts. There are lots of other licenses that don't differ substantially enough from those listed to make the additional details helpful for understanding the big picture, which is that there's a range of licenses offering degrees of freedom and protection.

It'll probably satisfy nobody, but I made an /appendix page listing all of the licenses cataloged in this repo, linked from the /about page. See #406

[Kwpolska]

I find it humorous that @ionas who thinks AGPLv3 is what one wants, and @Kwpolska who thinks copyleft stifles innovation agree that showing all licenses on the single/home page would be a good thing.

Which is exactly the reason for our request: my beliefs are different than yours or @ionas’s, or any other software developer’s. You should showcase all options and let people decide from themselves.

If I were building an opinionated pickALicenseApprovedBy.chriswarrick.com (not a real place), I would definitely add a lot of GPL copyleft criticism. But I’d rather build a site that showcases every possible option (out of the popular ones) in a fair way, and that has no bias.

[ionas]

Well, while I don't agree on the innovation rhetorics and would claim its the opposite way long term, twofold:

A) @Kwpolska and me are maybe on the same page because we prefer demystification, choice and considerations over just taking what you get.

B) Also I don't agree at the whole concept of 'target audience' as pointed out earlier. 'target audience' judges upon groups made up by you/us for what they might want to chose instead of helping them with tools, filters, categories and as-neutral-as-possible description of single features so that a well informed choice can be made.

Then... As for contribution, while these are only static pages (aren't they) there is a complex build process making it harder. It is not like you want me to create an sqlite based (for instance) filtering app that goes towards a database. That's however something I'd consider of high value for a site/an "app" like choosealicense.com.

If you, however, want me to fork, figure out how to re-arrange the homepage to fit #388 (comment) and add a PR. Let me know and I can give it a try (despite not really knowing the tech stack you are using... for a static site).