ModelicaSpecification
ModelicaSpecification copied to clipboard
modelica
MCP-0029: Add License Annotation for External Libraries and Include Files
Modified by beutlich on 8 Dec 2017 08:24 UTC This is related to https://trac.fmi-standard.org/ticket/417.
Cuurently there is no clean solution for specifying additional licenses files used by external libraries and include files, which for example can be used for FMU code export features.
This seems straight-forward to standardize in similar fashion as the existing annotations Include or Library in section 12.9.4.
Document location
- https://svn.modelica.org/projects/MCP/MAinternal/MCP-0029_LicenseExport/
Reported by beutlich on 7 Dec 2017 11:15 UTC This is related to https://trac.fmi-standard.org/ticket/417.
Cuurently there is no clean solution for specifying additional licenses files used by external libraries and include files, which for example can be used for FMU code export features.
This seems straight-forward to standardize in similar fashion as the existing annotations Include or Library in section 12.9.4. Do you want me to prepare an MCP?
Migrated-From: https://trac.modelica.org/Modelica/ticket/2217
Comment by karl.wernersson on 7 Dec 2017 11:45 UTC Good Idea Please do =)
Comment by beutlich on 7 Dec 2017 12:15 UTC For external code, i.e., 12.9.4 it is clear.
But for translated code, it is not that obvious. One idea is to have the package license file in a predefined location, e.g. Modelica/Resources/Documentation/ModelicaLicense2.html and consider this/these file(s) as long as the file name(s) contain(s) "license". But is this enough?
Comment by beutlich on 7 Dec 2017 12:19 UTC Edit: Well, what will be kind of inconsistent then, that we explicitly specify the license files for external code, but implicitly search files at some default location for the package. One other idea is to specify an new top-level annotation for this package license file (goes after section 18.8.4).
Comment by anonymous on 13 Aug 2018 08:31 UTC Dymola 2019 prints an extra disclaimer in the FMU documentation on the open-source licenses.
This list does not include open-source components potentially included through the use of third-party Modelica libraries which are not part of the Dymola 2019 distribution.
The goal of this MCP is to move the license responsibility from the tool vendors to the library vendors and to have an FMU specific license documentation (instead of a generic documentation of all potentially used licensed third-party components).
Any feedback if this will make it in Modelica v3.5? MCP documents are available from https://svn.modelica.org/projects/MCP/MAinternal/MCP-0029_LicenseExport/
Any feedback if this will make it in Modelica v3.5? MCP documents are available from https://svn.modelica.org/projects/MCP/MAinternal/MCP-0029_LicenseExport/
@HansOlsson Can you give me any hint how to proceed here? Thanks. (So far I have not received any feedback at all on the MCP. If it is not relevant, we should cancel it instead of having it open forever.)
@HansOlsson Can you give me any hint how to proceed here? Thanks. (So far I have not received any feedback at all on the MCP. If it is not relevant, we should cancel it instead of having it open forever.)
I have examined it, it seems like a good simple proposal - and we should just try to get it included in 3.5 version. It may be that it was forgotten due to being mistaken for legally more complex licensing issues.
Looking at https://github.com/modelica/ModelicaStandardLibrary/pull/3376 I believe we should revisit this. The reason is that MSL has 10+ licenses and referring to all of them is tedious and error prone (in the sense that one license might be missing from the list).
So instead of specifying "the license" or "the licenses" it would make more sense to specify the "the license-directory"; similarly as for "the include-directory"; and also have a reasonable default.
My idea was to only include the required licenses per external function. For example, if you have a model with tables only, you would refer to LICENSE_ModelicaStandardTables.txt, but not to LICENSE_ModelicaFFT.txt, which is not needed.
My idea was to only include the required licenses per external function. For example, if you have a model with tables only, you would refer to LICENSE_ModelicaStandardTables.txt, but not to LICENSE_ModelicaFFT.txt, which is not needed.
Ok, that would also work - assuming the license part is only in external functions.
However, then the proposed specification text needs a different update as it says: "A top-level package or model can specify the license it is distributed." (There is also some missing word.)
I see three variants of which classes can specify a license.
- A top-level package or model. (Current text.)
- A function or a top-level package or model. (Just adding function.)
- Any class. If the class is used (e.g. as a component model, or a function is called) the license should be included. The license for a class in a package is the union of the licenses specified in the class and the license(s) specified in the enclosing package(s).
To me it seems we need the latter case. Any other comments?
My actual proposal was 2. Whenever a function gets called, its license(s) should be included (to the union of all licenses). So, to me, I am puzzled what 3. is needed for.
My actual proposal was 2. Whenever a function gets called, its license(s) should be included (to the union of all licenses). So, to me, I am puzzled what 3. is needed for.
I was considering cases like Modelica.Fluid.Dissipation where a sub-package (or even a specific model) is developed independently and then added to the package - but with a different license. I'm not 100% sure it is needed, but it looked as if it might be needed.
@HansOlsson Please let me know in advance if you plan to discuss this MCP during a web meeting.
"A top-level package or model can specify the license it is distributed." (There is also some missing word.)
Right. New proposal: A top-level package or model can specify its license file(s).
Note that there are two use-cases covered by this MCP.
- The licenses of the the Modelica library itself (e.g.,LICENSE_ModelicaStandardLibrary.txt in case of package
Modelica) as top-level annotation (similar to the uses annotation). - The implicated licenses of the external C functions (e.g. LICENSE_ModelicaStandardTables.txt in case of function
Modelica.Blocks.Types.ExternalCombiTimeTable.constructor) aimilar as the annotations for external functions.
This has the advantage that the Modelica simulator only needs to consider the license files that are actually used in the exported model.
If you are interested in developing this, I would suggest that you transfer this issue into an MCP branch with a directory for the relevant documents (ideally converted to markdown where applicable).
OK, I'll get you started. The following PR is the modern replacement for this issue (the number is a bit uncanny): #2900
I've only made a rough conversion of the rationale document. I'll leave it to you to decide how to deal with the specification changes for now. (In some situations, it can be better to wait with commits on the specification source files until it's time to start collecting reviews.)
I would suggest that the present issue is closed now, and that the discussion is continued in #2900.
OK, I'll get you started.
Thank you.
The following PR is the modern replacement for this issue (the number is a bit uncanny): #2900
Just the annoying endianess issue, I see.
I've only made a rough conversion of the rationale document. I'll leave it to you to decide how to deal with the specification changes for now. (In some situations, it can be better to wait with commits on the specification source files until it's time to start collecting reviews.)
Yes, we need to gather reviews first. And probably a tool implementation which I am not aware of yet.
I would suggest that the present issue is closed now, and that the discussion is continued in #2900.
I'd linked both issues. Thus, if #2900 gets merged, this issue is closed automatically.
The following PR is the modern replacement for this issue (the number is a bit uncanny): #2900
Just the annoying endianess issue, I see.
:)
I've only made a rough conversion of the rationale document. I'll leave it to you to decide how to deal with the specification changes for now. (In some situations, it can be better to wait with commits on the specification source files until it's time to start collecting reviews.)
Yes, we need to gather reviews first. And probably a tool implementation which I am not aware of yet.
The three required reviews needed to enter under preparation should be with regards to the actual specification changes, but to reduce risk of merge conflicts you typically want to have as much of the discussion as possible settled before beginning to make changes. Once the specification changes are in a relatively stable condition, you can engage the three reviewers, so that the reviews they give are relevant reading for anybody participating in the MCP vote during the later part of under evaluation.
I would suggest that the present issue is closed now, and that the discussion is continued in #2900.
I'd linked both issues. Thus, if #2900 gets merged, this issue is closed automatically.
The reason for closing #2217 would be to avoid getting more comments on this issue here, so that we concentrate future discussions in the proper place. (Naturally, #2900 is where you will find all discussions on the actual specification changes made on the MCP branch.)
@HansOlsson I set the milestone to ModelicaSpec3.7 (really due by 2024-03-31?)
@HansOlsson I set the milestone to ModelicaSpec3.7 (really due by 2024-03-31?)
That date should be changed, and I generally use the label M37 instead.