# License and copyright of archetypes **Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153) **Created:** 2009-09-01 11:10 UTC **Views:** 1 **Replies:** 28 **URL:** https://discourse.openehr.org/t/license-and-copyright-of-archetypes/14934 --- ## Post #1 by @system Dear all, These days I have been thinking about the legal issues involving the use of existing archetypes. I have seen that openEHR archetypes available on the Clinical Knowledge Manager are all "Copyright (c) 200X openEHR Foundation". But, what does this exactly implies? I can download them freely, but can I use them in a commercial environment? Must I make public specialized archetypes or adaptations from them? Obviously, "I" is not me but anybody :-) I have searched the openEHR page and wiki but I have not found anything about this topic, just a point in the copyright notice of the specifications linking to the non-existing page [http://www.openehr.org/free_commercial_use.htm](http://www.openehr.org/free_commercial_use.htm) I think it would be good to start a discussion about licensing. I'm not talking about open source implementations, but about the archetype artifacts that anyone can develop. A first approach that can be made is the use of a Creative Common license. I think that one of them can fit the interests of the openEHR community. In my opinion, the main aspects that a license for archetypes must cover are: - To maintain the attribution to the original author (the openEHR Foundation or whoever) - To allow a commercial use of archetypes (like or not, health is a business) - To allow modifications and derivations of the archetype. - On behalf of the openEHR community, the new derived archetypes should be made public with the same conditions. This is arguable and could be eliminated. As I said, one of the Creative Commons licenses covers all this properties. It is the Attribution Share Alike license: "This license lets others remix, tweak, and build upon your work even for commercial reasons, as long as they credit you and license their new creations under the identical terms. This license is often compared to open source software licenses. All new works based on yours will carry the same license, so any derivatives will also allow commercial use." [http://creativecommons.org/about/licenses](http://creativecommons.org/about/licenses) Finally, this leads to a secondary point. Maybe, the "copyright" attribute of an archetype should be renamed to "license" to best fit the conditions of usage of archetypes. What's your opinion? --- ## Post #2 by @thomas.beale There is now a page for discussing this - [http://www.openehr.org/wiki/display/oecom/Archetypes+-+Copyright+and+Licensing](http://www.openehr.org/wiki/display/oecom/Archetypes+-+Copyright+and+Licensing) - thomas beale David Moner wrote: [details="(attachments)"] ![OceanC\_small.png|74x72](upload://5I367QG2SMJUp18Pt3jF6yz13Ey.png) [/details] --- ## Post #3 by @system Ok, that page didn't appear to me because I was not logged in the wiki when I made the search :-) It is good to see thar there are discussed more or less the same points as in my mail. Best regards, David 2009/9/1 Thomas Beale <[thomas.beale@oceaninformatics.com](mailto:thomas.beale@oceaninformatics.com)> [details="(attachments)"] ![OceanC\_small.png|74x72](upload://5I367QG2SMJUp18Pt3jF6yz13Ey.png) [/details] --- ## Post #4 by @system I'm not an expert at all about licenses (and in fact, the more I read about them, the less I understand :-) As far as I know, CC licenses are in fact a kind of "copyright clauses". The copyright we all know is that of "all rights reserved". This includes the attribution right, the use right, the copy right, the distribution right and all that you can imagine. A CC license always maintains the attribution right but allows to transfer some other rights if you wish: distribution, modification and commercialization. So, I understand that the use of copyright + CC is something like "some rights reserved" (which are all those not covered by the CC). For example, one of those reserved rights is the ability of the author to re-license his work or a new version of it. As you say, the best solution seems to be having both to assure the right of the authors and to show clearly how archetypes can be used (those from the CKM or any other public archetype repository). As I said in my previous mail, this will require to add a "license" field to the archetype description section to include it. Best regards, David 2009/9/9 Sam Heard <[sam.heard@oceaninformatics.com](mailto:sam.heard@oceaninformatics.com)> [details="(attachments)"] ![OceanC\_small.png|74x72](upload://5I367QG2SMJUp18Pt3jF6yz13Ey.png) [/details] --- ## Post #5 by @tonyshannon Hi David Thats one of the best explanations of the CC licences I have seen Thank you Tony Dr\. Tony Shannon Consultant in Emergency Medicine, Leeds Teaching Hospitals Clinical Lead, Clinical Content Service, NHS Connecting for Health Chair, Clinical Review Board, openEHR Foundation \+44\.789\.988 5068 tony\.shannon@nhs\.net David Moner wrote: --- ## Post #6 by @erik.sundvall Hi\! Sam, I remember we've had similar discussions earlier both on\- and off\-list, and I believe the result was that CC\-BY was clearly the least encumbering and most suitable option for archetype licensing\. When it comes to copyright I think you might have misunderstood some things and David's interpretation below seems more correct\. There is no conflict between Copyright and CC\-licences\. Best regards, Erik Sundvall erik\.sundvall@liu\.se \(previously erisu@imt\.liu\.se\) http://www.imt.liu.se/~erisu/ Tel: \+46\-13\-227579 --- ## Post #7 by @Tim_Cook2 We can have all the fun and interesting discussions we want\. What we need is a statement from the Board of Directors\. I do not know what the laws in England require, but in most countries the BoD of organizations have to produce minutes of at least annual meetings to their membership\. I can't recall ever seeing anything to that effect\. Either way, the statement on the page at: http://www.openehr.org/about/bod.html says: "The openEHR Board oversees the proper functioning of the openEHR Foundation with respect to its charter and status as a not\-for\-profit organisation\." I believe that this issue falls under the concepts of proper functioning since the IP rights of donated artifacts are at stake here\. IMHO; the BoD needs to make a firm statement so that anyone donating time to the openEHR Foundation knows what they are donating to\. \-\-Tim --- ## Post #8 by @erik.sundvall Hi\! Thanks for bringing this up on the list as a more fundamental and general question Tim\. In addition to the archetype licencing some of us have a problem with the specification related licenses, they ought to be CC\-BY \(or similar well recognised and unencumbered license\) so that images, texts, definitions, UML\-files etc can be used by anyone, including commercial companies without the hassles of getting or understanding additional licenses etc\. I don't see how the openEHR foundation or it's informal community could lose anything by a broad change to CC\-BY for public artifacts\. I think Thomas Beale once said that CC\-BY was not that widespread and familiar when the specifications were first published but that CC\-BY could have been a logical choice nowadays\. Correct me if I'm wrong\. > From previous discussions om amd off list I sensed that some people might lose a \(false/illusionary\) "feeling of control" if "opening up" licensing\. What is approved/certified by a board \(ARB, CRB etc\) or not will still be very clear after changing to a more open, recognized and familiar licence\. Already today someone can copy or at least closely imitate openEHR\-approaches without openEHR having time/resources to legally stop it in every country\. The question is why anybody would care to do such an imitation instead of the original and why any country would be committing to use such a system\. So why fear? When is the next Board of Directors meeting? :\-\) Best regards, Erik Sundvall erik\.sundvall@liu\.se \(previously erisu@imt\.liu\.se\) http://www.imt.liu.se/~erisu/ Tel: \+46\-13\-227579 --- ## Post #9 by @erik.sundvall Hi Stef\! > Personally I would like to advocate a CC\-BY\-SA license: everybody is allowed > to use and modify the content as long as they attribute the author \(BY part\) > and if If one alters, transforms, or builds upon this work, one may > distribute the resulting work only under the same or similar license to this > one \(SA part\)\. For more > information: http://creativecommons.org/licenses/by-sa/2.0/ In many cases I like the idea of SA \(Share Alike\) as a way of spreading \(forcing?\) openness to more areas, especially when it comes to certain software settings, but regarding the openEHR specifications and archetypes I'd suggest using just CC\-BY \( http://creativecommons.org/licenses/by/3.0/ \) in order to avoid hard questions regarding what "non\-open" things are to be regarded as derivative works, see examples below\. We probably want openEHR to be used in all kinds of mixed private/public settings\. In august 2008 I some of us had an off\-list discussion regarding archetype licensing I quote myself \(since I do not know if I have permission to quote others in that discussion\), note that the quoted text below regards archetypes, not the openEHR specifications\.\.\. "What kind of value do you believe the SA requirement will add in the case of archetypes? SA does not require you to actively submit anything to any process, just to license your derivative work under the same license to whoever happens to get hold of it somehow\. People will submit works to a any review processes they find valuable, and most likely that will include openEHR's public process\. Requiring SA in addition to BY might add value or it might mostly add complications and hard\-to\-interpet situations regarding what a derivative work is\. Is data entered using the archetype a derivative work? Is a template or screen\-form based on the archetype a derivative work? Is a book using the archetype in an example a derivative work? A specialization of an archetype intended for top\-secret medical research is most likely a derivative work, is that a problem or not? It is issues like these that get companies uneasy regarding using things with SA\-licencing\-schemes \(such as GPL\) in some situations\. Another question is if SA is necessary in an openEHR\-based health record exchange system\. If you want to exchange archetyped data you're probably in most cases requested to supply the used archetype too anyway\. There may very well be good things in having BY\-SA instead of only BY, but could you please clarify what you had in mind?" \.\.\.that ends the quote from 2008\. Regarding the specifications additional questions like these arise with SA: \- Can you write a commercial \(i\.e\. a non CC\-BY\-SA\) book or commercial presentation slides about openEHR? \- Is an openEHR software implementation based on stubs autogenerated from openEHRs UML files to be considered a derivative work that can not be "closed" source code? Can it be released under e\.g\. Apache, MIT, or BSD license or not? Best regards, Erik Sundvall erik\.sundvall@liu\.se \(previously erisu@imt\.liu\.se\) http://www.imt.liu.se/~erisu/ Tel: \+46\-13\-227579 --- ## Post #10 by @Koray_Atalag Hi openEHRers, Why don't we get professional help in this? It is obvious that there is a myriad of licenses etc. But I think the intention is clear: creating high quality archetypes and sharing - without limitation of any kind. That simple! Any business model whatsoever related with IPR has to do with the products/services, not the content. Make sense? Also I believe the reason that this copyright issue has been brought up after all these years is because we operate on openness and trust - let's keep it this way. Cheers, -koray Erik Sundvall wrote: --- ## Post #11 by @thomas.beale Morally I am all for the CC-BY approach. My practical questions are: - What does 'remix' really mean? We don't want people adapting an archetype with a given identifier, and putting it out without the identifier changed as well, according to emerging governance rules. This would be against the interests of the community (i.e. it will drive people crazy) - see [http://creativecommons.org/licenses/by/3.0/](http://creativecommons.org/licenses/by/3.0/) - Naturally, I am all for people 'adapting the work' - as long as the new version has a new appropriate identifier. - is a new 'identifier' in our technical domain the equivalent of a new title or somesuch? - what copyright statement should be included then? We still have the problem of deciding who to copyright a work to, when the work was the result of a group. - SEE PARTICULARLY HOW the FSF people do this: [http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright](http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright) In more detail (from [http://creativecommons.org/licenses/by/3.0/legalcode](http://creativecommons.org/licenses/by/3.0/legalcode))..... - CC-BY is saying that "**THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW**. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED." - see also: "**2. Fair Dealing Rights.** Nothing in this License is intended to reduce, limit, or restrict any uses free from copyright or rights arising from limitations or exceptions that are provided for in connection with the copyright protection under copyright law or other applicable laws." - see also 4b: "If You Distribute, or Publicly Perform the Work or any Adaptations or Collections, You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice...." So we have two questions to resolve: - how to ensure a modified archetype is not published under its old id (which just messes up life for everyone); this does not seem to be well addressed anywhere; - what name to put in a copyright notice; possible solution to this one: - for group-developed archetypes e.g. in CKM environment, make it openEHR.org or the relevant host organisation, e.g. if it were the Swedish government, they might put 'copyright 2009 SocialStyrelsen (Swedish National Board of Health and Welfare)'... - for individual submissions provided largely developed, particularly specialist archetypes, allow the copyright to be the original author, unless they prefer to cede it to openEHR.org or some other organisation (e.g. they might want to put 'copyright 2009 Royal College of General Practitioners' on it - no reason not to allow that as far as I can see). In the end, I think David Moner's general description is a very good way of seeing it: paraphrasing - Q what is an xxx license? A: something you use to 'unreserve' some rights that would normally default to copyright law. So it is the license that takes care of most of the rights we practically care about. - thomas beale Erik Sundvall wrote: [details="(attachments)"] ![OceanC\_small.png|74x72](upload://5I367QG2SMJUp18Pt3jF6yz13Ey.png) [/details] --- ## Post #12 by @Stef_Verlinden1 Hi Thomas, Good points. I guess we need a good IP laywer after all:-) Maybe we should come up with some sort of a hybrid model in which the openEHR identifiers have a 'good old' restricted copyright and must be seen separately from the content of the actual archetype. This content falls under the CC-BY licensed and can be modified etc. as long as the unique openEHR identifier isn't used. Cheers, Stef --- ## Post #13 by @system Some idea's Maybe something like a domain\-authority which guards the identifiers and its versions, or maybe even incorporate the creators IP\-domain\-name in the identifier? So openEHR\-EHR\-OBSERVATION\.blood\_pressure\.v1 would become \(in my case\) something like: rosa\.nl\.openEHR\-EHR\-OBSERVATION\.blood\_pressure\.v1 Also I would like to see added is a checksum of thje archetype\-ID and some other important parts in the archetype, to guarantee that a license is still original in its version, and the copyright notice did not change\. The disadvantage is that the specs have to change, I would prefer it to have in version 1\.\* of the OpenEHR\-specs But there are many advantages, it gives free use and possibility to change archetypes to anyone, it gives the possibility for a company to have the arhetypes licensed in other ways\. regards, Bert Verhees --- ## Post #14 by @thomas.beale Bert Verhees wrote: > ``` > Some idea's > > Maybe something like a domain-authority which guards the identifiers and > its versions, or maybe even incorporate the creators IP-domain-name in the > identifier? > > So openEHR-EHR-OBSERVATION.blood_pressure.v1 would become (in my case) > something like: rosa.nl.openEHR-EHR-OBSERVATION.blood_pressure.v1 > > ``` or in fact nl.rosa::openEHR-EHR-OBSERVATION.blood_pressure.v1 according to the proposals at [http://www.openehr.org/wiki/display/spec/Development+and+Governance+of+Knowledge+Artefacts](http://www.openehr.org/wiki/display/spec/Development+and+Governance+of+Knowledge+Artefacts) > ``` > Also I would like to see added is a checksum of thje archetype-ID and some > other important parts in the archetype, to guarantee that a license is > still original in its version, and the copyright notice did not change. > > ``` you will see some proposal for MD5 of the whole archetype - I have never thought about checksumming the id alone - is there a precedent for doing such a thing? (Note that Java .jars and .Net 'assemblies' are a useful thing to compare archetypes to in this kind of thinking, even though they are source artefacts at one level - the flat forms are more like the latter binary artefacts). I am interested in any detailed feedback on the above proposals. - thomas beale --- ## Post #15 by @system Thomas Beale schreef: > Bert Verhees wrote: > > > ``` > > Some idea's > > > > Maybe something like a domain-authority which guards the identifiers and > > its versions, or maybe even incorporate the creators IP-domain-name in the > > identifier? > > > > So openEHR-EHR-OBSERVATION.blood_pressure.v1 would become (in my case) > > something like: rosa.nl.openEHR-EHR-OBSERVATION.blood_pressure.v1 > > > > ``` > > or in fact > > nl.rosa::openEHR-EHR-OBSERVATION.blood_pressure.v1 > > according to the proposals at [http://www.openehr.org/wiki/display/spec/Development+and+Governance+of+Knowledge+Artefacts](http://www.openehr.org/wiki/display/spec/Development+and+Governance+of+Knowledge+Artefacts) This proposal is better than mine because it makes it possible to have subdomains, good for big organisations or multi-customer organisations. > > ``` > > Also I would like to see added is a checksum of thje archetype-ID and some > > other important parts in the archetype, to guarantee that a license is > > still original in its version, and the copyright notice did not change. > > > > ``` > > you will see some proposal for MD5 of the whole archetype - I have never thought about checksumming the id alone - is there a precedent for doing such a thing? (Note that Java .jars and .Net 'assemblies' are a useful thing to compare archetypes to in this kind of thinking, even though they are source artefacts at one level - the flat forms are more like the latter binary artefacts). I was indeed also thinking about checksumming more then only the ID, but I was not sure about what to checksum. Why not the complete archetype? I haven't thought about that. There could be an authority that keeps the checksums and ID's so that one could verify if it is an untampered archetype. Such un authortiy could be very lightweight in first instance, because it only does a little thing. Maybe a little price for registering archetypeID's and checksums can raise enough money to keep this going. Later it could also be used for copyright-notices belonging to an archetype, so that one can easy find out what the current copyright-status is. > I am interested in any detailed feedback on the above proposals. Me too. Bert --- ## Post #16 by @erik.sundvall Hi\! > how to ensure a modified archetype is not published under its old id \(which just messes up > life for everyone\); this does not seem to be well addressed anywhere; ID\-assignment, ID\-control and content validation services is probably not the job of a licence to do\. Isn't that rather the job of the publishing organisations \(like the openEHR foundation and national institutions/organisations\)? It's for example technically possible for me to print a book and \(with evil intentions or by stupidity\) assign it an already existing ISBN\-number, that would mess things up for some and not be a nice thing to do\. But how would you check what book a certain ISBN\-number really belongs to and how would you as user or publisher handle the situation? The answer we're looking for is probably not in a licence or contract because that won't stop the "offenders" before they made the mess \(but possibly through legal means some time after the harm is already done\)\. Rather than trying to stop lunatics from creating archetypes with bad/existing IDs we should instead remind users not to trust unknown sources\. > There could be an authority that keeps the checksums and ID's so that > one could verify if it is an untampered archetype\. The authority that publishes an archetype could be the one helping people to verify the content \(by providing downloads or and/or digital signature\)\. The openEHR clinical review board could verify what they themselves have published and the NHS in turn could verify what has been published by the NHS\. We're dealing with digital files here so why not copy the mechanism used to verify the content of software \(e\.g\. linux distributions\): publish file and digital signature \(or possibly checksum\) at the same authoritative place \(the relevant authoring organisation\) and then also copy file and signature to some reliable backup/mirror sites \(for example ibiblio\.org, archive\.org, openehr\.org and openhealthtools\.org\) It does not take a lot of resources for an authoring organisation to run a download site \(a directory on a web server will do\), what is needed is a simple procedural or technical way to stop people from adding two things with the same ID to the site and then some procedures to copy/mirror the content to backup sites\. Best regards, Erik Sundvall erik\.sundvall@liu\.se \(previously erisu@imt\.liu\.se\) http://www.imt.liu.se/~erisu/ Tel: \+46\-13\-227579 P\.s\. Example for tech\-nerds: http://mirrors.ibiblio.org/pub/mirrors/apache/httpd/ \(uses PGP signatures\) --- ## Post #17 by @thomas.beale Erik Sundvall wrote: > ``` > Hi! > > > ``` > > > ``` > > how to ensure a modified archetype is not published under its old id (which just messes up > > life for everyone); this does not seem to be well addressed anywhere; > > > > ``` > > ``` > > ID-assignment, ID-control and content validation services is probably > not the job of a licence to do. Isn't that rather the job of the > publishing organisations (like the openEHR foundation and national > institutions/organisations)? > > ... > Rather than trying to stop lunatics from creating archetypes with > bad/existing IDs we should instead remind users not to trust unknown > sources. > > ``` which is an argument for registered or accredited 'publishers' (as per the current governance proposal). > ``` > > ``` > > > ``` > > There could be an authority that keeps the checksums and ID's so that > > one could verify if it is an untampered archetype. > > > > ``` > > ``` > > The authority that publishes an archetype could be the one helping > people to verify the content (by providing downloads or and/or digital > signature). The openEHR clinical review board could verify what they > themselves have published and the NHS in turn could verify what has > been published by the NHS. > > ``` again - see the proposal - there is a reasonably well described model of how this could work. > ``` > We're dealing with digital files here so why not copy the mechanism > used to verify the content of software (e.g. linux distributions): > publish file and digital signature (or possibly checksum) at the same > authoritative place (the relevant authoring organisation) and then > also copy file and signature to some reliable backup/mirror sites (for > example ibiblio.org, archive.org, openehr.org and openhealthtools.org) > > ``` yep - exactly the idea we had as well. > ``` > It does not take a lot of resources for an authoring organisation to > run a download site (a directory on a web server will do), what is > needed is a simple procedural or technical way to stop people from > adding two things with the same ID to the site and then some > procedures to copy/mirror the content to backup sites. > > ``` yep. So - let's assume that the id problem is solved by the above argument, i.e. a) we assume that neither the license nor the copyright try to legislate on artefact identifiers and b) only authoritative sources can tell you what artefact an id belongs to, and can provide the artefact via a tamper-proof mechanism like an MD5. This just leaves the question of guidelines about who to assign copyright to for group-developed artefacts. My current suggestion would be that it be by default the publisher organisation where the archetype is developed. This would be openEHR.org for international archetypes, and various national organisations for nationally specific archetypes, e.g. sll.se or socialstyrelsen.se for Sweden, nehta.gov.au for Australia and so on. Other than that, it might be a recognised peak body such as rcplondon.org.uk (Royal College of Physicians). There have been questions about whether companies or corporations could create and copyright archetypes. Clearly they can - an archetype is just an instance of a formalism and there is nothing to stop a company creating and owning them. Whether keeping them private serves anyone's purpose (including the developers) seems doubtful, since preventing the use of archetypes prevents data interoperability and querying (openEHR templates on the other hand could reasonably be made as both private and public artefacts). If we could get some agreement on some of the above, we can update the wiki page with a 'community position' and get the openEHR board to endorse it as an official guideline, along with the relevant licenses. One remaining question here is whether we should use CC-BY-SA rather than just CC-BY; the former adds the condition that modified versions must be shared under the same license as the original. If the original is shared under CC-BY-SA (which allows commercial use), then a modified versoin must still be under CC-BY-SA, which still allows commercial use; i.e. it is 'viral', but only in a business-friendly way, while still guaranteeing openness and shareability... or that's my understanding. - thomas beale --- ## Post #18 by @Stef_Verlinden1 Hi Erik, I see your point and agree\. My call for the \-SA extension was based on the idea of reciprocity\. So let's go for CC\-BY\. Cheers, Stef \(I sended this reaction earlier but for an unknown reason only to Eric\. So now for the whole group\. Although I still believe in the idea of reciprocity and would like to advocate for it, a license shouldn't become a hindrance for the broad usage of openEHR archetypes and/or a 'paper tiger' as we call it in the Netherlands: don't create rules which you can't \(or don't want to\) follow up\) --- ## Post #19 by @system Hi Eric An issue that I am concerned about that needs consideration is the Collection\. As a director of the openEHR Foundation, I am concerned that we do not set up a situation where people merely collect or make minor adaptations of an archetype and make it commercially available\. Your concern seems largely to relate to the derivative works\. I believe that the Foundation is only concerned here about derivative archetypes\. I would not consider a form or other coded artefact to be a derivative work of the archetype\. So the 'SA' license is really there to ensure that specialised or adapted archetypes based on openEHR archetypes remain freely available\. I would think we could make a statement to be clear about this on the licensing page\. I am interested in other people's views and I am sure David and Dipak will as well\. Cheers, Sam --- ## Post #20 by @Stefan_Sauermann AGREE\! The target is to keep archetypes available for free\. And to put them under a strict management\. Developers shall then be able to write and sell code and software that uses these managed archetypes\. Developers might be charged a small licensing fee, similar to what you pay when you buy a standard from IEEE or CEN or ISO\. Greetings from Vienna, Stefan Sauermann Acting Program Director Biomedical Engineering Sciences \(Master\) University of Applied Sciences Technikum Wien Hoechstaedtplatz 5, 1200 Vienna, Austria Tel: \+43 \(1\) 333 40 77 \- 988 mobile: \+43 \(664\) 6192555 sauermann@technikum\-wien\.at http://www.technikum-wien.at http://www.healthy-interoperability.at Sam Heard schrieb: --- ## Post #21 by @Richard_Dixon_Hughes Sam, As a lawyer \(among other things\), I felt a burning need to make quick comment; however, I have not had time to refresh my memory on all the details \- but here goes anyway\. As you may be aware, in Australia our copyright law has slightly different terms and interpretations \- so I have to be careful making superficial observations on a topic that many others have studied in considerable depth\. In Australia, we only have "adaptations" but our adaptations cover both the "adaptations" and "derivative works" found under the US Copyright Law \- Title 17 of the US Code\. I am unsure of current British Law in this area although much of our original precedent is based on UK decisions\. In all common law jurisdictions the courts have struggled to come to grips with the digital age \- so even though all of our copyright laws are based on common WIPO treaties \- the US, UK, Australia all have strange decisions based on technicalities that have resulted in the various laws being "patched up" by subsequent legislative amendments \(e\.g\. Computer Edge v Apple \(1986\) in Australia\)\. My first reaction is to disagree with you about a form based on an archetype not being an adaptation of an archetype \- in my view that would be at least debatable, depending on the facts of each case\. There are questions about whether copyright can subsist in a work which infringes another \(it appears it can in Australia \- provided that sufficient effort is expended in creating the adaptation \(the form in this case\) as to satisfy the requirement of originality \[Redwood Music v Chappell\]\); whether what has been copied is the unoriginal \- rather than the original \- portions of a work; or whether it is the idea underlying the work rather than the expression of the idea which has been taken\. In any case, there is a delicate balance and tension in the open source licensing that allows vendors to use archetypes in commercial products \(expanding the appeal of openEHR\) as against ensuring that work contributed to the common good remains freely available to all \(ensuring ongoing community of interest support\)\. I think that the potential problem arises when vendor A takes an archetype and renders it directly into a screen form and vendor B independently does the same thing, slightly differently\. If Vendor B did this without reproducing a substantial part of Vendor A's work \(and Vendor A cannot prove otherwise\) \- it is OK from a copyright perspective\. But if Vendor A had gone and got an associated software patent or is able to mount a successful "look and feel" case against vendor B \- vendor A may be able to establish a restrictive monopoly over the most obvious way of rendering the archetype \- good for vendor A but not anyone else\. Following Digital Communications Associates Inc v SoftKlone Distribution Corp \(1988\) \- the threshold to succeed in a "look and feel" case in the US is very low \- which is why people are worried\. The situation was almost identical to rendering an archetype \- and lawyers were surprised at the outcome as the screen layout was so basic that it almost appeared to be protecting the use of an idea, rather than its expression\. On the other hand, vendors naturally want to protect their investments from theft \- and to do this they would be well advised to develop their own look and feel, copyright unique aspects of their code and patent original software processes and use these means \(along with revenues from good service and support\) to secure their returns rather than to make claims on the basis of the rendering of archetypes \- but even this may be difficult for them \- now that clinical safety and efficiency are suggesting that we all ought be adopting standard user interfaces\. Your openEHR licences need to be developed with good legal input to address the most obvious legal use cases and create the type of market that you want\. Unfortunately for what openEHR Foundation is trying to achieve, there will always be people in the commercial world \(some with deep pockets\) who will try to take out competitors by mounting legal actions\. You at openEHR Foundation and your downstream developers need the best licensing protections that you can secure, if you wish to engender strong uptake\. By the way \- when you take lots of pieces of IP and build them into a new work \- such as a book \- it is a "composition" not an adaptation\. There are a whole lot of rules about compositions and the originality of compositions\. Regards Richard DH --- ## Post #22 by @erik.sundvall Hi\! > My first reaction is to disagree with you about a form based on an > archetype not being an adaptation of an archetype \- in my view that > would be at least debatable, depending on the facts of each > case\. Richard, this resonates with my fears regarding SA\-requirements for Archetypes\. There will be very many other cases we probably have not thought of yet\. Can a proprietary or a CC\-BY\-licensed openEHR template be based on CC\-BY\-SA archetypes? Can a closed source medical device \(e\.g\. a pulse oximeter\) include a transmission format based on CC\-BY\-SA\-archetypes? etc\. etc\. > Your concern seems largely to relate to the derivative works\. I believe that > the Foundation is only concerned here about derivative archetypes\. I would > not consider a form or other coded artefact to be a derivative work of the > archetype\. Sam, what matters here is not what \_you\_ think would be OK, but what the license says if somebody wants to go to court e\.g\. to create trouble for a competitor, and how that potentially scares people/organisations away from using openEHR\-hosted archetypes and might instead build momentum for an alternative archetype community using licenses that allow more freedoms\. If we want to use a simple well known CC\-license, then CC\-BY, \(or possibly CC\-0, http://creativecommons.org/about/cc0) would avoid these issues\. But the interesting thing here is probably not to make a list of potential problems, but instead to see if there really are any real benefits of a CC\-BY\-SA requirement that can't be met by just using e\.g\. CC\-BY\. > So the 'SA' license is really there to ensure that specialised or > adapted archetypes based on openEHR archetypes remain freely available\. If you select CC\-BY you can still require that any specialised or adapted archetypes \_hosted\_ by openEHR should be free under CC\-BY\. Exchanging archetype based health data between organisations is pretty pointless if you don't share the archetypes somehow, so I don't quite see the driving force for organisations \_not\_ to use CC\-BY for archetypes used in data that they want to exchange with others\. \(For commercial clinical trials there may be a case for secret/private archetypes during the trial though since the archetype may reveal things about the trial structure\. Do we really want to forbid these to in some cases be be specialisations of openEHR\-hosted archetypes?\) > As a director of the openEHR Foundation, I am concerned that we > do not set up a situation where people merely collect or make minor > adaptations of an archetype and make it commercially available\. Sam could you clarify: Do you mean that your main worry is that you are afraid that somebody will take CC\-BY\-licensed archetypes from the openEHR\-hosted repository, modify them a bit, and then redistribute under a less free license and start charging for it? Or do you have any other concerns that you can clarify? Won't your feared modified redistribution only be a problem to interoperability if, all the following comes true: a\) If users will really consider the "commercial" versions to be a lot better than the openEHR\-hosted versions and are willing to pay for something they used to get for free\. b\) If the adaptations, if found useful by openEHR, are of such innovation height that the modifying company can claim copyright/patent on the changes and somehow block openEHR from incorporating similar features in their revised archetype versions\. c\) If national programmes/authorities etc\. will start telling people to use the "commercial" versions instead of the openEHR ones for national exchange use\. \(Or more likely they would start their own repository for international archetypes under e\.g\. OHT or some other organisation\.\) d\) If the really valuable clinical community creating and maintaining archetypes etc\. stop supporting the work in the openEHR repository in favour of other alternatives\. I think c and d would only happen if openEHR messes up their governance and/or community support, and if that is the case, then it is actually a good thing that the community, using CC\-BY, can take the archetype collection and keep innovating elsewhere\. CC\-BY might actually pressure the openEHR foundation to do a better job than if feeling too "safe" behind CC\-BY\-SA\. \(No matter what you think of Google, have a look at their Data Liberation Front http://www.dataliberation.org/ \) The more formal power you try to cling on to, the more informal power you risk to lose\. > In any case, there is a delicate balance and tension in the open > source licensing that allows vendors to use archetypes in commercial > products \(expanding the appeal of openEHR\) as against ensuring that > work contributed to the common good remains freely available to all > \(ensuring ongoing community of interest support\)\. Yes, this is the core of the problem\. Will a SA\-requirement really be necessary to keep the community interested? I believe not\. Today the situation of the archetype development in the \(closed source, Ocean created CKM tool\) at http://openehr.org/knowledge/ is only marked "copyright \(c\) 2009 openEHR Foundation", so legally it seems like we don't know if those archetypes can be used in any system without explicit permission from the openEHR Foundation, the foundation is also of course now free to upon request grant permission to any commercial or derivative use of the current archetypes\. Still people are happily engaged in the work, there is some kind of community trust, which is a nice thing\. Some companies with close connections to the foundation also seem to be comfortable with using these archetypes within their products and services, nice for them\. I believe this proves that there might be an interested community even under very unclear licensing conditions and that they don't seem to mind if their contributions may be used commercially without a licence guarantee demanding derivative works also to be open\. The observation can of course also be used to prove that they might accept contributing to something that they don't know if they can use in non\-SA\-like systems themselves later if the foundation would elect to use SA\. The private contributions from people using their un\-paid spare time to help openEHR are wonderful, let's do all we can to encourage it that continue\. I also believe more health professionals will be allowed to engage in archetype authoring on paid work time once openEHR's importance starts to increase\. One of the best things that can happen to an open source software project is that some powerful entities start investing engagement an developer time in the project, that happens today also in openEHR \(sometimes indirectly\) where e\.g\. state\-run agencies have paid consultancy and research to the people doing a lot of the openEHR specification work and validation/implementation \(e\.g\. through Ocean Informatics and academic research institutions\)\. It will be wise to keep those state & commercial payers/players happy and assured that they and all their subcontractors can use the time/money/engagement invested in openEHR without any additional legal hassle and special permissions from the openEHR foundation board\. > The target is to keep archetypes available for free\. And to put them > under a strict management\. > \.\.\. > Developers might be charged a small licensing fee, similar to what you > pay when you buy a standard from IEEE or CEN or ISO\. Stefan, I and many others believe licensing fees for standards are counterproductive\. It would be better to charge for voluntary certification that proves if products adhere to standards, in case you need additional ways to make money\. I am glad licensing fees have not been suggested by the openEHR foundation\. And what would the process be, would it be as for standards documents, no access to documents/archetypes before payment? Best regards, Erik Sundvall erik\.sundvall@liu\.se http://www.imt.liu.se/~erisu/ Tel: \+46\-13\-286733 \(Mail & tel\. recently changed, so please update your contact lists\.\) --- ## Post #23 by @system Thanks Erik and Richard, Richard has raised the issue of people copyrighting forms and other derived works based on archetypes and perhaps claiming these cannot be copied\. This seems to be an argument in favour of SA\.\.\. Perhaps I could state what I personally see as the ideal state of archetypes: 1\) That there is a community commitment to develop a shared set of archetypes as well as detailed and summary display scripts \(including transforms to and from HL7 CDA, v2, CCR etc\) which are freely available\. 2\) That these archetypes can be specialised for local use but that these specialisations, should they be published, remain freely available to others and under copyright of the openEHR Foundation so that other people can specialise them further if appropriate\. 3\) That as many archetypes are copyright openEHR Foundation as possible to simplify the management of access and change, and certainly any released on the openEHR CKM\. 4\) That repositories for archetypes are federated to allow searching and that specialisation is possible for any one searching these without seeking permission from anyone \(ie federated CKMs, national etc, use openEHR copyright and licenses\)\. 5\) That no one using archetypes could be accused of copying someone else's forms or screen rendering based on archetypes\. So the tension here is between companies using archetypes being able to secure their investment in the software they produce and no one feeling threatened to use archetypes in their system\. I must say, after reading Richard's post that I do think that the SA has advantages in not leading to legal issues when companies use archetypes\. More on Eric's comments\. > Sam, what matters here is not what \_you\_ think would be OK, but what > the license says if somebody wants to go to court e\.g\. to create > trouble for a competitor, and how that potentially scares > people/organisations away from using openEHR\-hosted archetypes and > might instead build momentum for an alternative archetype community > using licenses that allow more freedoms\. I agree\. > > If we want to use a simple well known CC\-license, then CC\-BY, \(or > possibly CC\-0, http://creativecommons.org/about/cc0) would avoid these > issues\. But the interesting thing here is probably not to make a list > of potential problems, but instead to see if there really are any real > benefits of a CC\-BY\-SA requirement that can't be met by just using > e\.g\. CC\-BY\. > If you select CC\-BY you can still require that any specialised or > adapted archetypes \_hosted\_ by openEHR should be free under CC\-BY\. Well, what if the specialised archetype is hosted in Brazil for instance\. What if you receive data from there? > Exchanging archetype based health data between organisations is pretty > pointless if you don't share the archetypes somehow, so I don't quite > see the driving force for organisations \_not\_ to use CC\-BY for > archetypes used in data that they want to exchange with others\. I think this needs to be explicit \- you can use the data and archetypes\.   \(For > commercial clinical trials there may be a case for secret/private > archetypes during the trial though since the archetype may reveal > things about the trial structure\. Do we really want to forbid these to > in some cases be be specialisations of openEHR\-hosted archetypes?\) Surely the data is what must be secret, but if the archetypes are not published anywhere then I agree it would not be an issue\. > > As a director of the openEHR Foundation, I am concerned that we > > do not set up a situation where people merely collect or make minor > > adaptations of an archetype and make it commercially available\. > > Sam could you clarify: Do you mean that your main worry is that you > are afraid that somebody will take CC\-BY\-licensed archetypes from the > openEHR\-hosted repository, modify them a bit, and then redistribute > under a less free license and start charging for it? Or do you have > any other concerns that you can clarify? Yes > Won't your feared modified redistribution only be a problem to > interoperability if, all the following comes true: > a\) If users will really consider the "commercial" versions to be a lot > better than the openEHR\-hosted versions and are willing to pay for > something they used to get for free\. The point is the collective investment in archetypes will be massive\. How do we deal with the situation where someone creates a good archetype as a base idea and posts it on openEHR\. Then someone specialises it quickly on the web and copyrights the archetype saying this is their archetype and no one else can make one like that? As someone said earlier on the list \- these are all our collective ideas and it is inappropriate for anyone to claim them\. But we have to have a collective governance structure that works and supports the processes that support communication of health records\. > b\) If the adaptations, if found useful by openEHR, are of such > innovation height that the modifying company can claim > copyright/patent on the changes and somehow block openEHR from > incorporating similar features in their revised archetype versions\. Again, it might be quite small and malicious\. > c\) If national programmes/authorities etc\. will start telling people > to use the "commercial" versions instead of the openEHR ones for > national exchange use\. \(Or more likely they would start their own > repository for international archetypes under e\.g\. OHT or some other > organisation\.\) This scenario does not bother me really for the reason's you put in brackets\)\. There could be two sites for archetypes but sharing a single core set is likely to remain attractive\. > d\) If the really valuable clinical community creating and maintaining > archetypes etc\. stop supporting the work in the openEHR repository in > favour of other alternatives\. Again, this is not of great concern to me\. I am happy not to protect for this as the clinical community has to go where it thinks is best\. > I think c and d would only happen if openEHR messes up their > governance and/or community support, and if that is the case, then it > is actually a good thing that the community, using CC\-BY, can take the > archetype collection and keep innovating elsewhere\. I agree\. > CC\-BY might > actually pressure the openEHR foundation to do a better job than if > feeling too "safe" behind CC\-BY\-SA\. \(No matter what you think of > Google, have a look at their Data Liberation Front > http://www.dataliberation.org/ \) I think it is the participants and the users that need to feel safe\. > The more formal power you try to cling on to, the more informal power > you risk to lose\. > I hope my ambition is for people to share health records\. Having worked on the technical side for some time I believe the it is the community of clinicians and software companies that should answer this question to everyone's satisfaction\. I am sure that clinicians will want their work to remain freely available and not to lead to any wars between implementing companies\. As a company CEO I want to make sure I can create forms and other derived works from archetypes and no\-one can sue me for look and feel software\. I appreciate people sharing their ideas\. It is on the basis of these sorts of inputs that we need to make a decision\. Cheers, Sam --- ## Post #24 by @erik.sundvall Hi Sam\! > Richard has raised the issue of people copyrighting forms and other derived > works based on archetypes and perhaps claiming these cannot be copied\. This > seems to be an argument in favour of SA\.\.\. I'm not sure I understand your reasoning\. 1\. It seems to me that previously when you argued for Share Alike \(SA\) you said that derivative works \(like GUIs\) that were not archetypes should not be seen by the foundation as derivative works covered by the SA\-requirement\. \(It still remains to be detailed if/how such a position by the foundation should be formalised\.\) 2\. Now it sounds like you say that forms based on archetypes really should be considered derivative works and thus need to be released under SA too\. Somehow you seem confident that this would solve more potential copyright issues than it would create\. Don't you find the views 1 & 2 conflicting? Could you also detail how SA \(in 2 above\) would stop copy\-fights in this setting, is it by disallowing all archetype based systems that are not published under a SA\-license, leaving only open source solutions as permitted to use openEHR\-hosted archetypes? \(Since I like to use and create open source I would find this interesting, but I doubt it would be realistic in today's health care setting :\-\)\) > > If you select CC\-BY you can still require that any specialised or > > adapted archetypes \_hosted\_ by openEHR should be free under CC\-BY\. > Well, what if the specialised archetype is hosted in Brazil for instance\. > What if you receive data from there? I assume you don't have a certain issue with projects based in Brazil \(or do you?\) and that you instead mean something like: "What if you receive data from a stupid organisation that wants to share data with you and does not understand that they need to release the related archetypes under a licence that allows you to use the related archetypes too?" The above situation may occur no matter what what licence the openEHR\-hosted archetypes use \(as long as openEHR does have a global monopoly on archetype creation\)\. The way to cure this is not by SA, but by trying to educate stupid organisations on matters of reality\. \[Now jumping back to a previous part of the discussion\.\.\.\] > Perhaps I could state what I personally see as the ideal state of > archetypes: > 1\) That there is a community commitment to develop a shared set of > archetypes as well as detailed and summary display scripts \(including > transforms to and from HL7 CDA, v2, CCR etc\) which are freely available\. This I believe is a goal for most of us involved in openEHR\. It is the rules regarding the way to the goal that we are discussing\. I question the value of SA as a means for this purpose and I think that a "community commitment" will be based on other things\. If you don't have formal powers to force organisations to use your archetypes, and you don't have that since the openEHR specifications are OPEN, then you need to be as attractive as possible by other means \(e\.g\. by having the most interesting and active community\)\. Earlier I have stated why I think SA might make you less attractive and that it might provide a good starting ground for a competing non\-SA community\. A licence was not the tool to check integrity of archetypes \(instead digital signing etc was\)\. Likewise I doubt that a SA\-licence would be the right tool to fight fragmentation of efforts\. > 2\) That these archetypes can be specialised for local use but that these > specialisations, should they be published, remain freely available to others > and under copyright of the openEHR Foundation so that other people can > specialise them further if appropriate\. Whether the copyright of a CC\-BY licenced archetype is assigned to openEHR or somebody else is irrelevant for this purpose\. Anybody is free to build anything from a CC\-BY work \(including archetype specialisations\) the same goes for a CC\-BY\-SA provided you release the new work as CC\-BY\-SA\. > 4\) That repositories for archetypes are federated to allow searching and > that specialisation is possible for any one searching these without seeking > permission from anyone \(ie federated CKMs, national etc, use openEHR > copyright and licenses\)\. Again, the copyright assignment is not an issue if you go for CC\-BY\. A well specified way/interface to query each others repositories \(machine\-to\-machine, not GUI\) would be a good thing here though\. How do you for example query Ocean Informatics closed\-source proprietary CKM \(used by openEHR\) from another program? Is there a specification published? Being able to extract the entire content contributed by the community would raise the credibility of the currently employed solution\. > 5\) That no one using archetypes could be accused of copying someone else's > forms or screen rendering based on archetypes\. We could wish for this no matter what archetype licensing we use\. Don't you think people might try to make trouble no matter what licence we use\. Even if a system was based a different underlying information model companies might complain if a competitor's system's screen forms are direct copies of their well researched and mostly manually crafted GUI\. \(I feel sorry for countries like USA that have strong software patents\.\) Best regards, Erik Sundvall erik\.sundvall@liu\.se http://www.imt.liu.se/~erisu/ Tel: \+46\-13\-286733 \(Mail & tel\. recently changed, so please update your contact lists\.\) --- ## Post #25 by @thomas.beale Sam Heard wrote: > ``` > Thanks Erik and Richard, > > Richard has raised the issue of people copyrighting forms and other derived > works based on archetypes and perhaps claiming these cannot be copied. This > seems to be an argument in favour of SA... > > Perhaps I could state what I personally see as the ideal state of > archetypes: > > 1) That there is a community commitment to develop a shared set of > archetypes as well as detailed and summary display scripts (including > transforms to and from HL7 CDA, v2, CCR etc) which are freely available. > 2) That these archetypes can be specialised for local use but that these > specialisations, should they be published, remain freely available to others > and under copyright of the openEHR Foundation so that other people can > specialise them further if appropriate. > > ``` I think that if archetypes are published by organisations other than openEHR.org, e.g. Swedish Health and Welfare, the copyright naturally will be to that organisation. If the archetype is offered to openEHR.org to be published as a global archetype (necessitating at least translation and possibly more stringent quality review), then the copyright could be re-assigned. To me it makes sense that whoever is the publishing / managing organisation should have copyright, which is to say, the right to be identified with the work. Users of the work have some right to know who this is. > ``` > 3) That as many archetypes are copyright openEHR Foundation as possible to > simplify the management of access and change, and certainly any released on > the openEHR CKM. > > ``` on the openEHR.org CKM (or other tool of the future), yes; on the publishing repository of another organisation, I don't think so. Assigning copyright to openEHR Foundation when the archetype is created, published and managed by a Swedish, Brazilian, or other organisation makes no sense to me. It doesn't gain anything. > ``` > 4) That repositories for archetypes are federated to allow searching and > that specialisation is possible for any one searching these without seeking > permission from anyone (ie federated CKMs, national etc, use openEHR > copyright and licenses). > > ``` this of course is a desirable functional requirement of tooling. What is attractive here is to have the same (open) license in the federation (indeed, it might reasonably be made a condition of federation). > ``` > 5) That no one using archetypes could be accused of copying someone else's > forms or screen rendering based on archetypes. > > ``` A user of archetypes can do what the license allows (which is nearly anything); if they copy someone else's screen design or technology, that is another matter, and it won't be archetypes that gets them out of it... - thomas beale --- ## Post #26 by @system Hi Erik, On the licensing front, I was taken by some of the issues that Richard raised and the concern I was expressing was the possibility of people claiming that a particular template was their design \- a group of archetypes and then creating a form based on that\. This looked particularly problematic for clinical users from my perspective\. SA seems to offer some protection for that scenario\. I think you are focussing of the users in the traditional software sense \(a very important group if you want uptake\) and not the clinicians and other expert users who create the archetypes and who I want to be the leaders in both creation and use\. Your arguments for not using SA are well put\. I do not want to force people to use openEHR Foundation archetypes \- we all want the best ones to be out there in use\. If, as you say, a commercial effort created the best set and everyone started using it, then that will be the interoperability space\. At the moment archetypes are freely available\. The idea here is to get the best possible license to help the develop the sort of community activity that is what we want to see\. BY alone is clearly a choice, SA adds a major condition that we need to consider carefully\. Thanks for your challenging response\. Regarding CKM\. I sense that you would prefer it was open source and that is where I started as well\. Ocean worked on that basis with Central Queensland University for 3 years and had an academic team using the usual stack \(mySQL, Apache etc\) and just couldn't get there\. We chose to use a closed source asset management engine from a small company in Australia to get something working and I believe our team, led by Sebastian, Heather and Ian, have created something wonderful\. It might be that there will be open source tools that do this job in the future but I suspect these will flourish in the commercial sector for the time being \(Arcitecta's clients are largely research institutes and universities\!\)\. It would be good to have a list of interfaces for CKM people would like from this service\. You can look in the Archetype Editor for some specs immediately as this pulls web\-based files from CKM\. I will ask Sebastian to put the interfaces on the openEHR wiki\. The things you can do already: 1\. Pull down all the archetypes in a zip file\. 2\. Get a list of archetypes as a web service and download any you want\. Any refinements of the interface people would like to have, put it on the list or send it to Sebastian\. The platform CKM is running on is Linux and Java \(Could be Windows Server\) with this component in the middle\. We should have a plug\-in framework going shortly as this is basically how the underlying engine operates anyway\. Cheers, Sam --- ## Post #27 by @system Sam Heard wrote: > Regarding CKM\. I sense that you would prefer it was open source and that is > where I started as well\. Ocean worked on that basis with Central Queensland > University for 3 years and had an academic team using the usual stack > \(mySQL, Apache etc\) and just couldn't get there\. We chose to use a closed > source asset management engine from a small company in Australia to get > something working and I believe our team, led by Sebastian, Heather and Ian, > have created something wonderful\. It might be that there will be open source > tools that do this job in the future but I suspect these will flourish in > the commercial sector for the time being \(Arcitecta's clients are largely > research institutes and universities\!\)\. > > It would be good to have a list of interfaces for CKM people would like from > this service\. You can look in the Archetype Editor for some specs > immediately as this pulls web\-based files from CKM\. I will ask Sebastian to > put the interfaces on the openEHR wiki\. The things you can do already: > 1\. Pull down all the archetypes in a zip file\. > 2\. Get a list of archetypes as a web service and download any you want\. > > Any refinements of the interface people would like to have, put it on the > list or send it to Sebastian Hi Eric and all, The web service interface of CKM is described here: http://www.openehr.org/wiki/display/healthmod/CKM+Webservices If you are missing something let me know or raise a Jira issue in CKM: About/Suggest new feature \(when logged in\)\. In addition to what Sam has mentioned, from the CKM GUI you can also get selected classes of archetypes, archetypes that have been created or modified after a certain date, etc\. You can also get an OWL ontology of all archetypes and their classifications \(e\.g\. Health Domain = Adolescent Health, Profession = Nurse, \.\.\.\)\. Cheers Sebastian --- ## Post #28 by @system Hi Sam and Sebastian\! > \[\.\.\.\] I was taken by some of the issues that Richard > raised \[\.\.\.\] the possibility of people claiming that a particular template was > their design \[\.\.\.\] SA seems to offer some protection > for that scenario\. You still have not explained how/why you mean that CC\-BY\-SA offers better protection against this than just CC\-BY\. > Regarding CKM\. I sense that you would prefer it was open source No, I don't have the view that the CKM or anything else used by the foundation necessarily needs to be open source\. But I do think that openEHR is about open specifications and open content though, and that it is very important that work/discussions/experiences produced by the community are openly accessible so that they can be reused in many environments and that they can survive tool changes and to avoid vendor lock\-in\. > We chose to use a closed > source asset management engine from a small company in Australia to get > something working and I believe our team, led by Sebastian, Heather and Ian, > have created something wonderful\. Yes the CKM is an important tooI and it was important to get something like this up and running quickly, the current CKM is a great contribution\. I am also aware of some of your \(Ocean Informatics'\) reasons for basing the CKM on a commercial product and releasing it as a commercial tool \(although available for free to the foundation I assume\), I discussed this with Sebastian and others during and after MIE2008\. I'm not quite sure if your intention was to keep the entire solution as closed source or if you just wanted/needed to protect the calls made to the underlying commercial package\. \(Is it http://www.arcitecta.com/mediaflux/ ?\) Anyway, the reasons may be any, the most important thing is not in this case the software licence, but the open availability of the clinical content, discussions, reviews etc\. \(A drawback with the current situation though is that it's hard for others than Ocean Informatics employees to contribute with code/feature improvements or plugins to the de facto standard archetype management tool \(CKM\) used by and promoted by the foundation\. The fact that such contributions would go in to a closed commercial product also makes such contributions less likely\.\) > It might be that there will be open source > tools that do this job in the future but I suspect these will flourish in > the commercial sector for the time being If the CKM content is openly available and the data formats are open, then there is a chance that open source products \(or other competing closed source products\) can be used in the future\. If not, then we actually have a "vendor lock in"\. The same goes for all other software packages used by the openEHR foundation, the wiki, version management, issue tracker, specification editing tools etc\. As long as there is a working, well documented "way out" that allows the community contributions to be exported without too much hassle, then I believe most people will accept the use of closed source solutions in a setting like openEHRs\. This is also a risk management issue, a company behind a closed source product can disappear, run out of resources or simply discontinue support for a product\. If I was heading a national program \(or an international foundation\) considering to use the CKM for important work, then I'd make sure that I either had possibilities and rights to modify to the source code via some agreement, or that there were well documented complete export facilities \(and I'd set up a routine to backup the exports\) before investing too much time/resources in CKM\-based work\. > The web service interface of CKM is described here: > http://www.openehr.org/wiki/display/healthmod/CKM+Webservices This is a great start, thanks for documenting and announcing it\! > If you are missing something let me know or raise a Jira issue in CKM: > About/Suggest new feature \(when logged in\)\. 1\. I assume that developer resources are limited and that it would be wiser to spend time on improving CKM features than to make the perfect machine\-to\-machine interface for every possible content item in the CKM\. Thus in order to quickly get the complete export/backup feature discussed above, then maybe a documented, machine readable complete daily CKM database dump in the form of files on a public webserver will probably do the job\. \(I guess excluding the stored user password hashes might be wise for security reasons though :\-\) at least until you start using openID and can avoid storing passwords at all\.\.\.\) 2a\. Why is reading of the archetype discussions and reviews hidden to people not logged in? When e\.g\. the discussion thread "Generic name of medication" recently moved from the mailing\-list to the CKM, then at the same time it moved from public space to private space, the continued discussion is no longer searchable or cacheable by search engines, internet archives etc\. \(The commercial wiki engine used by the foundation is for example a lot better when it comes to this kind of accessibility\.\) 2b\. After opening up reading, can you make the CKM content search engine friendly? Best regards, Erik Sundvall erik\.sundvall@liu\.se http://www.imt.liu.se/~erisu/ Tel: \+46\-13\-286733 \(Mail & tel\. recently changed, so please update your contact lists\.\) --- ## Post #29 by @thomas.beale regarding CKM: one key thing we want to achieve is to define an open interface for the generic notion of a 'Clinical Knowledge Manager', which corresponds to a 'publishing organisation' in the governance proposal documents I published recently. At the moment we at Ocean have built a product and it is provided for openEHR.org on a similar basis as Jira, Confluence is by Atlassian. What will clearly become important, and we want to support is the definition and evolution of two things with respect to this product: - the service interface: how do systems talk to the CKM - the plug-in programming interface: how can a developer build a new plug-in to fit into the CKM? We are trying to make this happen as fast as reasonably possible. At some point in the future, there will undoubtedly be other 'CKM' products; we believe that this is a good thing. We would like to think that what we are doing now - trying to develop the above two open specifications via an actual implementation rather than some theoretical process - will in the long run help to ensure that when other such products appear, they are all interoperable in the same way, and don't lock anyone into proprietary interfaces. This will clearly take some time. I hope the community sees this as a reasonable state of affairs - the only alternative I can imagine is for significant pooled funding to be provided by governments to take care of the costs of doing this, which might make it faster. At the moment, this does not appear to be available. - thomas beale Erik Sundvall wrote: [details="(attachments)"] ![OceanC\_small.png|74x72](upload://5I367QG2SMJUp18Pt3jF6yz13Ey.png) [/details] --- **Canonical:** https://discourse.openehr.org/t/license-and-copyright-of-archetypes/14934 **Original content:** https://discourse.openehr.org/t/license-and-copyright-of-archetypes/14934