search

modelica / ModelicaSpecification

Specification of the Modelica Language
https://specification.modelica.org
Creative Commons Attribution Share Alike 4.0 International
97 stars 41 forks source link

Suggestion for a standard for encryption, licensing and packeting of libraries #1868

Open modelica-trac-importer opened 5 years ago

modelica-trac-importer commented 5 years ago

Reported by jmattsson on 18 Dec 2015 17:04 UTC To enable proprietary Modelica libraries to be compatible with multiple tools, Modelon and Wolfram has worked together on a suggestion for a new standard for encryption, licensing and packeting of Modelica libraries. The suggested standard describes:

The suggested standard is described in the attached file "Licensing & Encryption v1.pdf".

Migrated-From: https://trac.modelica.org/Modelica/ticket/1868

modelica-trac-importer commented 5 years ago

Comment by beutlich on 18 Dec 2015 20:15 UTC See also #1282 for a previous discussion.

modelica-trac-importer commented 5 years ago

Comment by dag on 21 Dec 2015 10:56 UTC Based on your experience, what is the ECCN number of the library vendor executable? That is an important question as it could potentially affect our classification.

modelica-trac-importer commented 5 years ago

Comment by hubertus on 22 Dec 2015 15:26 UTC Dag, because Dymola already has the same type of encryption software embedded, it should have the same ECCN code already now. The ECCN number for encryption software is 5D002. This is probably rightly classified as "Cryptographic enabling software, 5D002.d. In any case, it would be strange if it changed the classification for Dymola, which has the same functionality today.

modelica-trac-importer commented 5 years ago

Comment by dag on 22 Dec 2015 21:01 UTC Hubertus, you maybe underestimate the complexity of this issue. We can only manage because we have dedicated experts in the field.

Dymola is not regarded as cryptographic software because it does not decrypt files with arbitrary encryption keys. On the contrary, every library encrypted by Dymola can be decrypted by any Dymola program, but you need a license key of course.

So I interpret your reply such that the library vendor executrable, if it supports encryption, would be 5D002. Next question: what does that mean with regards to export control and where/how you can sell your software?

modelica-trac-importer commented 5 years ago

Comment by hansolsson on 4 Jan 2016 17:20 UTC Regarding the non-encryption parts: I remember that this was discussed before, and one previous comment form #1152 was "if you want to distribute a Modelica library in one file, why not just zip the corresponding directory in the file system"?

Meaning:

I can see some reasons for having additional restrictions on the zipped directories, but not for having unique contents in the zip-archives.

For the encryption part I need to study it in more detail.

modelica-trac-importer commented 5 years ago

Comment by hansolsson on 5 Jan 2016 09:17 UTC I believe this supersedes #536 and #1152 (obviously the proposals are different), and would thus to close them as duplicates - and if necessary include relevant parts of that discussion (as I tried to do above).

modelica-trac-importer commented 5 years ago

Comment by pharman on 5 Jan 2016 10:04 UTC Replying to [comment:5 hansolsson]:

Regarding the non-encryption parts: I remember that this was discussed before, and one previous comment form #1152 was "if you want to distribute a Modelica library in one file, why not just zip the corresponding directory in the file system"?

Meaning: * Allow manifest files (etc) in Modelica directories * Specify that we can distribute a zipped version of one or more Modelica directories (as in this proposal)

This was proposed and discussed in #132, and a working implementation was shown at a design meeting in 2009.

Replying to [comment:6 hansolsson]:

I believe this supersedes #536 and #1152 (obviously the proposals are different), and would thus to close them as duplicates - and if necessary include relevant parts of that discussion (as I tried to do above).

The resource bundling described in #132 and #1152 does form part of this ticket, I don't think #536 does though.

modelica-trac-importer commented 5 years ago

Comment by hansolsson on 5 Jan 2016 12:41 UTC Replying to [comment:7 pharman]:

Replying to [comment:6 hansolsson]:

I believe this supersedes #536 and #1152 (obviously the proposals are different), and would thus to close them as duplicates - and if necessary include relevant parts of that discussion (as I tried to do above).

The resource bundling described in #132 and #1152 does form part of this ticket, I don't think #536 does though.

You are right that I should have included #132 (some parts of it were added earlier to the specification). Ticket #536 has some parts that are superseded by this ticket, and the other parts would need to be updated.

The reason I didn't find #132 is that we have many open tickets, and the idea with closing more or less duplicate tickets is to make it easier to find the relevant ones.

modelica-trac-importer commented 5 years ago

Comment by hansolsson on 25 Jan 2016 15:53 UTC Apart from the issue with export control and previous comments I see two items that could be improved with minimal effort:

Note that this addition doesn't create any new tool-vendor lockin - since the decryption executable already maintains a list of trusted tool-vendors.

I'm aware the "decryption executable" doesn't fully capture the licensing part of the executable, but I couldn't find a better name.

modelica-trac-importer commented 5 years ago

Comment by jmattsson on 27 Jan 2016 11:26 UTC Replying to [comment:5 hansolsson]:

Regarding the non-encryption parts: I remember that this was discussed before, and one previous comment form #1152 was "if you want to distribute a Modelica library in one file, why not just zip the corresponding directory in the file system"?

Meaning: * Allow manifest files (etc) in Modelica directories * Specify that we can distribute a zipped version of one or more Modelica directories (as in this proposal)

I can see some reasons for having additional restrictions on the zipped directories, but not for having unique contents in the zip-archives.

If I understand correctly, you want the additions described to be allowed both in the extracted and the zipped code? That is the intention in the proposal, and it is required that the zip file is extracted with all contents. I did not specifically write that the Modelica specification should be changed partly because it is my understanding that adding such a directory is currently allowed, and partly because I wanted this proposal to be usable without specification changes.

modelica-trac-importer commented 5 years ago

Comment by hansolsson on 27 Jan 2016 12:42 UTC Replying to [comment:10 jmattsson]:

If I understand correctly, you want the additions described to be allowed both in the extracted and the zipped code? That is the intention in the proposal,

Yes, and good that we agree on this.

and it is required that the zip file is extracted with all contents.

You are right the proposal requires this, and I didn't realize before - and it is not clear that this is desired.

As an example could a small library with thousands of resources such as png-files for the documentation, and a few tables. A tool could automatically unzip the images when needed and tables based on ModelicaServices.ExternalReferences.loadResource calls.

A manifest file additionally enable tools to find information (e.g. version information) without having to unzip and read other files (e.g. mo-files).

Thus I think we should consider removing this restriction, and instead state which parts must be unzipped to make the decryption work. Obviously the encrypted file and the executable itself, and as I understand also the directory of the executable - but do we need more?

I'm not certain that we will do a partial unzipping in Dymola (since disk-space and bandwidth is getting more plentiful), just that I think it would be good to consider - and I think it will be straightforward to specify if we do it early.

I did not specifically write that the Modelica specification should be changed partly because it is my understanding that adding such a directory is currently allowed, and partly because I wanted this proposal to be usable without specification changes.

It's true that it is allowed, and we can start supporting this without changes in the specification.

However, I still think this is something that should be in the specification.

modelica-trac-importer commented 5 years ago

Comment by jmattsson on 27 Jan 2016 13:08 UTC Replying to [comment:11 hansolsson]:

Thus I think we should consider removing this restriction, and instead state which parts must be unzipped to make the decryption work. Obviously the encrypted file and the executable itself, and as I understand also the directory of the executable - but do we need more?

That requirement is there to make the specification easier to understand and implement. If there is consensus for a more precise requirement, then I have no problem with that. My initial thought was that the decryption executable should read the encrypted files directly from the zip file, but we dropped that because we didn't want to require that it can handle both reading from the archive and from a directory structure. We thought that some tools might need to unzip the entire archive, thus requiring the decryption executable to handle that case as well.

It could work to simply require that the entire ".library" directory is unzipped before starting the decryption executable, plus that any file that is asked for with the FILE command must be unzipped (and in the correct place) before the command is sent. That would allow both tools that want to unzip everything at once and tools that want to unzip as little as possible, without making the decryption executable harder to implement.

It's true that it is allowed, and we can start supporting this without changes in the specification.

However, I still think this is something that should be in the specification.

My preference would also be to incorporate this into the Modelica specification. We just wanted to make it possible for it to work with the current spec.

modelica-trac-importer commented 5 years ago

Comment by dag on 19 Feb 2016 10:02 UTC I suggest we schedule a break-out session on this topic during the meeting in Linköping in March.

It would be great if one of the proposers could give a presentation of the complete scenario, not only the internals but the whole picture of distribution of libraries, licensing models, distribution of license keys, how it will be managed by the customer's organization, etc.

Export control is still an issue, so we need to discuss that too.

modelica-trac-importer commented 5 years ago

Comment by jmattsson on 19 Feb 2016 13:58 UTC Replying to [comment:13 dag]:

I suggest we schedule a break-out session on this topic during the meeting in Linköping in March.

I agree.

It would be great if one of the proposers could give a presentation of the complete scenario, not only the internals but the whole picture of distribution of libraries, licensing models, distribution of license keys, how it will be managed by the customer's organization, etc.

I'll prepare a presentation.

modelica-trac-importer commented 5 years ago

Comment by hansolsson on 7 Mar 2016 13:24 UTC One additional minor issue - it would be desirable that a tool could have more than one public/private SSL-key pairs. It wasn't clear that this is supported.

This just has a minor impact on the hand-shaking as far as I understand.

Two reasons:

modelica-trac-importer commented 5 years ago

Comment by hansolsson on 7 Mar 2016 14:11 UTC Note: The operations specified in Modelica spec (ExportSource and ExportBinary) are not handled - since they should be in the authorization-file; and the new format does not have an authorization file.

It can be handled in various ways: e.g. just having an authorization file encrypted in the library (seems redundant), or answering some specific query (so asking for "Operations" instead of "package.moc" - even if there is no "Operations" file).

The idea in the Modelica Spec is that ExportSource could be depend on the specific user; so if using an authorization file it would be different contents for different users - which is contrary to the goal of simple distribution of libraries.

modelica-trac-importer commented 5 years ago

Comment by otter on 7 Mar 2016 14:12 UTC More information on protection is provided in: IEEE Std 1364™-2005 IEEE Standard for Verilog® Hardware Description Language http://staff.ustc.edu.cn/~songch/download/IEEE.1364-2005.pdf(http://staff.ustc.edu.cn/%7Esongch/download/IEEE.1364-2005.pdf)

modelica-trac-importer commented 5 years ago

Modified by jmattsson on 8 Sep 2016 07:29 UTC

AndreasHofmann87 commented 5 years ago

Hello everyone,

Bosch Rexroth is very interested in a standardized encryption (tool-independent) for Modelica. I attached a file (draft) which compares the possibilities of VHDL-AMS (IEEE Std 1076.1-2017) and the Modelica specification 3.4 including the idea provided by Jesper Mattsson in this ticket. Maybe it can be a good starting points for further discussions, since also LTX GmbH is interested in a standardized encryption and licensing mechanism.

Best regards, Andreas

eric-Thomas-da commented 5 years ago

Hello everyone,

Note that I fully agree with this potential initiative :-) There are now many valuable tools supporting Modelica, used by several of our design partners. It would be a much more efficient way to exchange models than current FMI (which has many limitations vs Modelica), in particular with simulation of complex "physical" models (highly non-linear, with events, clocks ...) of natively acausal models (at boundaries ...) I have currently the issue, waiting desperately FMI 3.0 to solve partially the problem. A standardization of "encryption, licensing and packeting of libraries" would be much better.

Regards,

Eric Thomas

beutlich commented 5 years ago

Updated milestone.

DagBruck commented 5 years ago

Just a reminder that the issue about export control has not been resolved. Currently, a tool such as Dymola is not regarded as sensitive because it does not allow user-defined encryption keys (i.e. the .moe file is just a proprietary binary file format). Adding functionality that changes the export classification could have far-reaching consequences.

Question to other tool vendors: what is your analysis of the impact on export classification?

MartinOtter commented 5 years ago

I talked to a DLR lawyer. My understanding:

So, to summarize, the proposed approach seems to be uncritical with regards to EU export control regulations.

DagBruck commented 5 years ago

So, to summarize, the proposed approach seems to be uncritical with regards to EU export control regulations.

Maybe so, but that possibly does not help us because we also have to handle US legislation. Martin, could you check with your lawyer what applies when you export software to/from the USA?

henrikt-ma commented 5 years ago

The legal department at Wolfram Research in the US makes the same interpretation as Martin's DLR lawyer, that is, that the proposed design would also be OK with US laws.

Henrik

On 2018-11-12, at 12:33, Dag Brück notifications@github.com wrote:

So, to summarize, the proposed approach seems to be uncritical with regards to EU export control regulations.

Maybe so, but that possibly does not help us because we also have to handle US legislation. Martin, could you check with your lawyer what applies when you export software to/from the USA?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/modelica/ModelicaSpecification/issues/1868#issuecomment-437847766, or mute the thread https://github.com/notifications/unsubscribe-auth/AYH1P1Iu-ZEKOSrYImD5F3KCR51217ejks5uuVxxgaJpZM4YNXjw.

GallLeo commented 5 years ago

The legal department at Wolfram Research in the US makes the same interpretation as Martin's DLR lawyer, that is, that the proposed design would also be OK with US laws. Henrik

Dear Henrik, I'm not sure if I understood your message correctly: Are you saying, that there are similar exceptions for U.S. legistlation? Meaning, it would be OK to deliver the encryption/decryption tool together with the library?

henrikt-ma commented 5 years ago

Yes, the preliminary response based on the following brief summary is that it would be OK:

In the current proposal for the standard, the encryption of a Modelica library is handled by a binary that is distributed with the library. That is, SystemModeler wouldn't need to deal with encryption/decryption at all as long as the user is using libraries built by another software. The potentially sensitive part would be to allow SystemModeler to package a library with encryption, since SystemModeler would then need to both encrypt the library content, and also include a small binary for decryption inside the library package.

I take it as a preliminary response since it is only based on the brief summary above, and not based on a complete proposal which is in "under evaluation". Please indicate if there was any key aspect of the proposal that I forgot to mention.

Henrik

On 2018-11-19, at 12:06, Leo Gall notifications@github.com wrote:

The legal department at Wolfram Research in the US makes the same interpretation as Martin's DLR lawyer, that is, that the proposed design would also be OK with US laws. Henrik

Dear Henrik, I'm not sure if I understood your message correctly: Are you saying, that there are similar exceptions for U.S. legistlation? Meaning, it would be OK to deliver the encryption/decryption tool together with the library?

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/modelica/ModelicaSpecification/issues/1868#issuecomment-439855893, or mute the thread https://github.com/notifications/unsubscribe-auth/AYH1P5rHJjRC7-6coxwa2wE0FUyEHCSFks5uwpDLgaJpZM4YNXjw.

GallLeo commented 5 years ago

Thank you for the clarification. I really take this as an informal first information, as it would need to be checked by several lawyers, anyways.

So, do I interpret correctly, that the Library Vendor then needs to deal with the Export Control issues. A Modelica Tool would just act as an "importing" tool with an API and therefore does not have to worry about export control, as long as the library is not delivered bundled together with the Modelica tool?

jespermattsson commented 5 years ago

New revision of the proposal, mostly clarity changes and a couple of minor protocol tweaks: Specification_v1_r2.pdf When this was first presented, Hans asked for support for opening a library directly from a .mol file without extracting it first. I think that this is a good idea, but have not had time to finish incorporating it in the proposal.

As for the export control, I can only comment that there are several different kinds of encryption and decryption involved. Both the Modelica tool and the executable from the library vendor would be including an implementation of TLS. This is also true for every internet browser on the market. The executable from the library vendor would also include code to decrypt files with a hard-coded key.

Additionally, a Modelica tool could include functionality for encrypting user libraries. In this case there would be several different possible approaches for setting that up, that could have very different consequences for export control.

jespermattsson commented 5 years ago

I took a look at the Verilog link provided by Martin Otter, and while it is both rather general and flexible, it does require specific language support. In their case they use pragma, but in our case I guess we would specify annotations for that purpose. They define the encryption process using embedded directives in the source code. They require the receiving tool to handle decryption, and place licensing in a separate binary. I'm not clear on how the licensing binary is authenticated.

To use it we would still need to make some changes to make it fit into Modelica. To migrate any existing libraries into the resulting format would require adding annotations, probably to the top class of each Modelica file in the library.

GallLeo commented 5 years ago

Status from discussion at the 97th Modelica Design Meeting in Dresden:

Our presentation and use case documents are available here: https://svn.modelica.org/projects/ModelicaDesign/trunk/MeetingMinutesMaterial/min97_2018_Dresden/Slides-and-Documents/EncryptionLicensingLibraries

Based on the discussion, I see two options:

  1. Standardize Licensing, Encryption & Packaging (ideal solution for library "encryptor", because he only has to ship one build of the library)
  2. Standardize Licensing & Packaging, but leave encryption up to a tool (this means, the "encryptor" has to ship a separate library build for each target Modelica tool)

I clearly prefer option 1. in order to have to test and ship only one build of a library. Same probably holds for suppliers, which need to ship models to their OEM. They don't want to build many encrypted packages.

Todos:

HansOlsson commented 5 years ago

@GallLeo and Niklas Worschech please add requirements.

HansOlsson commented 4 years ago

Henrik: It's the library provider that "encrypts" - the tool vendors only need to be able to read it; the encryption seems the most problematic and can be outside this discussion. Eric Thomas: Might not need to encrypt all, could scramble as well. And might be only relevant for parts of the library. @jespermattsson do you have more information?

chrbertsch commented 4 years ago

This issues is very important for industrial usage of Modelica and Modelica-based tools and it slows down adoption in industry that we do not have an established solution yet.

The specification draft from above was extended by colleagues from Bosch Rexroth (Niklas Worschech) with industrial use cases: Specification_v1_plus_use_cases.docx

There is also a draft MCP at https://svn.modelica.org/projects/MCP/MAinternal/MCP-0029_LicenseExport/, which needs further update.

In the meantime, Modelon has published SEMLA under an open source license which implements for a great part the ideas mentioned in this ticket. https://github.com/modelon-community/SEMLA/blob/master/doc/SEMLA.md

If there are still concerns with US legislation: could the tool vendors please check the current proposals with their lawyers or propose alternative solutions that fulfill the requirements?

It would be good get broad feedback on this and bring this forward to a standardized solution supperted at the best in all Modelica-supporting tools.

@hubertus65 , @GallLeo, @DagBruck and others: Please comment on your view and the next steps. Thanks.

henrikt-ma commented 4 years ago

I totally agree that the standstill on these issues under the MA umbrella is very unfortunate. I wasn't even aware of SEMLA, but it looks like a possible explanation why the MCP hasn't got any attention lately.

As I recall it regarding US legislation, tool vendor lawyers have been consulted and nothing was found that was preventing us from proceeding with the proposal.

Henrik

On 2020-01-30, at 21:51, Christian Bertsch notifications@github.com wrote:

This issues is very important for industrial usage of Modelica and Modelica-based tools and it slows down adoption in industry that we do not have an established solution yet.

The specification draft from above was extended by colleagues from Bosch Rexroth (Niklas Worschech) with industrial use cases: Specification_v1_plus_use_cases.docx https://github.com/modelica/ModelicaSpecification/files/4136110/Specification_v1_plus_use_cases.docx There is also a draft MCP at https://svn.modelica.org/projects/MCP/MAinternal/MCP-0029_LicenseExport/ https://svn.modelica.org/projects/MCP/MAinternal/MCP-0029_LicenseExport/, which needs further update.

In the meantime, Modelon has published SEMLA under an open source license which implements for a great part the ideas mentioned in this ticket. https://github.com/modelon-community/SEMLA/blob/master/doc/SEMLA.md https://github.com/modelon-community/SEMLA/blob/master/doc/SEMLA.md If there are still concerns with US legislation: could the tool vendors please check the current proposals with their lawyers or propose alternative solutions that fulfill the requirements?

It would be good get broad feedback on this and bring this forward to a standardized solution supperted at the best in all Modelica-supporting tools.

@hubertus65 https://github.com/hubertus65 , @GallLeo https://github.com/GallLeo, @DagBruck https://github.com/DagBruck and others: Please comment on your view and the next steps. Thanks.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/modelica/ModelicaSpecification/issues/1868?email_source=notifications&email_token=AGA7KP3IEX5SS7YFGJIOXVTRAM4VXA5CNFSM4GBVPDYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKMQPBA#issuecomment-580454276, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGA7KP6C3DDKQYEXN5H5ECTRAM4VXANCNFSM4GBVPDYA.

hubertus65 commented 4 years ago

Here is an investigation by us for a partner regarding export control regulations in the EU and US regarding the encryption used in SEMLA. Part is in a Question-and-Answer from a lawyer asking us.

The tldr executive summary for the impatient is: SEMLA can be used by anyone without worrying about export controls. This has been checked and validated by corporate lawyers from e.g. ANSYS and others, as well as by us, Modelon. If you want to verify the details yourself, please dive into the following.

Background: Here is a bit of background on the software parts that are under export control in SEMLA. SEMLA is licensed under the open source 3-clause BSD license. We use the industry-standard open source OpenSSL software (see openssl.org) Version 1.1.1a. Alternatively users can choose the older version 1.0.2. OpenSSL is an open source project developed in Europe by European developers, so they themselves don’t follow US export control regulations. OpenSSL uses the dual OpenSSL and SSLeay license. Since OpenSSL is a core infrastructure element of the Internet and delivered as part of many open source packages by the Apache Software Foundation (ASF henceforth). AFS is a registered US non-profit corporation and strictly follows US export regulations. AFS registers all versions of OpenSSL with BIS and NSA as required by US export regulations, with the classification 5D002. SEMLA uses the RSA key-based algorithms with a 4096 bit long key.

For the export control assessment of the model library, please answer the following questions about the Modelon encryption tool: • Question: How is the tool classified with regard to European export control law (EU Regulation 428/2009)? Please indicate the export list position. Answer: The EU export control classification is 5D002. According to the guidance given in http://www.worldtradecontrols.com/eu-publishes-guidance-on-controls-on-information-security-items-and-the-cryptography-note/. This means that no export license is required in the EU. • How is the tool classified under US export administration rules (EAR)? Please provide the ECCN The EAR classification is 5D002. The source is the list from the Apache Software Foundation (ASF) which uses OpenSSL as component in many software packages developed and distributed by them. The list is here: http://www.apache.org/licenses/exports/. he ASF has an automated process that notifies BIS and NSA for each release of OpenSSL automatically, and they comply with the open source regulation for encryption software in that way. This holds for all versions, current and past, of OpenSSL, including versions 1.0.2 and 1.1.1a that is used in SEMLA. There is a good article regarding this requirement here: https://www.eff.org/deeplinks/2019/08/us-export-controls-and-published-encryption-source-code-explained. They say the following: “After satisfaction of the notification requirements of the EAR, software falls out of EAR coverage and publishers may export or publish open-source encryption software. “ AFS does this for openssl, therefore it falls out of EAR coverage.

• Is this tool open source software? Yes, with public access under https://github.com/modelon-community/SEMLA. • Is the encryption tool a publicly available encryption source code within the meaning of Part 742.15 of US export administration rules? Link: https://www.bis.doc.gov/index.php/documents/regulations-docs/2342-742-10-24-18/file Yes. As a Swedish company, not exporting or re-exporting from the US we believe that we don’t have to follow §742.15 (b), i.e. notification of BIS and NSA. In any case, AFS has done this for all versions of openssl, and according to the explanation by the eff above it falls out of EAR coverage. ANSYS did a legal audit of SEMLA and their use of it. ANSYS is a US company and has integrated SEMLA in their products and considers that safe. The conclusion of their legal department was that they can do so without problem.

If, as a company, you want extra security, you can send the SEMLA source code via to the US agencies BIS and NSA and in that way comply directly with the US regulations, and don’t rely on the registration done by the Apache Software foundation.

In conclusion: there are no reasons to not move forward with the SEMLA MCP based on export control regulations for encryption.

niklwors commented 4 years ago

For Bosch Rexroth a standardized method for encrypting Modelica libraries is of key importance. Bosch Rexroth develops Modelica libraries for various use cases where encryption is of great importance. We want to protect our libraries for different user groups with different levels of encryption. However, Bosch Rexroth customers uses different Modelica tools, so it is very important for us to have a standardized encryption method, which otherwise the effort required to encrypt our libraries is very high. Bosch Rexroth has reviewed the proposed encryption method for our application purposes under export control law aspects and does not see problems in using the method to encrypt our libraries.

niklwors commented 4 years ago

Is it possible for the Modelica Association to provide a reference implementation for the LVE and take responsibility for it? Perhaps the suggestion from Modelon Link: https://github.com/modelon-community/SEMLA can be used for this and included in the Modelica Association repository, where further developments will take place?

DagBruck commented 4 years ago

Is it possible for the Modelica Association to provide a reference implementation for the LVE and take responsibility for it?

We think this would be an essential part of the MCP. Not that everybody has to use the MA implementation of course, but a reference implementation would be very valuable and it would also be a useful tool for those who do not want to invest in developing their own.

The requirement is for an LVE plus a tool to package the Modelica library together with the LVE. Encryption is probably needed, but I do not think a licensing mechanism is needed in the reference implementation.

gkurzbach commented 3 years ago

ESI customers consider tool independent encryption and licensing of Modelica libraries very important. Therefore we plan to implement Modelons SEMLA in the next release of SimulationX (end of 2021). We hope that this will support the standardization of this technology.

MABackoffice commented 2 years ago

@hubertus65 I didn't find a ticket for MCP-0039 https://github.com/modelica/ModelicaSpecification/tree/MCP/0039/RationaleMCP/0039

Should this be the ticket? Then please add "MCP-0039: " to the ticket title.

henrikt-ma commented 2 years ago

The place where you find the entry points for the various MCPs is here: https://github.com/modelica/ModelicaSpecification/tree/master/RationaleMCP

There's also a dedicated GitHub label, MCP0039: https://github.com/modelica/ModelicaSpecification/labels/MCP0039

The label provides one way of finding the main PR of the MCP (https://github.com/modelica/ModelicaSpecification/pull/2931) (but in my opinion the main PR of each MCP should also be listed in the overview table at https://github.com/modelica/ModelicaSpecification/tree/master/RationaleMCP to make it easier to find).

While this answers the question (negatively) whether the present issue is the main PR of the MCP, this must be considered a predecessor from the trac times, so I'll add the GitHub label accordingly.

HansOlsson commented 2 years ago

Is it possible for the Modelica Association to provide a reference implementation for the LVE and take responsibility for it? Perhaps the suggestion from Modelon Link: https://github.com/modelon-community/SEMLA can be used for this and included in the Modelica Association repository, where further developments will take place?

Note that this is also a good idea from a legal standpoint. Currently SEMLA is an essential part of this proposal, but it's difficult for companies to contribute, since it is essentially owned by another company in the same market.

christoff-buerger commented 2 years ago

Is it possible for the Modelica Association to provide a reference implementation for the LVE and take responsibility for it? Perhaps the suggestion from Modelon Link: https://github.com/modelon-community/SEMLA can be used for this and included in the Modelica Association repository, where further developments will take place?

Note that this is also a good idea from a legal standpoint. Currently SEMLA is an essential part of this proposal, but it's difficult for companies to contribute, since it is essentially owned by another company in the same market.

That! Without any public, open source available reference implementation (i.e., a MA release) the objective of a portable, open standardadized, common encryption mechanism can not be achieved I am afraid. It is a no-go for companies to build on top of a free but not open source licensed library because of legal risks; and it is a no-go for open source communities for the same reason and because they don't want to loose the backbone they are developing on top if the controlling entity changes their mind.