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
License Export #2900
base: master
Are you sure you want to change the base?
License Export #2900
Conversation
In order to avoid confusion at least the summary should make it clear that it's not related to licensing (and other proposals for IP-protection) but just about including the license texts. |
Several of the links in the document seem to be broken. |
Resolved by 70f0c49. |
I miss a general description of the annotation, like where is it allowed (in the example it's on the top-level package and on external functions, but can it be any where?) and what does it mean and what's the expectation on the tool. Now everything is implied from the summary/rationale. |
Two use cases:
|
Design meeting: Seems good - try to make ready for next release. |
Since we now have a prototype implementation I would suggest:
|
I think it would be good if we could progress on this simple (and fairly uncontroversial) MCP. |
This is just a rough manual conversion of the following file to get the MCP branch started: - https://svn.modelica.org/projects/MCP/MAinternal/MCP-0029_LicenseExport/MCP-0029_LicenseExport_Overview.pdf
Co-authored-by: Hans Olsson <HansOlsson@users.noreply.github.com>
Added prototype.
Please note, that I rebased and force-pushed the PR branch. |
Since it can also occur at top-level packages we should likely add that as well
Co-authored-by: Henrik Tidefelt <henrikt@wolfram.com>
Co-authored-by: Henrik Tidefelt <henrikt@wolfram.com>
Add minor specification text corresponding to what has been implemented.
It doesn't sound like a bad idea to me, but I think we need a concrete proposal here, and I don't think modelica/ModelicaStandardLibrary#4268 gives all the answers. In my opinion, having a Licenses/Third-party suggests that no license files should be placed directly under Licenses, but that there should also be a directory for non-third-party licenses next to Third-party. This would make it clear that one always needs to make an active choice of where to place the file, and avoiding that the use of Third-party somehow ends up being interpreted as voluntary. |
Would be good if we could those reviews to move this forward. |
Even if I think that it is a good idea, I don't see that we need to standardize this, but that library authors can handle that themselves - including the naming of the license files, and whether non-3rd party licenses should be in a separate directory, or directly under licenses. To me such over-standardization just risks delaying the development, reduce innovation, with very little gain. The main part is that it should be clear what licenses apply to what component - for two reasons:
|
I agree that the standard should not prescribe fixed locations for the license files, as it goes against the idea of using a Modelica URI to locate the file. (If there were fixed locations, we should have simply stated that all relevant license files (and only those) should be placed in If we would like to have special recognition of license files coming from third-party dependencies in the future, we could add another annotation: |
I agree with your comments @HansOlsson and @henrikt-ma. The main intention of modelica/ModelicaStandardLibrary#4268 was to increase visibility and transparency what's MA and what's third-party as "explicit is better than implicit". |
The structure of the
|
Co-authored-by: Henrik Tidefelt <henrikt@wolfram.com>
Language group: "license text files" seems best, but think of other options during the week. Alternatives are "license conditions", "license agreements", and possibly more. |
Looking more I think that even if "license agreements" could work it often refers to other agreements (for patents, trademarks, etc), but these licenses are primarily a copyright-license, so if we wanted to be clear it should be "copyright license agreements". However it also seems to depend on the kind of license: https://opensource.org/licenses - just calls it licenses, whereas commercial licenses are often called license agreements (including having you actually sign that you agree to them). |
According to 2024-02-20 phone meeting.
We're looking for something which is not called just license file to avoid collision with the |
Hm, is a file License.md also a license text file or is it a license markdown file? I'd even claim that the annotation name has to match the other wording. I am actually in strong favor to call it license file. |
I would say that "license text file" refers to the logical contents - i.e., that the "file" contains the "license text" in these cases. It may still be that we should use another name. |
Another solution would be to describe the other "license files" as something else (the files that actually provide computer-readable licenses). However, looking closely it seems that when using FlexNet and similar programs the computer-readable files for licenses are often called "license files". |
Co-authored-by: Hans Olsson <HansOlsson@users.noreply.github.com>
In preparation of the voting...
|
In the discussion above it sounds like the location is assumed to be given by a modelica URI. If that's the case, perhaps that should be spelled out more in text and not only in the code snippet. Like it is for the other external function annotations.
|
Yes. It was discussed at the latest phone meeting, and nothing better was found.
Yes, that is a constant problem. I think this one was unnecessarily delayed since "license" evoked a lot of other license-issues. |
This is a good suggestion. Can we consider it Typos and similar trivial changes so that we can fix it during the evaluation period? |
\section{License Texts}\label{license-texts} | ||
|
||
For a top-level class the {\lstinline!annotation(License="modelica:/ModelicaLibraryName/Resources/Licenses/MyLicense.txt")!}\annotationindex{License}, gives a license text file for the class. | ||
The annotation may give a scalar value or an array of values. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is a concrete proposal for addressing @otronarp's #2900 (comment):
The annotation may give a scalar value or an array of values. | |
The annotation may give a scalar string or an array of strings, where each string is a URI referencing a license text file, see \cref{external-resources}. |
This is MCP-0029 License Export. Currently in Draft state to reflect state of being under development.
This PR is the continuation of the issue #2217.