Some copyright holders of scores or scales have restrictions on translation of their scores. They want to approve that the translation is correct, which is understandable. Once an archetype is uploaded to the CKM ,it is available for translation. When the archetype reaches v1 or above, it means the design of the archetype, including the original language, is correct. But the state of the translations are handled differently.
When anyone can add a translation in a branch, the copyright holder loses control of the translation. This is problematic for some copyright holders, and restricts their willingness to allow their score to be âarchetype-fiedâ and made available in the CKM.
There is no way to not show translations in the CKM today. I wonder if there could be a feature of some archetypes as ânot translatableâ unless for specific users (possibly Translation Editors) and the translation to language âXâ not being visible until the translation of it is approved/published.
I know this will be difficult, also as the adl will contain all languages regardless of their completeness and/or correctness.
I have the same problem. I have worked on many PROM archetypes, but I only provide the English version to the international CKM due to copyright issues with the translations. However, there is no guarantee that someone else will not translate the archetype.
@sebastian.garde - If you could take a look at this case, that would be great! I have another question: when an archetype is uploaded to the CKM, will the whole structure only contain the ADL code, or is there a possibility of adding extra âtagsâ to indicate that an archetype is a PROM/CROM, which would make the translation feature appear differently as @varntzen suggested?
I also remember suggesting some time ago implementing in the CDR some kind of feature to warn if the model contains a copyrighted model, and to check if the owner of the model holds the copyright for it. For example - REDCap - an application which is typically used for case report forms, asks this every time a new form or instrument is added to the database - doesnât matter what type of form it is. They added this recently because were affected by the same issue. It does not solve the problem but gives awareness, which I believe is one of the main issues to start.
A bit off topic:
We had to take down several proms in incubators.
I think openEHR internatnational has to get into contact with this proms organizations.
Maybe we can reach some sort of agreement in general in regards of PROMs for some companies as we have with SNOMED.
That we can use it in the models but used practically you need a license.
Not sure I have a good solution for this, but letâs explore.
In terms of what is possible now:
It is possible to configure CKM to restrict the checkout of archetypes and templates to users with a role for the owning project (or an instance-wide role such as CKA or translation admin). This applies to all archetypes and templates then though.
In terms of what could be investigated for the future:
A Project-specific restriction: We could look into extending projects to be able to override the above âcheckout-restrictionâ setting on a per project basis. Then the checkout could be controlled for all archetypes and templates owned by a specific project (one ore more PROMs projects for example). Or:
An Archetype-specific restriction: We could also look into agreeing on a specific attribute in the archetypeâs (language-independent) other-details section, such as âtranslation-restrictedâ and if that is âtrueâ then the checkout is restricted for users without special rights for the archetype/its project. From a CKM point this is possible (albeit probably only as a backend check causing an error message when people actually try to checkout a specific resource). This would enable control on a per archetype basis, but at the expense that this has to be managed somehow in the archetype.
Of course, even then anybody can download the archetypes and translate them elsewhere, e.g in AD. Or fork the Github repo and do it there. This is beyond your control and also responsibility I assume, however of course, if the copyright owners are concerned about (fairly hidden away) branches on CKM, they may be concerned about that possibility as well.
The irony here is that copyright holders are happy to themselves publish an article describing the score/PROM in detail, without any control of how it is going to be used, how it will be translated and possibly modified.
But when we are publishing an archetype with all data items correctly represented both in terms of wording, data types and value set, ready for downloading to be used in an application, this is suddenly something they have concerns about. It should be the opposite, archetypes are providing more confidence for the copyright holders that the score/PROM will be correctly used and represented.
This is an educational issue we as a community have to work with.
As this will affect all archetypes and templates, it is not a way ahead, I think.
Sounds good, but the other way around: Project-specific rules that prevent users without âcheckout privilegesâ to make a branch. I guess some of the âdifficultâ archetypes when it comes to restrictions/control of translations can reside in one, or very few, such project. This means the archetypes will be in a read only state (unless for designated users with privileges). But it wonât stop anyone to download and do whatever they want with it, though.
Possible, but less elegant than alternative 1, and I guess with more workload both on modellers and in the CKM.
Another (bad) possibility is to specialise the original archetype for each translated language, and publish them separately.
Iâm starting to think the âproblemâ we are dealing with here, is the conflicting interests and philosophy between copyright holders and the openness and sharing philosophy in openEHR, including the âdo-ocracyâ attitude. It might be that this problem sometimes is not possible to solve.
Already the commit to main branch from a branch with translations is only possible for authorised (editors) right? Isnât that the correct point to do the enforcement? The editors should check copyright before committing to main, am I wrong that editors are able to do that without extra CKM features?
I donât think itâs reasonable for copyright holders to stop anyone from translating their work, only to publish that translation. And openEHR policy should be that only the main branch is to be considered published. This does mean that anyone could download a translated archetype from the branch, but we couldnât do community translations without that. If we block it in CKM it wil just happen in some other public place with worse support, like a public archetype designer repository, also under openEHR domain.
As an alternative we might want to use the translation review process to offer copyright holders the opportunity to review translations. And then we could consider CKM by default downloading the ADL with only reviewed/published translations. That way, by default, you will never download an archetype with a translation that has not been reviewed by the copyright holder. It should still be possible IMO to download with draft translations, maybe a secondary action/button on the download page.
CKAs, Project editors, Translation Administrators and Translation Editors (of that project) can commit a translation to the trunk. A translation editor might not have the insight in the licensing/copyright regulations on that particular archetype.
Well, some do. And sometimes rightly, if you ask me. Words matter in validated scores/PROMs.
Correct. But when the translation is available in the openEHR CKM, even in a branch, openEHR might breach the regulations from copyright holders, and risk being held accountable.
Yes, highly recommended.
This is unfortunately not possible today.
Correct. We canât control that. As for any unauthorised translation from a published article - paper or web. Copyright holders are (or should be) aware of that, but still have objections to upload their PROM/tool to the CKM, both in original language and translated. Checking license regulations and comply with them ahead of putting an archetype in production is a responsibility of the implementer, not the modeller or openEHR who make the archetype available. But when the translation is a part of the archetype itself, then this is a responsibility of âthe publisherâ, in this case openEHR.
Iâm afraid this doesnât solve anything, it will only be digging a hole under the fence.
This is now mostly a legal argument I believe. So not sure it makes much sense to discuss among modellers without a joint legal understanding. Very hard without lawyers and all the different jurisdictions and legal systems. Any suggestions?
I think weâre running into an edge case here that exposes the downsides of overlapping application roles as editor and publisher. AD is the main editor for archetypes, CKM is the main publisher. But CKM is the main editor for translating archetypes.
I think itâs fair to apply license to publishing copyrighted material. Rules for editors should be different, based on that itâs not published for use, so no one would ever see the copyrighted material. The issue off course is we edit publicly. Which means anyone can see the âunpublishedâ artefact. So we need to strike a reasonable balance. Weighing the concerns of the copyright holders, separating them in practical (like quality control) and legal (because they claim legal rights).
Practical concerns may be solved by practical people. Like the creator of the IP and people like you and me.
Legal claims should be contested if against our interests. And require risk analysis and mitigation strategy.
I will move the discussion from the legal perspective to the modeling perspective, and Iâm going to be quite frank here.
What is the point of having a model that cannot be translated into other languages in the international CKM? If that is the case, I believe it goes against the philosophy of having an open and global repository of knowledge artifacts. We would be publishing a model that is only valid for a specific context or jurisdiction (the English-speaking countries).
If thatâs the case, this should not be a discussion about the capabilities of the tools, but a discussion about whether such archetypes should be published in the international CKM at all.
Thereâs still a lot of value. If you/implementers do the translations locally (outside of CKM) the model and semantics (mostly) and data are still standardised.
