ModelicaSpecification
ModelicaSpecification copied to clipboard
modelica
License Export
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.
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 70f0c49fa2a10bd681811ce626e8b965bdffd239.
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.
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:
- Top level annotation (similar to the existing
usesannotation) to specify the license of the Modelica source package. - Annoation for external functions (similar to the existing
LibraryDirectoryannotation) to specify the third-party licences of external libraries.
Since we now have a prototype implementation I would suggest:
- [x] Merge master into this branch (to avoid merge conflicts later).
- [x] Add the few lines needed for the specification.
- [x] Then review it.
Since we now have a prototype implementation I would suggest:
- [ ] Merge master into this branch (to avoid merge conflicts later).
- [ ] Add the few lines needed for the specification.
- [ ] Then review it.
I think it would be good if we could progress on this simple (and fairly uncontroversial) MCP.
To me this seems ready, and we can move forward with this and start formal review soonish. We have a prototype in Dymola and a library using it already.
Can we move forward with this MCP? ("License export")
BTW: I would see the prototype implementation in Dymola and experience as a Review.
There are some things that could be made even clearer, but I think this is ready to be evaluated.
Use emojis (face left-below) to vote (closes day before next phone meeting):
- Thumbs up: Ok to move forward to "Under evaluation". If so please provide a Review as well (we need three to move forward).
- Thumbs down: Don't want this at all.
- Eyes: Need more discussion.
After dealing with OSS licenses for some years, I prefer to have the utilized third-party licenses explicit set. See modelica/ModelicaStandardLibrary#4268 for what I mean. This way it is clear which licenses are directly produced by the original authors and which one are pulled-in by third-party OSS.
It doesn't sound like a bad idea to me, but I think we need a concrete proposal here, and I don't think https://github.com/modelica/ModelicaStandardLibrary/pull/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.
Reviewers: Henrik, Elena
Would be good if we could those reviews to move this forward.
After dealing with OSS licenses for some years, I prefer to have the utilized third-party licenses explicit set. See modelica/ModelicaStandardLibrary#4268 for what I mean. This way it is clear which licenses are directly produced by the original authors and which one are pulled-in by third-party OSS.
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:
- Tools can then automatically include them with generated contents.
- Users can quickly find the licenses and get their legal experts to review them.
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.
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 modelica:/ModelicaLibraryName/Resources/Licenses.)
If we would like to have special recognition of license files coming from third-party dependencies in the future, we could add another annotation: annotation(ThirdPartyLicense="modelica:/ModelicaLibraryName/Resources/ThirdPartyThing/TheirLicense.txt")
I agree with your comments @HansOlsson and @henrikt-ma. The main intention of https://github.com/modelica/ModelicaStandardLibrary/pull/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 License-annotation is identical with the styleSheets which was recently added in #3409. Shouldn't we be introducing License in the same modern style (where the inclusion of constant would depend on whether #3448 is merged first)?
constant String[:] Licenses "URIs pointing to license files";
Language group: "license text files" seems best, but think of other options during the week. Alternatives are "license conditions", "license agreements", and possibly more.
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).
I'd simply call it "license file". See also https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license
I'd simply call it "license file". See also https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license
We're looking for something which is not called just license file to avoid collision with the licenseFile-annotation. I've updated it now to license text file according to https://github.com/modelica/ModelicaSpecification/pull/2900#issuecomment-1954375478, but I'd be in favor of something more clearly distinct from license file.
I'd simply call it "license file". See also https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license
We're looking for something which is not called just license file to avoid collision with the
licenseFile-annotation. I've updated it now to license text file according to #2900 (comment), but I'd be in favor of something more clearly distinct from license file.
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'd simply call it "license file". See also https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#determining-the-location-of-your-license
We're looking for something which is not called just license file to avoid collision with the
licenseFile-annotation. I've updated it now to license text file according to #2900 (comment), but I'd be in favor of something more clearly distinct from license file.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 would say that "license text file" refers to the logical contents - i.e., that the "file" contains the "license text" in these cases. So, whether the file format is plain text, markdown, pdf, or a jpeg with a photo of the license text(!) shouldn't matter here.
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".
In preparation of the voting...
- Is the term
license text filesfinally resolved/decided? It rather looks still pending to me. If it is decided it is inconsistent in one location presumablely and inconsistent with FMI (where it is calledlicense filesin https://fmi-standard.org/docs/3.0.1/#structure-of-zip with example given). Note, that I am alo in favour to name itlicense filesand give an example. - Apart from this naming issue, it feels confirmative that my MCP-0029 is on the finish line. As usual, the rationale was written within some days, but the final text takes years...
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.
...location could be specified by using an URI name for the library directory, see section 13.5.
In preparation of the voting...
- Is the term
license text filesfinally resolved/decided?
Yes. It was discussed at the latest phone meeting, and nothing better was found.
- Apart from this naming issue, it feels confirmative that my MCP-0029 is on the finish line. As usual, the rationale was written within some days, but the final text takes years...
Yes, that is a constant problem. I think this one was unnecessarily delayed since "license" evoked a lot of other license-issues.