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

Semantics of UsagePatterns DYNAMIC_LINKING and STATIC_LINKING is unclear #260

Closed
ohecker opened this issue Apr 24, 2024 · 0 comments · Fixed by #261
Closed

Semantics of UsagePatterns DYNAMIC_LINKING and STATIC_LINKING is unclear #260

ohecker opened this issue Apr 24, 2024 · 0 comments · Fixed by #261
Labels
enhancement New feature or request

Comments

@ohecker
Copy link
Member

ohecker commented Apr 24, 2024

(This story replaces/superseeds #257.)

As a user of Solicitor I want to be sure that the semantics of the UsagePattern is clear so that no legal evaluation done based on the Solicitor data / rules is jeopardized by wrongly selected/understood UsagePattern settings.

The UsagePattern describes how a component is linked to the overall application executable. Besides STANDALONE_PRODUCT which is used if the component is not linked at all to other components there are currently two possible values:

  • STATIC_LINKING
  • DYNAMIC_LINKING

The terms static and dynamic linking have some technical/historical origin (statically linking libraries into an executable using a linker vs. dynamically linking to a shared library at runtime). The semantics in the context of more recent technologies (Java, Spring-Boot, Quarkus, Angular React, ...) is often not clear. Furthermore the semantics need always to be regarded with respect to the impact on the evaluation of OSS license compliance. So the focus needs to be "how does the usage pattern affect the licensing situation" - which might different from a mainly technical driven interpretation.

From the legal standpoint (impact on OSS license compliance) STATIC_LINKING and DYNAMIC_LINKING mainly describe whether it is possible to distinguish/separate/exchange the components within the executable or not.

Within this story the documentation (user guide) should be extended to describe the semantics of the different values of UsagePattern so that a common understanding is ensured.

AC:

  1. The user guide is extended towards the description of the different values of UsagePattern
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant