Same identifier (BSD) used for two different licenses.

[fabacab]

There is currently some ambiguity in the licenses marked as BSD; they might either be the FreeBSD License or the BSD 2-Clause or BSD 3-Clause licenses. Further, there are two line-items in the List of Licenses section with the same identifier (BSD). These should be disambiguated more clearly by using the SPDX short-identifier string for the appropriate license.

See also #1268 for a related issue about using SPDX identifiers for consistently.

[nodiscc]

@meitar I have merged FreeBSD/BSD-2/3-clause licenses under a single naming BSD. (05b4ab4) This doesn't respect the SPDX identifier conventions, but we have no track record of which project uses which one; anyway the license tag should only be used as an indication, users should read the actual license terms of the program they want to use. This alos reduces complexity in the license list, and makes contributing easier (just label it BSD).

I am aware of the differences between these licenses, but I don't think it's worth the maintenance cost and added complexity to make a distinction between them here.

Please let me know if you think otherwise.

[fabacab]

I don't think it's worth the maintenance cost and added complexity to make a distinction between them here.

I disagree. This is really not a difficult problem to solve? And it is better to iteratively improve the current list than to keep sweeping these issues under the rug, isn't it?

Also, you cite the following as a reason not to do this right now:

we have no track record of which project uses which one [license]

But in reality, we don't have to wonder what the licenses are. GitHub, among other tools, will just tell us if we ask. For instance, here are a couple Bash loops that will automatically correct all the BSD tags for projects that contain a LICENSE file on their GitHub source repository to the more specific ones listed by the SPDX identifier that GitHub displays on their GitHub project homepages:

# Read out all the projects labeled BSD in the awesome list, and grab their GitHub source URL.
for url in $(grep \`BSD\` README.md | grep -ioE "Source Code]\(https://github.com/.*)" | tr -d ')' | cut -d ':' -f 2); do
    # For each listed project, ask GitHub what it thinks the License is; GitHub uses SPDX short-identifiers.
    for i in "$(curl --silent https:$url | grep -E "  0?BSD(-[234PS])?" | \
        sed -e "s/^/$(echo -n $url | sed -e 's/\//\\\//g')/" | tr -s ' ')";
    do
        # Now we can just batch-replace our readme file by editing it in-place.
        sed -i'' -e "/$(echo -n $i | cut -d ' ' -f 1 | sed -e 's/\//\\\//g')/s/\`BSD\`/\`$(echo -n $i | cut -d ' ' -f 2)\`/" README.md
    done;
done;

I've just opened PR #1278, which is nothing more than the diff generated by running the above shell command and adding the new license identifiers into the list of licenses at the bottom of this file. I'm sure other tools are able to do this programmatically, too. This was just a quickie.

Moreover, it's (obviously?) better to iteratively improve the awesome list even if it's not perfect right now than it is to keep things broken just because we can't instantaneously correct all the items at once? And once cleaned, there is zero additional maintenance cost, because new additions will just use the correct identifier, saving us the trouble from this process in the futrue, because we've done it correctly the first time.

TL;DR: Merging the licenses and willfully retaining the ambiguity feels like a kludge, to me. I don't think it's a good idea. Plus, some of this work, has also already been done, and ignoring that just means you're going to eventually have to do the same work all over again, but it will be even harder because there will be more items in the list. I think you think this merging is going to save you time and work, but it's not. It's just deferring work that will be harder to accomplish later.

On a personal note, all the above said, I'm happy to do my own thing in my own fork if this approach seems unreasonable to you. You can always pull from my fork if you want. ¯\_(ツ)_/¯ I'll leave the above-linked PR for your review, but moving forward I'm not going to keep advocating for what I think are substantially better maintenance methods and approaches to iterative improvement if I keep feeling like each time I do so I need to justify my thinking to you. :\

I propose that this issue remain open to track the progress of the remainder of the ambiguously defined BSD licensed projects, of which there are exactly this many remaining as of this writing:

$ grep '\`BSD\`' README.md | wc -l
      26

This is down from 43 ambiguous instances. In one fell swoop that took about 15 minutes of my time, we are able to cut this down almost by half. That's why I don't believe this is really a difficult or complex maintenance burden, as you suggest it might be.

[nodiscc]

$ grep '\`BSD\`' README.md