Skip to content

License compatibility and suggesting outbound #77

Description

@hesa

In the source code, one can read "We need to run flict as subprocess as usage as library is too complicated"..... and, as the main author, I agree 💯. I appreciate you use the word "complicated" :)

Flict relies on OSADL's license matrix, which is dealing with snippets. There are other license resources to use than just OSADL's (e.g. https://github.com/osslab-pku/RecLicense, https://gitlab.com/hermine-project/hermine-data and the work in progress https://gitlab.com/automated-foss-license-compliance/) for other use cases (than snippets).

There is a new tool, https://github.com/hesa/licomp-toolkit, which wraps these resources and takes into concern things like:

  • how do you provide your software to your customer (REST api, binary, web ui, ....)?
  • how you use your software (link to it, stand-alone tool ...)?
  • have you modified the component?

So I think a switch to using licomp-toolkit both will be easier and more flexible.

Let's go back to looking at your tool. The functions (in https://github.com/OpenRailAssociation/compliance-assistant/blob/main/complassist/_flict.py) I find are:

  • flict_simplify_license
  • flict_simplify_license_list
  • flict_outbound_candidate

Are these your "only" use of flict?

Is there any other feature you would like to see in a tool?

If you would consider switching to licomp-toolkit, which I strongly suggest, I will of course help you out.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions