Generate json file compatible with "FSF License Metadata API"

[reversi-fun]

In order to make your data more reusable, please generate the file shown in the title.

"FSF License Metadata API" is defined in the following site. It is a convenient data format that can be reused. https://wking.github.io/fsf-api/licenses-full.json

That data format can associate the license identifiers with the catalog name and "tags". For example,

 {"licenses":{
    "apsl2": { /* fileName of choosealicense.com/_licenses/apsl2.txt  */
       "name": "Apple Public Source License",
         "identifiers": {
                "spdx": ["APSL-2.0"],
                "OSI" : ["Apple Public Source License"],
                "FSF" : ["FSF/apsl"]
                ]
            },
        "tags": [
        "libre"  /* FSF information*/,
                "patent-use" /* choosealicense information */
        ]
   }
 }

Please have a look at the data I made for a trial. https://github.com/reversi-fun/license_doc_similality1/blob/master/config/choosealicense-attrs.json

From this json data and the similarity of the license text, you can deduce the characteristics of the unknown license.

For example, SPDX / ODC-by-1.0 is not included in choosealicense, but it can be inferred that it has characteristics similar to SPDX / ODbl-1.0.

Please look at the attached figure. https://github.com/reversi-fun/license_doc_similality1/blob/master/data/lic_graph.sfdp.svg

[mlinksva]

Hi @reversi-fun I'm reluctant to add another data format which others might rely on without thinking through it a bit. The FSF API was created as a stop gap measure by @wking since the FSF doesn't have an easily machine readable version of their list, see https://github.com/wking/fsf-api

However, I welcome this issue because it got me thinking...I suspect it'd be entirely feasible to split out the license metadata from the license texts in this repo, having the metadata in separate data files. That would make using both the metadata and the license texts more trivial, no preprocessing needed. That need for preprocessing has been a minor annoyance for me many times. I'm going to play around with removing it, but no promise on quick turnaround.

[reversi-fun]

@mlinksva, Thanks to response. I seems that You want to implement it with license metadata in yoies own format. OK, I request the following for your license metadata:

• "Tags" list element is Attribute that defined by you or others.
  • not ["FSF/libre","choosealicense.com/patent-use"] , but ["libre","patent-use"]
• Ability to map one-to-many license names.
• Manage a namespace-qualified name that indicates the name of the organization to which the license name has been assigned.
  • There are several groups that manage more license names than SPDX license list.
    • at least OSI,FSF,calculate-Linux, scancode-toolkit
  • Able to distinguish between licenses of dissimilar articles that each organization has named, as {spdx/libpng,spdx/libpng-2.0,spdx/zlib,FSF/libpng}
  • determines the correspondence between the old SPDX license name that you are aware of and the new SPDX license name. (For example, "SPDX/GPL-2.0" is old and deprecated. Only "SPDX/GPL-2.0-only" or "SPDX/GPL-2.0-or-later" are correct names.) To that mapping, the analysis of the similarity of the license text, which is the output of my tool is useful.
    • "spdx/Zlib" -> "choosealicense.com-gh-pages/_licenses/zlib
    • "spdx/GPL-2.0-only" -> "choosealicense.com-gh-pages/_licenses/gpl-2.0"
    • "spdx/GPL-2.0-or-later" -> "choosealicense.com-gh-pages/_licenses/gpl-2.0-or-later" /new/ or "choosealicense.com-gh-pages/_licenses/gpl-2.0" -> ["spdx/GPL-2.0-only", "spdx/GPL-2.0-or-later"]