-
Notifications
You must be signed in to change notification settings - Fork 33
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 template update #656
Comments
One other option is to have a very broad regular expression for the license, e.g.
There are potential issues with this, there is a lot of freedom for text that could lead to errors, but it wouldn't require complex code to implement. |
I plan to incorporate the changes that I will make for this issue into the branch used for testing #628. I wanted to know how CMOR should handle a license created from the registered content vs that provided by the user input. I assume the default behavior should be filling in the What should happen if the user provides a license in the input file? Should the user-provided license overwrite the CV-provided license, or do we just force using the CV-provided license? Should the user-provided license be validated against the CV-provided license? |
@mauzey1 thanks for pushing on this. I would like broader consultation from this from @matthew-mizielinski and @taylor13, but in my view, if the template (which includes the Is this clear enough guidance? And @matthew-mizielinski does this work for you (and across other projects, for which we'll have to update the table defaults)? |
@durack1 Okay. So if the user provides a license in the user input like the one below
then we replace the template license with that one? |
@mauzey1 exactly, that is what I was thinking. Before you proceed, I might defer for signoff from @matthew-mizielinski and @taylor13 just to make sure that I am not thinking of all edge cases we may encounter |
I think I'd consider error-exiting (with a clear explanation) if the user-provided license doesn't match the registered license. Shouldn't we ask the modeling group to update the CV if they want to change their license? |
I just noticed that the license template contains the following substring.
How do we handle this? If the user adds this info, are we suppose to find the optional substring containing a URL? For example, If the license is made from the template, then it wouldn't have that substring, right? Should there be another user input parameter for a URL so that CMOR can build that substring? |
@mauzey1 good catch. Yes, so that user-provided URL would be optional, and if provided, we remove the |
I'm tempted to suggest that we have a meeting to discuss this. Some thoughts on the last few comments;
In this situation I would be tempted by changing CMOR and such that the license text here is a list with multiple entries, one for each acceptable license pattern, e.g.
CMOR could then test whether the license text matches any one of the licenses specified within this list -- if exactly one match is found proceed, if zero found then fail. This would also allow the current If C had a better regular expression capability I think we could simplify the above, but a quick google suggests that this is a little tricky at present. |
I don't think we need to be prescriptive as to what is in the license, but for CMIP, at least, CMOR should access an updateable CV entry, approved by the relevant modeling group, which contains the license information. The WIP would recommend that a group adopt one of perhaps a couple of options regarding the wording of the license, but I think the groups should be free to impose any license restrictions they want to. Perhaps CMOR should be flexibly configurable such that license information could be obtained from a CV or from the user's direct input. For CMIP we would require the license information be extracted from the CV; other projects might want to allow the data writer to directly inject the license to CMOR. We might also consider a 3rd option: we could store a URL in the CMOR license attribute that would point to the license description (perhaps in a CV) that could subsequently be updated. Under any of the options, I think we must insist that any update to a license would need to be in the direction of relaxation of restrictions; else someone might make use of data that at the time was allowed, but subsequently illegal. |
For context, here is the license template in the current CMIP6_CV.json.
This template is not derived from CMIP6_license.json but rather hard-coded in the script that builds CMIP6_CV.json. I applied @matthew-mizielinski's idea and made templates similar to the original in format but with all four options.
It does make the rules for the license and URL stricter by removing the If we just wanted to validate the license values provided by the user, then we shouldn't need to make any changes to CMOR. Do we still want CMOR to provide a license value created from the templates if the user doesn't provide one? Edit: Fixed the templates to escape periods. |
@mauzey1
That error is really a pitty because, at that stage in cmor_CV.c:2015, an error message should be created which would have clearly described what the problem is :D I have not looked into detail but it most probably is because of the additional license entry for all sources which cannot be evaluated by CMOR. Idk how but maybe users should be warned somehow when the update is coming.. It still works with the 9b44cc846da13a6594f7315af6430876f6c6fa5b CMIP6_CV.json version. |
This is actually related to an error we encountered where an error message got bigger than the maximum length of a string in CMOR (see issue #638). This has been resolved by pull request #639, which removes the code from cmor_CV.c that tries to build a long regex string for the error message to display. Each license template is >800 characters long, so concatenating them easily exceeds the CMOR_MAX_STRING value of 1024. This change will be in the next release of CMOR (version 3.7.0), which we are expecting to release later this month. |
Thanks for explanation. I suggest to update CMOR_Version in the header of the Tables in addition. That will let the users know they cannot work with the MIP-Tables and an earlier CMOR version. |
Due to changes to cmip6-cmor-tables from PCMDI/cmip6-cmor-tables#360 and WCRP-CMIP/CMIP6_CVs#1066, the way CMOR processes the license template will need to be changed.
The license template will be changed from the one below...
to this one..
The text was updated successfully, but these errors were encountered: