Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to add confidence tolerance to specific license #385

Closed
othree opened this issue Jun 27, 2019 · 4 comments · Fixed by #388
Closed

Ability to add confidence tolerance to specific license #385

othree opened this issue Jun 27, 2019 · 4 comments · Fixed by #388

Comments

@othree
Copy link
Contributor

othree commented Jun 27, 2019

Hi,

I am working on add Vim License to choosealicense and let GitHub can detect it. There is an issue I opened long ago. And I restart the work recently.

I have some discussion with Bram(author of Vim) about the license text. And confirms that the project name of the license text should modify when used on different project. I have created a license text file. You can see lots of [project] in the text.

For this reason. Current licensee can't detect Vim License. The exact matcher won't match because of [project] is different on different project. And the dice matcher also won't natch because of the CONFIDENCE_THRESHOLD is too high.

Now the threshold is 98(used to be 95). If I use Vim as [porject]. The similarity is 97.27% which is not over 98%. Also if the length delta of project name is to much. The license will not qualify as a potential_matches.

I found there are some special rule for specified licenses, such as creative commons and lgpl. So I think its acceptable to add one for Vim. I have some progress and confirms it can detect the Vim License Text used by Vim its self and some other projects which have longer project name.

I didn't send PR directly because I think this requires some discussion(and vim is not in choosealicense now). Or myabe its not ok from your point of view.

@benbalter
Copy link
Contributor

@othree thanks for the detailed and well thought out issue. Not terribly opposed to special casing vim temporarily. In the long run, It would be cool to explore using e.g., regex so that an exact matcher could be aware of where the fields are.

@mlinksva
Copy link
Contributor

mlinksva commented Jun 27, 2019

@othree relatedly https://github.com/spdx/license-list-XML/blob/master/src/Vim.xml doesn't account for any substitutions. We don't consume that directly (eventually I'd like to) but that's the best place to work out and mark up what textual variations are acceptable in a license. I'd like to see the substitutions you mention here documented by SPDX before cataloging them in choosealicense.com (assuming the Vim license might meet other criteria; I haven't investigated).

GitHub
This is the repository for the master files that comprise the SPDX License List - spdx/license-list-XML

@othree
Copy link
Contributor Author

othree commented Jun 28, 2019

@benbalter Not very sure about how to use regex for this. Are you thinking use regex to replace all the [project] part back to [project]?

In that case I think the major problem is how to get the project name. Repository name is not exactly the project name. Then there is no good place to get the project name as far as I know. Do you have any idea or I misunderstanding your suggestion.

@othree
Copy link
Contributor Author

othree commented Jun 28, 2019

@mlinksva Thanks, I will check the format and discuss with Bram. I believe it requires his permission before I can do any PR/issue/mail to SPDX.

As for other criteria, the only one I can't confirm is the 1000 project. The GitHub search can grab lots of results. But not all of them are expected(project using Vim License). Parts of the result are like personal vim config file. What I can confirm is at least 800 projects using Vim License:

I am not sure how you will decide in this case.

FYI, the account vim-scripts mirrors Vim Script from vim.org. And there are many Vim Scripts/Plugins live in the wild. Not listed at vim.org.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

3 participants