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.
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?
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?
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.
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?
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?
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.
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.
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+ protocol. An example can be found here: http://www.nysenate.gov/copyright-policy.
Mockup:
All artifacts published on this site are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. 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.
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.
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 License - FHIR v5.0.0 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: Licenses for Documentation
//Erik
P.s. You might find the following discussions interesting:
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 License - FHIR v5.0.0 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: Licenses for Documentation
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).
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.
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.
I agree any openEHR-published AQL queries should be licensed in the same way as archetypes.
I think any openEHR-published templates should also be dual-licensed like I suggested for archetypes above.
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.
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.
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
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 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.
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…
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.
