We have received a complain from Drew Bennett, Director - Software, Content Licensing and Research Partnerships who’s dealing with licensing of the EPIC QoL measure EPIC (Expanded Prostate Cancer Index Composite). The general, standard text about License is:
Licence: This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/4.0/.
As EPIC is licensed, there is an IP Acknowledge information added:
This is a contradiction, and may lead to confusion. Drew Bennet suggests to remove the License info, but that’s not what we want.
This is the case for other archetypes as well, and we need to be able to both state that the archetype itself is open source, but still point to the fact that to use the archetype is licensed. It is not super clear as it is now.
Should we rephrase the standard License text, something in the lines of “This archetype is licensed under the … and so on”?
Can the [“licence”] element in the adl be changed to [“archetype license”] ?
Can the order of [“licence”] and IP acknowledge be altered in the adl and CKM, so it is more clear that there is a license to use the score/scale/measure/PROM?
Although I don’t perse agree these are contradictory, I’m supportive off any clarifications to improve the acceptance of public archeypes modelling IP protected content.
We should check this isn’t a standard Creative Commons text, we don’t want any confusions re wether the archeype actually can be used under that license.
Both the license and Ip acknowledgement are under ‘other details’ attribute. So those are not specified by openEHR. But conventions by tooling.
The specs for resource description do specify an attribute for ‘copyright’. That class is a parent for adl2 archeypes and template. And the attribute seems to replace the ‘license’ in other details for adl1 archetypes.
We can’t just call that ‘archetype license’, because it’s not just about archetypes. Changing the name and/or meaning might be a breaking change at spec level. We could improve the description in the specs. And ask CKM to refer to the specs or some other clarification, would that help?
Ordering is done by tooling, so I guess yes, but up to tooling vendors. Or maybe hand changing the ADL fixes it.
We could add ip acknowledgements to the spec, and we can still choose any name and description we like, if that helps.
The “licence” field is an explicit field in adl2, migrated from the other_details field with key “licence”, so this would be a spec change for adl2.
Also it is the same name for any resource (templates mainly as well I suppose).
Putting IP Acknowledgements before licence in what is displayed in the CKM view is no problem if that is helpful.
Generally speaking the other_details in adl1.4 is just a key,value map without any particular order, so that specifying a particular order across any tooling is likely to fail sooner rather than later.
Personally, I think that modifying the licence text to clarify that the licence is for the archetype itself, but that there may be third party IP that has to be considered should do the trick and is better than changing the order and /or element name, which apart from the technical challenges I find more as it now.
Purely for CKM display (not inside the ADL), we could also add a short text after the licence text to state something to that effect if there are ip_acknowledgements.
(Copyright is separate - this has just been changed from 1 per archetype language to 1 per archetype between adl1.4 and adl2.)
What do you mean with ‘just changed’, adl2 depends on the resource description class I linked above, this contains the copyright attribute and is language specific right?
BTW we’re well aligned on the other parts of the post:)
No, it is not language-specific in adl2 in my understanding:
Copyright is in the archetype-wide BASE.RESOURCE_DESCRIPTION, and only the RESOURCE_DESCRIPTION_ITEM underneath is language-dependent.
If you compare this to the corresponding old RM.COMMON package Common Information Model
you see that copyright was moved from the (language-dependent) RESOURCE_DESCRIPTION_ITEM in Common.rm to the (archetype-wide) RESOURCE_DESCRIPTION in Base.
Second thought. If the IP holder insists the content is licensed, is it really true that the archetype “is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License”?
Maybe we just should move the text in today’s[“IP acknowledge”] to [“licence”] ?
So I think we can safely modify the phrasing of the license string. Maybe something like “Except where otherwise noted, this archetype is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit Deed - Attribution-ShareAlike 4.0 International - Creative Commons” ?
And maybe a similar modification to the overall licensing notice for the entire CKM?
@sebastian.garde, how difficult is it to display the IP acknowledge first, if it exists, in the CKM? Manually moving it in the adl doesn’t help. And if possible, when can this new way of display be introduced?
I understand the discussion is about two different types of licenses:
One is the access license, which is about being able to get, read, etc. the archetype, but not use…
The second one is the usage license, which allows to use what is modeled by the archetype.
My question is: do we have a simplistic licensing on archetypes that actually mixes both types of licenses? This is a clear example of that.
Second thought: should we explicitly separate both types of licenses in archetypes? Maybe in some both might just be the same, but in other cases like the EPIC index there is clearly two separated types that need to be clearly differentiated.
Nothing related to these parts of the archetype are a breaking change.
I like @siljelb suggestions but also suspect that might not be good enough for some ip holders. Might we direct this discussion to the PROMS group and @Koray_Atalag who are already in discussion with ICHOM on these issues.
Might we also consider working on specific, individual licensing statements for different providers. I appreciate this is burden but it might end up being less than the onogoing churn?
Well, turning it around and including this in next release won’t be a problem if that is what the community wants and what satisfies the third parties.
From my point of view, the current order works well with @siljelb 's suggested text, followed by the third party IP text.
I would probably rephrase “IP acknowledgements” which I find slightly misleading to e.g. “Third Party IP / IP Acknowledgements” to make it clearer that this is not a “thank you” message only, but highly relevant for being able to use the archetype.
It is worth noting in this regard that in adl2, the ip_acknowledgements are keyed, so that you can more easily separate between different third parties.
I don’t think it is interpreted/styled as markdown at the moment, but I would see no principle problem with enabling that, assuming it is used judiciously and the legal meaning is unchanged whether it is shown as plain text or styled as markdown.
Maybe, as @pablo suggests, there should be another “license” type, as the text we already made an agreement upon two years ago with the IP holder mostly consists of rules for using the measure. Meaning “obtain a licence first” type of notification. IP acknowledge is not the same.
My main concern is that fundamentally, the organisations we are dealing with find it very difficult to understand how an archetype is not a part of UI or implementation and that whatever kind of generic text we can come up with, and in whatever order, place etc will never be quite right.
If we try to put ‘both licenses’ in the same place, people will complain that it is confusing, and if we put them into separate places, they will complain that they do not undertstand why this artefact has 2 licences, and what is an ‘artefact license’ vs ‘a usage licence’
There are parallels with those fine-grained arguments around CC-BY-SA etc.
I know, but we can’t give up, or else the copyholders will oppose to make the archetypes available. I have argued it will be better for them to have a validated true-to-the-original archetype in CKM than a zillion home made pdfs based on an article in some medical journal.
I need to rephrase in EPIC soon, or else I fear we will have to remove the archetype.
I agree - my point is that I thin we should have a process where these kind of issues are passed on e.g to the PROMS group who will have increasing experience and similar cases to draw on with copyright holders.
They can point to agreements made with other people and I think they should be empowered to agree custom licensing text if that helps solve the problem.
So in this case it might be worth asking EPIC what they would like to see, as long as it does not compromise our IP rights, and is technically feasible to display in CKM.
But also let’s come up with a procedure for handling these kind of objections so that we do not land the responsibility of individual authors/Editors.
Yes - what I tried to convey with “Third Party IP”. Agree that IP acknowledgement is too weak as a header for this purpose (although probably ok as an element in the archetype itself).
Agree with Ian that it would be good to learn if there is anything specific that they would need to be able to support this.
- my point is that I thin we should have a process where these kind of issues are passed on e.g to the PROMS group who will have increasing experience and similar cases to draw on with copyright holders.