Static library archived in release assets

[coyzeng]

Description

OCCT compile is very heavy. How about support multi platform static library in release archive assets by github workflows.

Use Case

Integrating static library easily with ABI without install with package manage tools.

Benefits

Multi platform static library can be more easy to integrate with different program languages.

Additional Context

No response

[dpasukhi]

Hello @coyzeng.
Thank you for your suggestion.
I have a question about a benefit "easy to integrate with different program languages". What do you mean?
Usually dynamic easy to integrate with PInvokes or c call backs to dynamic library
_
As for a static release build, OCCT have LGPL 2.1. License and can NOT be linked to the commercial(private) code with static linking. That is why delivery is dynamic. Only open source solutions use static linking or at least only open sourced modules.

[gsegon]

Hello @dpasukhi,

With respect to LGPL2.1., to my knowledge, it is allowed to statically link LGPL2.1 library to a commercial(private) application with static linking provided that you also provide a way for your users to modify/exchange the LGPL2.1 part (in this case the library) and be able to re-link it back to your application ("work that uses the library", i.e. the "commercial" part). Practically this means that object code of the commercial part must be provided.

In terms on software freedom, nothing is lost if it is linked either statically or dynamically. Linking dynamically however implicitly enforced the ability for the users to modify/exchange the library (LGPL2.1. parts), as required by the LGPL2.1 license and there is no extra step to provide the object code of the application when distributing.

References:
[0] https://dev.opencascade.org/resources/licensing, Section 5, Section 6, Open CASCADE Exception
[1] https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic

I did a bit of research on this, and this is how I understand it. Please correct me if I'm wrong though.

Best regards!

[dpasukhi]

Dear @gsegon

Thank you for your explanation and references!

To clarify, for applications targeting WebAssembly, Windows or Linux, LGPL 2.1 compliance with static linking presents challenges. In WASM, everything is typically bundled into a single binary, making it impractical to allow users to modify and re-link the LGPL-licensed library. For desktop applications, static linking is allowed only if object files (or equivalent) are provided to the end user, which can be complex to manage for proprietary software. Dynamic linking remains the preferred option to meet LGPL 2.1 requirements without additional steps.

For commercial SDKs that include OCCT, the situation is slightly different. A commercial SDK can indeed statically link OCCT and be delivered to customers, but the end user of that SDK remains subject to LGPL 2.1 limitations. If the SDK user statically links the library into their final application, they must comply with LGPL 2.1 (e.g., providing object files or dynamic linking).

It’s worth mentioning that OCCT offers the option to purchase an LGPL 2.1 exception, allowing static linking in proprietary applications without requiring compliance with the LGPL static linking requirements.

Best regards,
Dmitrii.

[gsegon]

@dpasukhi Thanks for the quick and thorough response, much appreciated!