I always add my licenses manually (when I remember) and choose ISC, so I don’t really care either way.
But… I’d argue that the BSD license is older, better known, and probably more used than many of the ones they list. The whole point of the drop down was to make licensing convenient so more people would use one, so why not make the most popular licenses the easiest and most convenient to use?
It’s probably equally known as the main ones highlighted on the list (GPLv3, MIT, and Apache v2), but besides that, my guess is that whoever put together the initial version of the drop down assumed that the MIT and BSD are fairly similar, and adding more would just clutter the list.
Not that it’s a real defense. It also seems odd that the GPLv2 isn’t on the list, because of the number of people who’ve explicitly said they’ll use the v2 over v3 for new projects.
Redistribution of insubstantial portions would not be subject to copyright anyway. So there is no substantive difference between the licenses. GitHub is absolutely right to attempt to reduce license proliferation, and the MIT license is clearer and avoids the risk of confusion with the BSD 4-clause license.
Sure, but the linked GitHub comment doesn’t seem to care about the non-endorsement clause, it’s really focussing on the redistribution/attribution angle.
GitHub is absolutely right to attempt to reduce license proliferation
Sure, so they could have a list of suggested licenses for new projects and limit that to maybe 3 or 4, but at the same time allow you to specify any of the FSF/OSI approved licenses.
That’s what they do, isn’t it? If you go through the “quick start” process then you get their limited choice of licenses, but you are allowed to use any license by uploading it directly (and you grant a very limited set of additional permissions via their ToS).
The Haskell community as well, by and large, probably due to the similar academic-leaning demographics.
[Comment removed by author]
I always add my licenses manually (when I remember) and choose ISC, so I don’t really care either way.
But… I’d argue that the BSD license is older, better known, and probably more used than many of the ones they list. The whole point of the drop down was to make licensing convenient so more people would use one, so why not make the most popular licenses the easiest and most convenient to use?
It’s probably equally known as the main ones highlighted on the list (GPLv3, MIT, and Apache v2), but besides that, my guess is that whoever put together the initial version of the drop down assumed that the MIT and BSD are fairly similar, and adding more would just clutter the list.
Not that it’s a real defense. It also seems odd that the GPLv2 isn’t on the list, because of the number of people who’ve explicitly said they’ll use the v2 over v3 for new projects.
Redistribution of insubstantial portions would not be subject to copyright anyway. So there is no substantive difference between the licenses. GitHub is absolutely right to attempt to reduce license proliferation, and the MIT license is clearer and avoids the risk of confusion with the BSD 4-clause license.
What about the non-endorsement clause? Some universities care about this, eg. the UC system.
There’s nothing stopping someone from including their own license file over the preset ones that can be autogenerated for you.
Sure, but the linked GitHub comment doesn’t seem to care about the non-endorsement clause, it’s really focussing on the redistribution/attribution angle.
Sure, so they could have a list of suggested licenses for new projects and limit that to maybe 3 or 4, but at the same time allow you to specify any of the FSF/OSI approved licenses.
That’s what they do, isn’t it? If you go through the “quick start” process then you get their limited choice of licenses, but you are allowed to use any license by uploading it directly (and you grant a very limited set of additional permissions via their ToS).