devonfw/solicitor

Semantics of UsagePattern DYNAMIC_LINKING is unclear and needs to be split to different values

Closed this issue · 1 comments

ohecker commented

(This story is not implemented and has been superseeded by #260)

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 semantics of STATIC_LINKING seems to be quite clear: The component is linked into the executable in a way that makes it (practically) impossible to separate it from the rest of the executable. In case that this single component needs to be replaced the linking process has to be re-executed based on the (unlinked) components. De facto this means that separating and/or exchanging the single components with only the executable at hand is practically impossible.

The semantics of DYNAMIC_LINKING is not that clear. At the core it means that linking is done at the moment when the executable is loaded into the main memory to be executed.

  • For native applications this might mean that the executable is dynamically linked to a shared library which might already be present on the system (*.so , .*dll)
  • On the other hand classical java always uses some form of dynamic linking - all class files are dynamically loaded/linked into the JVM when the program executes. But the details of the packaging/distribution/loading process might differ significantly depending on the used approach. This might have severe impact on the legal evaluation/usability/compatibility of/with specific OSS licenses.

So qualifying e.g. all java based executable as DYNAMIC_LINKING might result in wrong legal evaluation of license compliance.

To avoid this DYNAMIC_LINKING should be split/replaced by two different new values SEPARATED and EXCHANGEABLE. To possibly even better align wording with semantics STATIC_LINKING will be renamed to FIXED. This will then result in the following possible values for UsagePattern:

  • FIXED: The component is linked into the executable in a way that makes it (practically) impossible to separate it from the rest of the executable. In case that this single component needs to be replaced the linking process has to be re-executed based on the (unlinked) components. De facto this means that separating and/or exchanging the single components with only the executable at hand is practically impossible. .
  • EXCHANGEABLE: The component is included in the executable and is linked into the executable in a way that allows it to clearly distinguish it from the other components. It is possible to separate the component from the rest of the executable and to replace the component with a modified version of the component just using common tooling.
  • SEPARATED: The component is not included in the executable but is either already existing on the target system or is deployed separately from the executable. Exchanging the component can be done by exchanging the component without touching the executable / other components of the application.
  • STANDALONE_PRODUCT: The component is not linked to other components.

Using DYNAMIC_LINKING and STATIC_LINKING will be deprecated (and later the value will be removed).

AC:

  1. There exist three new values SEPARATED, EXCHANGEABLE and FIXED for the Enum UsagePattern.
  2. The values DYNAMIC_LINKING and STATIC_LINKING are still available, but any usage of it will issue a deprecation warning.
  3. Any configuration examples (in documentation or within generated default configs) use SEPARABLE_LINKING instead of DYNAMIC_LINKING (this might be the standard replacement. Using SHARED_LINKING possibly is limited to rare occasions). Usage of STATIC_LINKING is replaced by FIXED.
  4. The user guide includes a description of the semantics of the values. (Possibly reproducing the descriptions above.)
  5. There is no occurrence of value DYNAMIC_LINKING or STATIC_LINKING in any of the Solicitor sample rules.
  6. There is a hint in the user guide how to configure one application having components with different UsagePatterns (-> Create different input files for them and use two Readers with different UsagePattern configuration.)
ohecker commented

Whilst the original motivation of this story is valid, the solution to replace current values STATIC_LINKING and DYNAMIC_LINKING with three new values SEPARATED, EXCHANGEABLE and FIXED has the following drawbacks:

  • Effort in Solicitor code (and using projects) for migrating code/configuration and managing the deprecation procedure.
  • Introduction of new wording which requires motivation and explanation why this is necessary.
    Additionally the proposed value SEPARATEDprobably will be used very rarely, in pretty all cases the up to now used DYNAMIC_LINKING would be replaced by EXCHANGEABLE. So the practical value of "more fine grained classification" is very limited.

So to avoid effort and confusion the decision is to stick to the original values STATIC_LINKING, DYNAMIC_LINKING and STANDALONE_PRODUCT and to "simply" extend the documentation with respect to the semantics of these values.

This will be tracked in new story #260. Closing this story now.