# Licensing of specifications and archetypes: Discussion from 2015 **Category:** [General Discussion](https://discourse.openehr.org/c/general-discussion/132) **Created:** 2026-01-21 07:18 UTC **Views:** 72 **Replies:** 31 **URL:** https://discourse.openehr.org/t/licensing-of-specifications-and-archetypes-discussion-from-2015/11697 --- ## Post #1 by @siljelb In light of the recent public consultation on licensing changes by openEHR International, I'd like to post an email discussion about the topic from 2015, with the consent of the original senders. I'll post each email in a separate post and in chronological order below. *Edit: I'm unsure whether a common document or wiki page was created as was suggested in some of the posts. I can find several Confluence pages about licensing and licensing change proposals, but the newest one of them was last changed in 2013.* --- ## Post #2 by @siljelb > **From:** @ian.mcnicoll > **Sent:** Monday, October 05, 2015 7:16 PM > **To:** Erik Sundvall; Bakke, Silje Ljosland; Thomas Beale > **Cc:** openEHR MB List > **Subject:** openEHR working group on Licensing issues > >Hi all, > >I have been asked by the Management Board if you would consider forming a short-life working group to summarise current options for re-licensing openEHR specifications, software and clinical models and provide a brief report back to the Management Board of your conclusions. > >There does appear to be a high level of consensus in the community of overall aims of licensing and a clear commitment to maximal openness and as few restrictions as possible. > >You might want to consider starting with these questions? > >1. Software > >Is there any need to review current apache-licensing for key components. Is it reasonable for tooling vendors such as Marand to apply a GNU type licence to the software whilst they are still principal maintainer? > >2. Specifications > >Should we consider dropping the -No Derivatives clause, given that we are unlikely ever to pursue a fork e.g MHLIM? Assume that we have Trademark protection in the key markets. > >3. Clinical content > >We sense that there is now reasonable consensus that the original reason for the -SA clause (prevention of re-commercialisation) is not particularly valid. Silje looked at this issue in the context of forking archetypes between CKMs and had some further concerns that dropping the SA clause might have other knock-on effects, particularly around more restrictive government licenses when archetypes are forked. Do we care? Is there any merit in switching to software licences for archetypes and templates? > >4. For all > >Does taking the FHIR route of CC-BY-0 have any merits (again assuming that Trademarking is in place). > >I know a lot of thinking and collating has already been done, and there is no need to re-visit any of these issues in detail. All that the MB are looking for a re some high-level recommendations and any caveats. No more than a single A4 page? > >If you have any questions, please ask. --- ## Post #10 by @siljelb --- ## Post #11 by @siljelb > **From:** @thomas.beale > **Sent:** Tuesday 6th October 2015 12:18 > > Happy to do this. > > My main input is to suggest we move beyond just Apache2 for software. > Various GPLs need to be allowed as well, and a short guideline published > as to which to choose in what circumstance. > > I am not interested in the FHIR approach; it relies on much greater > legal resources than we have now, and is an outlier approach w.r.t. > mainstream open source. > > Is there a common document we can edit containing the recommendations - > I would argue for a wiki page, so it is community-visible. --- ## Post #12 by @siljelb > **From:** @erik.sundvall > **Sent:** Thursday 8th October 2015 01:28 > > I am also happy to join this, but will not do do anything until next week. Agree to start with privately shared document for a first draft, then move to wiki page for community feedback before any decision is made. Set up a google doc or e en better start a privately shared wiki page that we then later van switch to public. > > Software licence for archetypes sounds like an interesting option. Apache 2 or what was in mind? > > Drop ND on specs but emphasise trademark for specs also sounds good. --- ## Post #13 by @siljelb > **From:** @siljelb > **Sent:** Monday 12th October 2015 14:51 > > My thoughts on the issue: > > Regarding CC-BY-SA: > * The SA (ShareAlike) clause in the Creative Commons BY-SA licence (which all the openEHR archetypes are licensed under) mandates that any derivative works are licensed under a compatible licence, ie CC-BY-SA or (for CC-BY-SA 4.0) GPLv3. > * Commercial implementers might avoid using CC-BY-SA artefacts because the license requires any published modifications of the work to be licensed using the same license. This might lead implementers to believe the license would require them to license their entire software product as CC-BY-SA or GPLv3. There are several examples of CC-BY-SA works being used in copyrighted works, such as Wikipedia articles being used in newspapers, but this is probably reliant on a benign licensor, which any normal commercial company can’t rely 100% on. The way I see it, this problem could be solved in one of two ways: > * Use the CC-BY or another non-copyleft license (or even the PD waiver CC-0), which retains the attribution clause, but doesn’t require any derivative works to use the same license. This has the disadvantage of enabling proprietary tweaking of archetypes, which could potentially ruin interoperability. It would also mean the end of “all archetypes are freely licensed” paradigm which we’re working under at the moment. As soon as we leave the principle of copyleft, archetype licencing could start to diverge between different repositories. Eg. Openehr CKM could be PD, NEHTA could be regular copyright with no free licence, Norwegian CKM could be MIT, UK CKM Apache 2 Licence, Brazil CC-BY-ND, etc etc. This could make it harder to navigate the world of archetypes, since “archetypes are free to use and modify but remember attribution and you can’t change the licence” wouldn’t be true anymore. Even while initially simpler, non-copyleft licenses might make the world more complicated further down the road. > * Retain the CC-BY-SA license, but add an explicit clause that allows all implementers to use artefacts in closed-source, proprietary products with any license they like. Artefacts published by themselves, as standalone archetypes, templates or terminology sets would still be bound by the ShareAlike clause. This is supported by Creative Commons via the [CC+](https://wiki.creativecommons.org/CCPlus) protocol. An example can be found here: http://www.nysenate.gov/copyright-policy. > * Mockup: > > * [![image|80x15](upload://h7EPmlDeeBoFGrzb8nusf5HgPMi.png)](http://creativecommons.org/licenses/by-sa/4.0/) All artifacts published on this site are licensed under a [Creative Commons Attribution-ShareAlike 4.0 International License](http://creativecommons.org/licenses/by-sa/4.0/). Permissions beyond the scope of this licence are defined as follows: > Artifacts generated from the artifacts published on this site, including but not limited to operational templates, object models and source code, are NOT bound by the ShareAlike clause in the CC-BY-SA licence. > * Find or make up a license or license scheme which supports copyleft (ie the ShareAlike clause) for the original independent artefacts such as archetypes and templates, but not for transformed artefacts or software (for instance OPTs or object models). I’ve asked on the Open Source StackExchange site if anyone know about licences or licence schemes like this, but thus far there hasn’t been much real progress. (see http://opensource.stackexchange.com/questions/421/what-would-be-a-good-licence-for-computable-data-models) > > Regarding copyright notices: > * Even the most permissive licence I’ve looked at (the MIT X11 licence) requires the copyright notice to be left unchanged from the original copyright holder. Apache 2, while also permissive, is a bit stricter, and Mozilla Public Licence is about halfway between permissive and copyleft. (CC-BY-SA and GPL are other copyleft licences) > * There might be super-permissive licences out there that I haven’t heard of, but the only way I know of to allow NEHTA to change copyright to themselves when importing someone else’s archetypes, would be that the archetypes were public domain to begin with. > > Regarding trademarks: > * I don’t think trademarks are as relevant when talking about archetype licensing as specs licensing. As long as the specs are CC-BY-ND, nobody but the foundation can modify them and publish the result, and as such “competing” openEHRs aren’t very likely. --- ## Post #14 by @siljelb > **From:** @thomas.beale > **Sent:** Wednesday 14th October 2015 11:48 > > thanks Silje > > on CC-BY-SA - the basic practical question I think is: do the archetypes with this licence 'infect' templates (which in ADL2 are just archetypes) which then 'infect' software e.g. UI screens or XML schemas generated from those templates (OPTs)? > > If the legal answer to this is 'yes', the licence needs changing for this reason. > > If the legal answer is no (because the generation step is something like transformation or compilation, not a reuse of the original artefact), then we either: > > * educate the community on this point and leave the licence the way it is > * add the explicit clause to the existing licence that clarifies the idea that the transformation step is not regarded as creating a 'derivative work' > > * change the licence anyway (for no good legal reason) because we don't think the 'bad smell' of it can be expunged in the minds of potential users > > There is no question in my mind re: copyright notice - it should work as it works in the mainstream open source software arena. Nehta just need the facts explained to them. > > There is the question as to whether the CC-BY-ND licence on the specs should change. As I've said before, the thing we need to achieve here is that noone can alter and republish an openEHR spec with the 'openEHR' name or logo on it, if that spec was not issued by the openEHR Foundation. We don't want to legally prevent forking (which is what HL7 does do), but we do want to prevent dishonest masquerading. I don't mind what licence we use to achieve this. > > thoughts? --- ## Post #15 by @siljelb > **From:** @erik.sundvall > **Sendt:** Wednesday 14th October 2015 14:02 > > Hi! > > **Regarding CC-BY-SA for archetypes** I think toms bullet point… > > > change the licence anyway (for no good legal reason) because we don't think the 'bad smell' of it can be expunged in the minds of potential users > > …is actually an important issue. > > Silje wrote: > > This has the disadvantage of enabling proprietary tweaking of archetypes, which could potentially ruin interoperability. It would also mean the end of “all archetypes are freely licensed” paradigm which we’re working under at the moment. As soon as we leave the principle of copyleft, archetype licencing could start to diverge between different repositories. > > I have some issues with that line of reasoning (even though it may sound nice the first time around)… > * A license won’t stop proprietary tweaking, somebody could just tweak it enough (rearrange items, ID-codes etc) to claim that they were only inspired by the original (or by general medical knowledge), not copying the original archetype. We can’t use a licence to block the stupidity of tweaking to ruin interoperability. Education, validation-tools and checksums will be better tools to detect and alert people of such behaviour. > * We do not today have an “all archetypes are freely licensed”-paradigm, there are plenty of proprietary and/or non-shared archetypes out in the wild, used in systems. > * We already have archetypes diverging between different repositories, the licence did not stop that. (GPL has not stopped forking of software projects either...) > > One problem with using CC-BY-SA or similar things in the main openEHR repository is that others can copy that behavior without assigning the copyright to openEHR. If they used Apache 2, CC-BY or similar licenses it does not matter who has the copyright, we do not need to trust them (e.g. Nehta) to be a “benign licensor” for us to dare using their archetypes (or archetype tweaks) as a basis for official openEHR archetypes. > > Regarding the CC+ extension alternative removing SA from generated downstream artifacts, I have already argued that it thanks to clever programmers and reverse engineering in practice nullifies the SA part (or worse, fails to remove it at all) so why not use CC-BY from the beginning, see details in the comment… > https://openehr.atlassian.net/wiki/display/oecom/Archetype+licensing+-+the+case+for+CC-BY-SA?focusedCommentId=6127957#comment-6127957 > …and the comments following it. I never really got any good complete answer from Sam so I still think the SA-with-a-general-wavier-construction is very much confusion for no practical gain. > > Using a known software license like Apache 2 etc for Archetypes might actually be better than CC-licences, it makes the “attribution” a bit easier to understand, and serialized/saved archetypes may very well be considered to be software components. Ian mentioned this as a possibility I believe. > > **Regarding CC-BY-ND for Technical Specs:** > ND complicates forking, but as mentioned before, if UML with class descriptions and all other computable it implementation-crucial spec-artifacts are under Apache 2, then a fork can be compatible and the forkers “just” needs to rewrite the textual stuff and create new images. > > ND still has the “bad smell” of “what are they afraid of – what is their hidden agenda”, so if it could be dropped it would smell better. > The bullet-points directly under heading 1.3.2.1 in http://hl7.org/fhir/license.html#1.3.2.1 seem to have gotten clearance by the HL7-lawyers, we should be able to make a similar clarification in openEHR specs if we pick some permissive license (not necessarily CC-O as FHIR did). > > I have not studied documentation licenses thoroughly, but found this page somewhat useful: http://www.dreamsongs.com/IHE/IHE-50.html > > //Erik > > P.s. You might find the following discussions interesting: > > * https://openehr.atlassian.net/wiki/display/oecom/openEHR+IP+License+Revision+Proposal > * https://openehr.atlassian.net/wiki/display/oecom/Archetype+licensing+-+the+case+for+CC-BY-SA --- ## Post #16 by @siljelb > **From:** @thomas.beale > **Sendt:** Wednesday 14th October 2015 14:38 > > On 14/10/2015 13:02, Sundvall Erik wrote: > > > > **Regarding CC-BY-SA for archetypes** I think toms bullet point… > > > change the licence anyway (for no good legal reason) because we don’t think the ‘bad smell’ of it can be expunged in the minds of potential users > > > > …is actually an important issue. > > > > Silje wrote: > > > > > This has the disadvantage of enabling proprietary tweaking of archetypes, which could potentially ruin interoperability. It would also mean the end of “all archetypes are freely licensed” paradigm which we’re working under at the moment. As soon as we leave the principle of copyleft, archetype licencing could start to diverge between different repositories. > > > > I have some issues with that line of reasoning (even though it may sound nice the first time around)… > > > > * A license won’t stop proprietary tweaking, somebody could just tweak it enough (rearrange items, ID-codes etc) to claim that they were only inspired by the original (or by general medical knowledge), not copying the original archetype. We can’t use a licence to block the stupidity of tweaking to ruin interoperability. Education, validation-tools and checksums will be better tools to detect and alert people of such behaviour. > > * We do not today have an “all archetypes are freely licensed”-paradigm, there are plenty of proprietary and/or non-shared archetypes out in the wild, used in systems. > > * We already have archetypes diverging between different repositories, the licence did not stop that. (GPL has not stopped forking of software projects either…) > > > > One problem with using CC-BY-SA or similar things in the main openEHR repository is that others can copy that behavior without assigning the copyright to openEHR. If they used Apache 2, CC-BY or similar licenses it does not matter who has the copyright, we do not need to trust them (e.g. Nehta) to be a “benign licensor” for us to dare using their archetypes (or archetype tweaks) as a basis for official openEHR archetypes. > > > > Regarding the CC+ extension alternative removing SA from generated downstream artifacts, I have already argued that it thanks to clever programmers and reverse engineering in practice nullifies the SA part (or worse, fails to remove it at all) so why not use CC-BY from the beginning, see details in the comment… > > https://openehr.atlassian.net/wiki/display/oecom/Archetype+licensing+-+the+case+for+CC-BY-SA?focusedCommentId=6127957#comment-6127957 > > …and the comments following it. I never really got any good complete answer from Sam so I still think the SA-with-a-general-wavier-construction is very much confusion for no practical gain. > > it probably is - I just wanted to expose the potential solutions (even if we think some of them are dumb), which is more or less restating what Silje said anyway... > > > Using a known software license like Apache 2 etc for Archetypes might actually be better than CC-licences, it makes the “attribution” a bit easier to understand, and serialized/saved archetypes may very well be considered to be software components. Ian mentioned this as a possibility I believe. > > I have also wondered about this... > > > **Regarding CC-BY-ND for Technical Specs:** > > ND complicates forking, but as mentioned before, if UML with class descriptions and all other computable it implementation-crucial spec-artifacts are under Apache 2, then a fork can be compatible and the forkers “just” needs to rewrite the textual stuff and create new images. > > I've just realised there is no licence specifically on the UML models - they are located in the Github repos with the specs, and are only covered by the CC-BY-ND licence there. I suspect we don't want that because we do want people to use (i.e. change / add to) the UML models, just not republish them as something they are not. Do we need to insert Apache 2 licences in specific directories? > > > ND still has the “bad smell” of “what are they afraid of – what is their hidden agenda”, so if it could be dropped it would smell better. > > The bullet-points directly under heading 1.3.2.1 in http://hl7.org/fhir/license.html#1.3.2.1 seem to have gotten clearance by the HL7-lawyers, we should be able to make a similar clarification in openEHR specs if we pick some permissive license (not necessarily CC-O as FHIR did). > > I would agree with the first list of bullet points there. > > > I have not studied documentation licenses thoroughly, but found this page somewhat useful: http://www.dreamsongs.com/IHE/IHE-50.html > > hm - with respect to documents, I don't believe in the idea that documents can be redistributed with 'minor' updates by intermediate reviewers/users without reference to the original authors (other than exceptional cases where the original author is dead or gone, and the new 'author' has become some kind of credible maintainer of the work). > > They can easily make huge errors, since they may or may not understand the material properly. Imagine changing the command 'rm -rf *.bak' to 'rm -rf *' in some programming book. Catastrophic but only a tiny change lexically. > > I believe that the only versions of a document (like a spec or a book) that should be circulated under the original author's name should be ones containing errata that have been checked by that author. This is the case for example with the Antlr4 book I bought as a PDF, and for which I can download updated PDFs containing errata fixes - from the original author site (Pragmatic Programmers). --- ## Post #17 by @thomas.beale A few thoughts from where we are today in 2026. We have trademark protection for Europe, US and I think Australia, not sure about India (we need to think about India!), and not in China (but we don’t expect to). That’s worth quite a lot, and I would now say that the CC-0 / FHIR approach makes at least some sense to contemplate. Anyway, requirements first… here’s what we need today, IMO: * **protection of specifications:** abstract specs and models are copyright openEHR Foundation, with a minimal license that allows any kind of use, EXCEPT republication under the openEHR name. The trademark protection theoretically (and we assume practically / legally) achieves this. * so if you want to take say UML models or BMM files or whatever, and modify them to your ‘openEHR-flavoured'-but-not-exactly-openEHR’ system, go for it - but you can’t publish those models as ‘openEHR’ * it is essential that specifications, including ITS artifacts, are change managed and published only by the official body (SEC), otherwise there is no accountability * **ITS artifacts** should be under a friendly license: developer level artefacts from the specifications program (OpenAPI files, XML schemas, JSON schemas etc) should be usable by industry, not viral, and just require attribution and maintenance of original copyright where appropriate. * → Apache 2.0 and if we want, MIT as well * **archetypes stay open**: the key to interop is for archetypes to be shared. So for the ones that openEHR creates, we may want to keep CC-BY-SA * this doesn’t mean that there can’t be commercial / closed source archetypes; people can create what they want outside of the published (and usually publicly funded) open archetypes * it is essential that openEHR archetypes are change managed and published only by the official body (CPB), otherwise there is no accountability * **AQL queries**: we have not considered what it would be like to have a proper library of reusable queries, but we really should; they are the drivers of CDS, analytics, reporting etc. I would see them like archetypes: CC-BY-SA if published by an open / public org. * **templates are fair game**: openEHR and public bodies might publish templates (e.g. for IPS) with an open license, but vendors and provider IT depts routinely make their own, including secret sauce, UI workflow trick etc - they should be able to do so, including based on openEHR ones, e.g. an improved IPS template * any template from openEHR would be CC-BY, or maybe Apache 2 * **software** should be industry-friendly, usually this means Apache 2.0; some orgs allow the user to choose Apache or MIT. * **Abandoned IP**: we have the known issue of IP from work efforts that have stopped, and are currently blocking reuse due to the ND license. This would be solved by dropping ND, and converting those specs in question to CC-0, as I believe has been agreed. In the future, this problem would no longer arise. So in the above regime, there should be nothing stopping Better (for example) using anything they want to build a closed source tool like Archetype Designer, and publishing only the built tool. As they have. And with a solution to the abandoned IP problem, those of us who care to can take over IP that is currently sitting around doing nothing. --- ## Post #18 by @siljelb [quote="thomas.beale, post:17, topic:11697"] **archetypes stay open**: the key to interop is for archetypes to be shared. So for the ones that openEHR creates, we may want to keep CC-BY-SA * this doesn’t mean that there can’t be commercial / closed source archetypes; people can create what they want outside of the published (and usually publicly funded) open archetypes * it is essential that openEHR archetypes are change managed and published only by the official body (CPB), otherwise there is no accountability [/quote] For openEHR-published archetypes, I'd still like to argue for some kind of dual licensing based on the actual intended use, for example something like this: ``` SPDX-License-Identifier: CC-BY-SA-4.0-or-later OR Apache-2.0-or-later # Dual License Notice # Derivative information models created from this content are governed by # Creative Commons Attribution ShareAlike 4.0 International or any later version. # Use of this content within software systems is governed by # the Apache License 2.0 or any later version. # Users must apply the license that corresponds to their intended use. ``` Hopefully this could alleviate some of the worries about using archetypes in proprietary software. [quote="thomas.beale, post:17, topic:11697"] **AQL queries**: we have not considered what it would be like to have a proper library of reusable queries, but we really should; they are the drivers of CDS, analytics, reporting etc. I would see them like archetypes: CC-BY-SA if published by an open / public org. [/quote] I agree any openEHR-published AQL queries should be licensed in the same way as archetypes. [quote="thomas.beale, post:17, topic:11697"] **templates are fair game**: openEHR and public bodies might publish templates (e.g. for IPS) with an open license, but vendors and provider IT depts routinely make their own, including secret sauce, UI workflow trick etc - they should be able to do so, including based on openEHR ones, e.g. an improved IPS template * any template from openEHR would be CC-BY, or maybe Apache 2 [/quote] I think any openEHR-published templates should also be dual-licensed like I suggested for archetypes above. --- ## Post #19 by @ian.mcnicoll The dual-license idea is new to me , and TBH I did not quite understand how it applied, but it makes sense now, and I think it is well worth considering. I guess my only concern is that (versus going to CC-0) it might be quite hard to explain to the risk-averse. It definitely solves the problem, but might still scare folks off. @Thomas - I get your point about ‘protecting’ official archetypes from being forked and re-presented as ‘official openEHR’. I would have thought we can use the same approach as FHIR re Trademarking that you described. As you say, the CC-BY-ND => CC-0 change has been accepted in principle by CIC and Foundation. The document that prompted this thread was really just proposing the formal process by which this should be done, to ensure community awareness of the proposal. FWIW,m in regards to going for CC-0 generally for specifications, I spoke to Rachel about Trademark progress a few months ago on whether we are in a position to make that jump, and she felt not quite yet, but it is certainly under active review by the Foundation. --- ## Post #20 by @siljelb [quote="ian.mcnicoll, post:19, topic:11697"] I guess my only concern is that (versus going to CC-0) it might be quite hard to explain to the risk-averse. [/quote] I don't think it's that difficult tbh? If you're publishing an information model, whether an openEHR archetype or template, or using another formalism, follow CC-BY-SA 4.0 or higher. If you're publishing software, whether open source or proprietary, follow Apache 2.0 or higher. --- ## Post #21 by @ian.mcnicoll I like the idea and dont’t really disagree but I’m also aware that whilst It is not hard for people who are used to thinking about software licenses and copyright, it can raise a lot of questions from those who are not in this world. I’m just questioning the residual benefit of the SA clause (assuming we can protect the ‘branding’ with trademarks). Until that point, I like the idea of dual-licensing. --- ## Post #22 by @thomas.beale [quote="siljelb, post:20, topic:11697"] If you’re publishing an information model, whether an openEHR archetype or template, or using another formalism, follow CC-BY-SA 4.0 or higher. If you’re publishing software, whether open source or proprietary, follow Apache 2.0 or higher. [/quote] Silje, I have nothing at all against the dual license you propose, but I’m not clear on what problem it’s solving. Let’s say DIPS build some proprietary software (as they do), and incorporate openEHR archetypes, make some specialisations, templates etc. Are you saying they should put Apache 2.0 on the reused and specialised (derivative) archetypes rather than CC-BY-SA? Fine by me, but it’s actually more work isn’t it? Wouldn’t it just be easier to leave the default CC-BY-SA 4.0 notice intact, and copy it to any other archetypes they create, that specialise those archetypes? You’ve probably already answered this, but I have not reread everything in this rather voluminous thread and previous 10yo discussions, so sorry if you repeat yourself ;) --- ## Post #23 by @siljelb My reasoning is that since CC-BY-SA is a copyleft license, you can't publish proprietary derivative works, for example proprietary software including a CC-BY-SA archetype. Apache2 on the other hand is a permissive license, which does allow you to do just that. The openEHR Foundation IIRC has said that it's not going to pursue anyone using CC-BY-SA archetypes in proprietary software, but technically it could, which is the problem. There's also the factor of CC licenses being geared towards creative works and not software ([CreativeCommons itself uses MIT](https://github.com/creativecommons) for most of its own software development), but I think that's a minor point. Edit: Btw, my reasoning is based on the assumption that software using an archetype is a derivative work of that archetype. --- ## Post #24 by @thomas.beale [quote="siljelb, post:23, topic:11697"] Edit: Btw, my reasoning is based on the assumption that software using an archetype is a derivative work of that archetype. [/quote] I think this might be questionable (this is where the kind of IP we are talking about doesn’t match creative works very well.). But specialisations of published archetypes certainly are, so your reasoning is right at least on that anyway. If we do the dual license, I was just thinking about the wording that would go with it. We might want to adjust your proposed text a bit to make it clearer what the rules / choices are around: NB: the following license choices are for openEHR-published artifacts; de novo artifacts of the same kind within companies or govts can be whatever they want. * openEHR archetypes (top-level and specialised) - changed versions are only made through the governance process anyway, so that’s not an issue * we need the dual license here, since we want to allow further ‘derivatives’ to be non-viral * specialised archetypes made by vendors or other developers - which are derivatives * CC-BY-SA (if you want to make your brilliant specialisation *the* standard for that thing) or Apache 2.0 (your specialisation contains secret company tricks) or proprietary - *this is just advice, we’re not talking about archetypes published by openEHR here* * openEHR templates - I’m inclined to just say Apache 2.0, since otherwise we waste a lot of time trying to figure out whether ‘derivative’ as defined for creative works applies or not I’m wondering if we lose anything if we just move to Apache 2 for everything… --- ## Post #25 by @siljelb [quote="thomas.beale, post:24, topic:11697"] openEHR templates - I’m inclined to just say Apache 2.0, since otherwise we waste a lot of time trying to figure out whether ‘derivative’ as defined for creative works applies or not [/quote] The way I understand this, a template made from archetypes is a derivative work of those archetypes, in the same way as a specialisation is derivative. --- ## Post #26 by @thomas.beale [quote="siljelb, post:25, topic:11697"] The way I understand this, a template made from archetypes is a derivative work of those archetypes, in the same way as a specialisation is derivative. [/quote] It probably is - a template is like a rap track sampling bits of rock or classical ;) --- ## Post #27 by @pablo [quote="siljelb, post:23, topic:11697"] software using an archetype is a derivative work of that archetype. [/quote] From what I read, “using” is not “derivative” work, I have asked this on the original thread. [quote="siljelb, post:25, topic:11697"] template made from archetypes is a derivative work [/quote] That could be if more constraints are defined. In other cases it would be usage or reference only. --- ## Post #28 by @thomas.beale [quote="pablo, post:27, topic:11697"] That could be if more constraints are defined. In other cases it would be usage or reference only. [/quote] you see, we’re already debating whether it is or isn’t! My conclusion from having gone though all the CC legal documention over the last couple of years to determine exactly what is a ‘derivative’ or not was that CC just doesn’t apply that well to technical artifacts that have a) lifecycles and b) tooling frameworks that do source → combine → compile → deploy and similar. We initially decided to use CC licenses for archetypes because we used them for the specifications. If we are rethinking this whole thing, we maybe should just do trademark + Apache 2 for everything, especially as even the abstract specs have computable models in them (BMM, previously UML). --- ## Post #29 by @pablo [quote="thomas.beale, post:28, topic:11697"] just doesn’t apply that well to technical artifacts that have a) lifecycles and b) tooling frameworks that do source → combine → compile → deploy and similar. [/quote] I’m certainly not 100% sure about that. From what I understand those CC licenses apply to authored works that are protected by copyright like literature, music, film, etc. and those are as technical as you can get, need tooling (hardware and software) and tool chains to put them together in some kind of process, very similar to combine → compile → deploy. So the analogy, at least for me, doesn’t seem to apply here. I see archetypes as similar authored works, that can be modified, extended, mixed, etc. and I would call that derivative work. Though if a software USES the archetype, the software isn’t derivative work, even if the software is designed to do any work to generate the derivative work: it’s the result what’s derivative. At least that’s what I understand. For the specs themselves, I think you can see those as some kind of specific literature, though the authors and who holds the IP are different entities. So, related to the question I asked in the original thread that referenced this one: if we create a RM package that uses/references some of the existing RM classes, I don’t think that’s derivative work, because is a reference: it doesn’t change the original thing, just uses it. Is like using the ISO 8601 date format spec: you reference to it and use it, but you don’t change the spec in any way. This is also personal interpretation. Though formal confirmation from the openEHR Foundation would be nice. --- ## Post #30 by @siljelb [quote="pablo, post:29, topic:11697"] Though if a software USES the archetype, the software isn’t derivative work, even if the software is designed to do any work to generate the derivative work: it’s the result what’s derivative. At least that’s what I understand. [/quote] I think I see what you mean now: The Archetype Designer uses an archetype to generate an OPT, but *isn't* derivative. While a medication module incorporating a set of OPTs generated from archetypes *is* derivative. Is that what you meant? --- ## Post #31 by @thomas.beale [quote="pablo, post:29, topic:11697"] I’m certainly not 100% sure about that. From what I understand those CC licenses apply to authored works that are protected by copyright like literature, music, film, etc. and those are as technical as you can get, need tooling (hardware and software) and tool chains to put them together in some kind of process, very similar to combine → compile → deploy. So the analogy, at least for me, doesn’t seem to apply here. [/quote] You are right about all the modern tools. But the difference I was getting at is there is still (mostly, with a few exceptions) a single ‘final version’, whether of a song, book or artwork. In software and information engineering, we don’t have a definitive version, we have a release cycle and multiple versions each containing (we hope) constant improvement. Whereas Taylor Swift puts out her new album and moves on to the next one. Creative Commons is all about determining and protecting rights on these kinds of artifacts. And the idea of a ‘derivative’ of such artworks is intended to say whether you have acceptably reused some copyrighted bit of music in your new mashup video. For us in the tech world, ‘derivatives’ aren’t exceptions, they’re really just ‘use’, and the norm. [quote="pablo, post:29, topic:11697"] For the specs themselves, I think you can see those as some kind of specific literature, though the authors and who holds the IP are different entities. [/quote] That is how I (and I assume some others) have historically thought about them. But they are still constantly improved and versioned. There’s no single copy of the EHR Information Model spec you can get, in the way you can get a copy of Dorian Grey at the bookshop. And specs are increasingly generated from semi-computable and computable source files, which are directly ‘usable’ by tools. [quote="pablo, post:29, topic:11697"] Is like using the ISO 8601 date format spec: you reference to it and use it, but you don’t change the spec in any way. [/quote] We change our specs all the time - that’s what all the releases are. ISO is just glacially slow at that kind of process! For the above reasons I now think that CC isn’t a great fit, even for the specifications (and I do love the whole Creative Commons project… but we need to serve our own needs as well). --- ## Post #32 by @pablo @siljelb in terms of the software, yes. It's like a audio mixing or video editing software: the software itself isn't derivative but the result could be. I don't think using a template somewhere is derivative, though the template must of the time is derivative work from archetypes drive new constraints are applied on top to create the template. For instance using a template to feed CDS rules IMHO isn't derivative work, is usage. The difference between that and the archetype-template relationship is the latter uses the same base elements and had the same goal, and the template can't exist without the archetype. Though the CDS rule had logic that can live independently from templates and archetypes, and using them is just a design decision. I know there is a grey area, that's why the Foundation should clarify and formally day what's what. Best Pablo. --- ## Post #33 by @siljelb [quote="thomas.beale, post:31, topic:11697"] For the above reasons I now think that CC isn’t a great fit, even for the specifications (and I do love the whole Creative Commons project… but we need to serve our own needs as well). [/quote] While we may or may not agree about the fitness of the CC licenses for the works in question, relicensing them is not trivial. Especially getting contributor approval would be next to impossible for archetypes. That is, unless we have a contributor license agreement (CLA) which permits relicensing, which I don't think we do. With that in mind, we're likely stuck with CC-BY-SA. I would hope though that we could get away with applying a dual license or at worst a clarifying exception to the -SA clause, since the intent has never been to prohibit using archetypes in proprietary software. Something along these lines? > *For the purposes of the Creative Commons Attribution Share Alike 4.0 International License applied to openEHR information model source files, the following rule applies.* > > The following artefacts are **not** considered Adapted Material or derivative works: > > * Operational Templates (OPTs) generated from archetypes or templates > * Flattened or compiled representations of templates > * User interface definitions or forms generated from templates or OPTs > * JSON schemas, XML schemas, code, or other technical artefacts automatically generated by tooling > * Runtime artefacts produced by software systems using the models > * Clinical data or other content created within systems that implement the models > > These artefacts may be licensed and redistributed under the **Apache License 2.0**, and no Share Alike obligation is applied to them. > > Changes to archetypes, templates, or other model source files themselves remain subject to the CC BY SA 4.0 license and must be shared under the same license. --- ## Post #34 by @pablo [quote="siljelb, post:33, topic:11697"] Operational Templates (OPTs) generated from archetypes or templates [/quote] Let me reason on that: OPTs generated are a form of aggregating what we already have, kind of a different format that expresses the same thing (semantically) as existing artifacts but do not change them. Though semantically it’s the same thing, just in a different format. I’m really bad with analogies, though isn’t that like changing a song from WAV to MP3? It’s a different format but it’s the same song and the copyright is in the song, not in the format (though formats might have their own IP and licensing, like JSON or XML could have, or even ADL). It’s the same with Flattened/compiler representations of templates. Though user interface definitions is another layer that might use templates and archetypes, but it’s about the USE, it’s not the same thing semantically speaking. --- ## Post #35 by @thomas.beale [quote="siljelb, post:33, topic:11697"] Something along these lines? [/quote] This is pretty good. Maybe we can get away with listing fewer downstream artifact types, but something like this would work. [quote="pablo, post:34, topic:11697"] I’m really bad with analogies, though isn’t that like changing a song from WAV to MP3? It’s a different format but it’s the same song and the copyright is in the song, not in the format (though formats might have their own IP and licensing, like JSON or XML could have, or even ADL). [/quote] Templates are like those bad compilation albums from the 70s that mashed together ‘ballads’ or ‘love songs’ or whatever ;) --- ## Post #36 by @pablo [quote="thomas.beale, post:35, topic:11697"] Templates are like those bad compilation albums from the 70s that mashed together ‘ballads’ or ‘love songs’ or whatever :wink: [/quote] That’s a good analogy, and I think both are derivative: template and OPTs (OPTs is just a different format). --- ## Post #37 by @erik.sundvall I think the contageous -SA part should be dropped for everything new we make from now on (using CC0 or Apache 2 would be even better). **Reason:** SA+waivier/explanations is more confusing and can be worked around anyway as I described in 2011 in https://openehr.atlassian.net/wiki/spaces/oecom/pages/6127649/Archetype+licensing+-+the+case+for+CC-BY-SA?focusedCommentId=6127957 and never got a satisfying logical reply to: > A little scenario to consider: > > 1. A multilingual java-based EHR GUI made by company A may contain every logical and structural requirement from an archetype (compiled as java code) in order to produce nice RM instances and explain the contained archetypes to curious users. > > According to the suggested SA-waivier-modification I assume this GUI could be released under any license, e.g. Apache 2. > > Yes or No? > > 2. Company B later makes a program that analyses company A's open source GUI and via reverse engineering recreates the original archetype and serialises it in an openEHR compatible ADL- or XML form that is logically equivalent to the original archetype. > > Is this reverse-engineered archetype bound by openEHRs original CC-BY-SA license claims? > > Yes or no? > > If yes, then company A's code was obviously SA-contagious and the wavier was not worth much as a comfort. > > If no, then the CC-BY-SA of the original archetype is fairly easily circumvented (so one might just as well use CC-BY in the first place and skip all the confusing wavier and copyright assignment stuff, and use better means to fight bad copyright claims). If it is hard to get permission to relicense some existing archetypes (e.g. because it is hard to reach contributors/authors) then adding the dual license (suggested by @siljelb) to those archetypes might be a step in the right direction. --- ## Post #38 by @siljelb [quote="erik.sundvall, post:37, topic:11697"] 1. A multilingual java-based EHR GUI made by company A may contain every logical and structural requirement from an archetype (compiled as java code) in order to produce nice RM instances and explain the contained archetypes to curious users. According to the suggested SA-waivier-modification I assume this GUI could be released under any license, e.g. Apache 2. Yes or No? [/quote] Yes, per my "The following artefacts are **not** considered Adapted Material or derivative works:" list above. Does it need to be logical if it's clearly stated? [quote="erik.sundvall, post:37, topic:11697"] 2. Company B later makes a program that analyses company A’s open source GUI and via reverse engineering recreates the original archetype and serialises it in an openEHR compatible ADL- or XML form that is logically equivalent to the original archetype. Is this reverse-engineered archetype bound by openEHRs original CC-BY-SA license claims? Yes or no? [/quote] Tbh I think this is a bit far fetched. But since the new artefact is in fact *not* based on the CC-BY-SA licensed artefact but on source code licensed under some other OS license, it would not be affected by the CC-BY-SA license. So no. [quote="erik.sundvall, post:37, topic:11697"] If no, then the CC-BY-SA of the original archetype is fairly easily circumvented (so one might just as well use CC-BY in the first place and skip all the confusing wavier and copyright assignment stuff, and use better means to fight bad copyright claims). [/quote] Sure, but why would anyone want to go through all that just to be able to publish an archetype (as an archetype and not as any of the downstream artefact mentioned in my list above) under a license other than CC-BY-SA? I think I've said this before somewhere, but IMO the greatest benefit of the -SA clause (or any other copyleft license) for archetypes is that all CKMs and other repositories in the "openEHRosphere" *use the same license*. If one repo used GPL, another Apache2 and a third CC-BY-NC, it would create huge barriers to sharing models to the point where it just wouldn't be worth the hassle. (Edit: When we created the Norwegian CKM back in 2014, we did have a small discussion about which license would be the best for our purposes. It was a very short discussion, because of the -SA clause of the international CKM. If the international CKM had been CC-BY at the time, we could have ended up with GPLv3, the European Union Public Licence or something else, which could have become a huge spanner in the collaboration works) The discussion in your link touched upon another point though; how do we handle the "attribution" clause which is part of most open source licenses including CC-BY-SA. Do every archetype need to be attributed explicitly? Or even every contributor for every archetype? 😱 IMO it would be enough to attribute the source repository(ies) with name and URL, but the main point I guess is that this should be made explicit of our licensing information which I don't think it currently is. --- ## Post #39 by @erik.sundvall [quote="siljelb, post:38, topic:11697"] Sure, but why would anyone want to go through all that just to be able to publish an archetype (as an archetype and not as any of the downstream artefact mentioned in my list above) under a license other than CC-BY-SA? [/quote] Nowadays with AI assisting in coding _"go through all that"_ is just a matter of likely less that one day's work in order to create a reusable tool that then in seconds can be used to go from e.g. ADL to code/software (for example template specific classes) and back to ADL for any archetype. Somebody could argue that even reading the archetype into an object representation via [Archie](https://github.com/openEHR/archie) (then perhaps storing and then retrieving the object representation if one wants to be picky) and then serializing it again into ADL could be a variant of the above. Thus the -SA is very easy to circumvent when downstream artifacts are not bound by -SA. I think FHIR did a smart thing with CC0 that even got rid of the attribution problems. Trying to use license to enforce coherence is likely the wrong tool. Better tools are: - community building - openness to several use case requirements from many actors - education efforts regarding the stupidity and shortsightedness of unnecessarily forking modelling efforts --- **Canonical:** https://discourse.openehr.org/t/licensing-of-specifications-and-archetypes-discussion-from-2015/11697 **Original content:** https://discourse.openehr.org/t/licensing-of-specifications-and-archetypes-discussion-from-2015/11697