feat: added LGPL as a valid license

[jhdub23]

No description provided.

[RobPasMue]

LGPL cannot be accepted as a license by default - investigations need to be performed on the way the impacted package is used on our side.

[jgd10]

The ability to release Python libraries freely but NOT as fully OSS (aka Freeware) is desirable and there is at least one library that falls into this category at the moment within ansys and there could be more in the future.

[jhdub23]

Under what circumstances would an LGPL package X be permissible while an LGPL package Y be denied? For example: GPL - internal use only, allowed. Shipped within a closed-source product: not allowed.

I'm trying to understand the decision factors that would apply for us to deny the use of an LGPL package. I can't think of any, assuming the product team has ok'd the use of the package.

[jorgepiloto]

As far as I am concerned:

• We allow the use of free software for development
• We don't allow free software dependencies in our projects

The reason for the last point is that we would be force to distribute our software under a free software license.

[ansys-cla-bot]

All Contributor License Agreement (CLA) signatures have been captured successfully. Thanks for contributing!

[jhdub23]

As far as I am concerned:

• We allow the use of free software for development
• We don't allow free software dependencies in our projects

The reason for the last point is that we would be force to distribute our software under a free software license.

LGPL packages don't force us to distribute our software under a free software license. Also, software in the ansys org is already distributed as free; every repository has an MIT or equivalent license. That does NOT extent to components it uses (e.g. our proprietary code).

[jorgepiloto]

As discussed with @jhdub23, this should be fine. We are just using them as a dependencies. We are not modifying or copy-pasting their source code.

[RobPasMue]

As discussed with @jhdub23, this should be fine. We are just using them as a dependencies. We are not modifying or copy-pasting their source code.

If we end up allowing it, please revisit the https://github.com/ansys/actions/blob/main/check-licenses/ignored-packages.txt packages so that if any of them are LGPL, we can accept them

[da1910]

The main reason for my reservations here remains in place - we have downstream consumers of these packages who bundle them into executables using pyInstaller. In that context LGPL dependencies are almost certainly not going to be acceptable, and we've previously discussed at length the need to work with those teams.

Permitting LGPL components as strictly parts of the build or documentation process seems reasonable, but for any of the flagship libraries, hard dependencies on LGPL libraries will prevent this bundling, and impact those workflows.

This discriminated permission process is not supported by pip-licenses or by the existing workflows, and will require manual approval and tracking (which I remain convinced we should do)

[da1910]

Per yesterdays discussion this is reasonable - I would like to see the support policy written down somewhere, but we seem comfortable drawing a line around open-source.

We also discussed improving the reporting process for SBOMs which I'll take a swing at today.

[SMoraisAnsys]

After some thoughs, I would remove this checking tbh.
While I would like to ensure that every developer pays attention to direct/transitive dependencies' licenses, I don't think adding a step in our action is the right way. If one updates the whitelist-license-check input, then one should already take responsibility for this.

[jorgepiloto]

Everything works on my side. I thought to add this extra-step so that it forces developers to think twice about what they are doing.

[MaxJPRey]

Yes, that is a good point @SMoraisAnsys. You convinced me 😄

[RobPasMue]

Yeah the check is not needed as an action input. I thought we agreed on this yesterday. Modifying the whitelist acknowledges that you know what you are doing.

The bot comment as discussed is a good double-check though, but it has to be separate from the action itself