It is not possible to specify whether binary or source code export is allowed.

[niklwors]

SEMLA does not support the license annotation of 18.9.2 to define whether binary or source export is possible.

record License
   String licensee = "" " Optional string to show information about the licensee ";
   String id [:] " Unique machine identifications , e.g.\ MAC addresses ";
   String features [:] = fill ("", 0) " Activated library license features ";
   String startDate = "" " Optional start date in UTCformat YYYY -MM -DD";
   String expirationDate = "" " Optional expiration date in UTCformat YYYY -MM -DD";
   String operations [:] = fill ("", 0) " Library usage conditions ";
end License ;

You wrote:

SEMLA does not support the license annotation of 18.9.2 to define whether binary or source export is possible.

If I understand you correctly, what you want to do is to add support in SEMLA for interpreting a license file.
Specifically, the operations annotation: String operations[:] = fill("", 0) "Library usage conditions";
to define whether binary or source export is possible.

A design decision for the default SEMLA implementation is that it does not require the license manager to interpret anything in the Modelica code. It is expected that the Protection annotation is processed by the tool.

For context, here is the relevant section of the spec (https://specification.modelica.org/maint/3.6/annotations.html#licensing).

SEMLA already supports protecting classes using a tool specific license manager.
I do not think it is necessary to also add support in SEMLA for interpreting a license file, assuming that the tool interprets the Protection annotation and license file.

The Library Vendor trusts the tool, and the tool needs to do certain checks to ensure that classess are protected.

[niklwors]

But this does not explain how the Modelica tool can know whether it is allowed to export code for a Model in an encrypted library, e.g. a source code FMU. Or how do you think this could be solved?

[niklwors]

@axelmartenssonmodelon this is the part of the specification that I meant

The format of the strings used for libraryKey and id are not specified (they are vendor specific). The libraryKey is a secret of the library developer. 
The operations define the usage conditions and the following are default names:
-    "ExportBinary" Binary code generated from the Modelica code of the library can be included in binaries produced by a simulation tool.
-    "ExportSource" Source code generated from the Modelica code of the library can be included in sources produced by a simulation tool.

To know whether binary or source code export is allowed, a tool could ask the LVE for the license file.
It is the responsibility of the tool to interpret the license file, from the SEMLA perspective, it is encrypted/decrypted like any other Modelica file.

If this license file is to be used in SEMLA it must have the extension ".mo" (not ".mo_lic" which the example in the Modelica spec has), because it is only files with the ".mo" extension that get encrypted.

[hubertus65]

In my interpretation, this is an OpenModelica issue. I would also say that the 2 issues are different. A library can be encrypted, e.g. to inhibit editing, but still have a liberal license. From that point of view, the OpenModelica decision is correct. Since OpenModelica has no license manager, it has to do it this way. So I think that @axelmartenssonmodelon is correct in that this is not necessary to do in SEMLA.

[hubertus65]

@iakovn will provide comment after reading the specification again. The OpenModelica default is that no FMU export is allowed by default if nothing is said. Currently nothing is specified about code obfuscation for any export.

[iakovn]

@niklwors, @hubertus65, here’s my interpretation:

Given the current framework and specifications (per Axel’s comment above), the library vendor will need to provide a separate package that includes annotations as per Modelica Specification 3.6, section 18.9.2 Licensing:

• A protection annotation in package.mo, for example:

  annotation(Protection(features={"MyLibraryWithBinaryExport"}, License(licenseFile="Operations.mo")));

• An encrypted Operations.mo file as a part of the library containing:

  package Operations
    annotation(Authorization(license={License(operations={"ExportBinary"})}));
  end Operations;

The Modelica tool (compiler) implementing support for the relevant operations and the License annotation would then need to request the Operations.mo file before proceeding with the operations and parse out the annotation.

An alternative approach could be to extend the SEMLA framework with an "OPERATION" request, which would be processed by the license manager similarly to the "FEATURE" request and return YES/NO based on whether the specific operation is permitted. This seconds approach might be more straight-forward both for library and tool vendors.

[hubertus65]

@iakovn, that sounds like a proposal. Let's take a local poll here in the group about the above. Pleas add the emoji corresponding to your choice below:

• 👌 for Iakov's proposal with the Operations.mo solution
• ❤ for adding an "OPERATION" request to the SEMLA spec.