# Message from the Board - openEHR Intellectual Property **Category:** [Announcements (archive)](https://discourse.openehr.org/c/announcements-archive/155) **Created:** 2010-06-01 13:40 UTC **Views:** 3 **Replies:** 19 **URL:** https://discourse.openehr.org/t/message-from-the-board-openehr-intellectual-property/14998 --- ## Post #1 by @thomas.beale Posted on behalf of Professor David Ingram, chair of the board of the openEHR Foundation: Since initiating the consultation on the principles governing present and future licensing of openEHR IP \(see wiki page http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal), we have had positive responses, expressed on a personal basis\. As the Board needs to begin to act on these proposals, from the end of June, this is a request to hear from anyone in the community who may be harbouring doubts or concerns about the direction of travel we have laid out, or wishes to offer alternative proposals\. This can be by private communication to me, as chair of the openEHR Foundation Board, or by contribution to the openEHR lists and/or the above wiki page \. We would be happy to receive messages of support as well, of course\. \- David Ingram --- ## Post #2 by @system Hi David and others! I have added a section for summaries of discussions to the bottom of the page at [http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal](http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal) The current version of the text is also included below: #### Summary of views by Erik Sundvall (preferring CC-BY) There has been mail discussions on (and off) the mailinglists regarding what license to use for content models (exemplified above by openEHR.org archetypes, templates, archetype-based queries).The concrete suggestion from the openEHR foundation board is tu use CC-BY-SA with some homegrown additions. In my view the argument right now boils down to: - The main difference between CC-BY and CC-BY-SA is that CC-BY-SA in addition to the CC-BY also adds the requirement that derived works that are distributed must be distributed under an open license. The board now for some strange reason wants to use CC-BY-SA with a loosely formulated addition that derived works "do not have to be openly distributed". I have not heard any reasonable motivation what this would gain compared to just using CC-BY from the beginning. In open source communities homegrown additions to (or modifications of) licenses are known to be potential problem sources. CC-BY and CC-BY-SA (without homegrown additions) have been scrutinized by lawyers and have been translated and developed to fit legislation in many countries, it would take a lot of work to do the same with a homegrown addition to CC-BY-SA - and if there is no well motivated gain, then why not just use CC-BY in the first place? Some previous mailing list posts regarding this, commented from Erik's perspective: - January 2006 - The importance of having very well understood open licenses for archetypes was very well formulated by Tim Churches [http://www.openehr.org/mailarchives/openehr-technical/msg01774.html](http://www.openehr.org/mailarchives/openehr-technical/msg01774.html) - 1 September 2009 - David Monér starts an interesting thread: [http://www.openehr.org/mailarchives/openehr-technical/msg04573.html](http://www.openehr.org/mailarchives/openehr-technical/msg04573.html) Some excerpts from the discussion thread follow: - Tim Cook says the board should make a statement: [http://www.openehr.org/mailarchives/openehr-technical/msg04577.html](http://www.openehr.org/mailarchives/openehr-technical/msg04577.html) - Erik Sundvall discusses hard-to-interpret situations if using SA and quotes himself from off-list discussions from 2008: [http://www.openehr.org/mailarchives/openehr-technical/msg04579.html](http://www.openehr.org/mailarchives/openehr-technical/msg04579.html) - Sam Heard says -SA will "ensure that specialised or adapted archetypes based on openEHR archetypes remain freely available" and that other derived works won't be a big issue[http://www.openehr.org/mailarchives/openehr-technical/msg04622.html](http://www.openehr.org/mailarchives/openehr-technical/msg04622.html) - Richard Dixon Hughes (a lawyer) says and exemplifies that derived works might be a tricky area [http://www.openehr.org/mailarchives/openehr-technical/msg04623.html](http://www.openehr.org/mailarchives/openehr-technical/msg04623.html) - Erik Sundvall responds to Sam Heard, especially regarding the expressed fear of modified redistribution of archetypes: [http://www.openehr.org/mailarchives/openehr-technical/msg04624.html](http://www.openehr.org/mailarchives/openehr-technical/msg04624.html) - Sam Heard responds to Erik Sundvall [http://www.openehr.org/mailarchives/openehr-technical/msg04628.html](http://www.openehr.org/mailarchives/openehr-technical/msg04628.html) - Thomas Beale says copyright does not always have to be assigned to openEHR [http://www.openehr.org/mailarchives/openehr-technical/msg04632.html](http://www.openehr.org/mailarchives/openehr-technical/msg04632.html) - Erik Sundvall finds Sam Heard's reasoning changing and contradictory, asks for clarification and responds to Sam's other points [http://www.openehr.org/mailarchives/openehr-technical/msg04631.html](http://www.openehr.org/mailarchives/openehr-technical/msg04631.html) - Sam Heard explains parts of his thought process and then says things like "Your arguments for not using SA are well put" and "BY alone is clearly a choice, SA adds a major condition that we need to consider carefully." [http://www.openehr.org/mailarchives/openehr-technical/msg04639.html](http://www.openehr.org/mailarchives/openehr-technical/msg04639.html) - The continued discussion then shifts focus away from Archetype licensing (to CKM and other things). - February 2010 - Erik repeats his fears that SA will hurt trust in openEHR: [http://www.openehr.org/mailarchives/openehr-technical/msg04892.html](http://www.openehr.org/mailarchives/openehr-technical/msg04892.html) and a reply where Tom B finds the basic argument solid[http://www.openehr.org/mailarchives/openehr-technical/msg04893.html](http://www.openehr.org/mailarchives/openehr-technical/msg04893.html) The fact that objections to using CC-BY-SA were openly declared on the mailing lists, but not properly answered before the decision by the board to adopt CC-BY-SA, makes me wonder how the decisions in the board are made with respect to response from the community. In a (mostly off-list) mail debate from August 2008 and in the (on-list) debate from September 2009 (referenced above) I sensed that Sam Heard (who is [part of the board](http://www.openehr.org/about/bod.html)) had some strong undefined feeling that CC-BY-SA would be more beneficial top the openEHR community, but he could not make a strong case for it when confronted. Is the case that Sam or somebody else has later presented strong arguments to the board that could not and will not be presented to the community in the mailinglists or on the wiki? If arguments can not be presented openly, then the risk increases that people suspect the board or some of its members to have hidden agendas, and that is a bad thing for an open project like openEHR. Best regards, Erik Sundvall [erik.sundvall@liu.se](mailto:erik.sundvall@liu.se) [http://www.imt.liu.se/~erisu/](http://www.imt.liu.se/~erisu/) Tel: +46-13-286733 --- ## Post #3 by @Stef_Verlinden1 For those of you who really want to dig deep into this, here ([https://oa.doria.fi/bitstream/handle/10024/42778/isbn9789522147219.pdf?sequence=2](https://oa.doria.fi/bitstream/handle/10024/42778/isbn9789522147219.pdf?sequence=2)) you'll find an excellent thesis dealing with all aspects of CC licenses. Although initially I voted for CC-BY-SA I have to agree that, although I still like the idea of reciprocity, it shouldn't become a barrier for wide adaptation and/or a 'paper tiger (as we call it in Dutch, which means that although it looks something, it's worth nothing). Therefore I also think we should go for CC-BY Underneath you'll find a small section of the thesis dealing with the SA aspect. Cheer, Stef --- ## Post #4 by @Koray_Atalag Hi All, I think many of us, including myself, get lost as we read all those licenses and the ways of the fine wording; thus will not be able to comment effectively. The wiki page listing the requirements/principles for licensing schemes was an extremely useful approach with that regard and I suggest we should all have a second and more careful look. I suspect they haven’t been discussed enough and perhaps not addressing the issues being brought about now. Once we openly discuss and agree on these then (at the Board’s discretion) it is up to the legal experts and the few knowledgeable people among us to verify if any of the proposed licensing schemes fulfil these requirements. Perhaps it would be worthwhile to determine some use cases in addition to these requirements for better understandability. Cheers, -koray --- ## Post #5 by @thomas.beale Erik, thanks for summarising this. I still have the same position as you, that CC-BY is the correct approach. I have not had the time to study the licences + all related openEHR posts + all related web resources in line-by-line detail, but I have yet to see the only thing that might convince me that CC-BY-SA is needed, which is a list of one or more concrete cases that the community knows it wants to support, that are prevented by using only CC-BY rather than CC-BY-SA. I think that the key things we need to preserve (with respect to archetypes, & templates) are: - A - allowing an entity or individual to create a private archetype or template (it is all the same thing in ADL 1.5 anyway). This is clearly needed for - purposes of private research - purposes of local use, e.g. hospital-authored and -used templates - commercialisation of equipment whose data may be described by templates - building of application and other software based on archetypes and templates that may or may not be published openly - B - preventing an entity or individual from patenting or otherwise 'occupying' part of the archetype / template space, i.e. preventing others from authoring (nearly) the same archetype or template by their own means. - this point is roughly equivalent to the problem of patented software, which is by and large not an accepted practice (see [http://en.wikipedia.org/wiki/Software_patent](http://en.wikipedia.org/wiki/Software_patent)).- C - encourage openness, cooperation and innovation - note that, as with other technology, the latter might be best encouraged in some circumstances by private competition rather than single open source efforts. CC-BY-SA would seem to prevent all cases of the point A above, where the artefact in question was *derived from* some openly published artefact. It might technically prevent B, but B isn't likely to be supportable even with CC-BY for the same reason as software patents not being widely accepted. C is not a function of the licence, it is a function of the technology, formalisms, governance mechanisms, and general health of the community. The words 'derived from' are the magic words, and on the wiki page, I distinguished between two kinds of derivation, namely 'semantic' and 'generated'. The first, in archetype-land means archetypes and templates derived from previously existing archetypes and templates. There are 3 forms of this: specialisations, new versions and new revisions. Note that in ADL/AOM 1.5, a template is a kind of specialisation of a template or archetype. These semantic 'derivations' are equivalent to programmers creating new classes based on existing classes (via the inheritance relationship) or modifications of existing classes (e.g. bug fixes, enhancements, usually provided as logical 'patches'). To my knowledge, commercial-friendly pen source software licences (i.e. non-viral ones) allow A above for software, and have no effect on B or C. The other kind of 'derivation' is a hand- or machine-generation of some different kind of artefact such as a screen form, XML schema etc, from an archetype or template. Firstly, I don't know whether this kind of 'derivation' qualifies as 'derivation' in the sense of licences like CC-BY, since the new artefact is not of the same kind as the old, but if this is ambiguous, we certainly don't want to use CC-BY-SA, since we certainly do want to allow commercial use of such generated artefacts. I also don't know whether the generated or hand-built output artefact could be patented, preventing another person creating the same thing by a different means (probably some aspects could, if sufficiently innovative), but a commercial company that uses patents might try to patent the generator/generating software or algorithm. I think it is more likely that they would just use normal legal means to prevent piracy, and sell it normally. From my point of view, even if we don't agree with such behaviour (I don't), it is not up to openEHR to try and prevent it, and the fact that CC-BY-SA would prevent perfectly reasonable commercial behaviour means it should not be used. I also agree that modified open source licences are to be avoided at all costs, because once you change a licence, the accepted legal interpretation (often created by experts & knowledgeable amateurs over some years) goes out the window, and you don't really know what the meaning of the licence is. - thomas beale --- ## Post #6 by @Tim_Cook2 Thanks for that research and organization work Erik\. Whether Sam \(as a Board member\) or anyone else has presented any 'strong arguments' to the other Board members is an unknown and frankly, I think, is irrelevant\. Over the past decade, we can probably count on our fingers the number of threads that a Board member other than Sam has participated in on any of the open mailing lists\. They have participated on the ARB list and in private group mails where the audience is controlled\. IMHO, this speaks loudly as to the desire of \(or lack of desire\) those members have to demonstrate any community building leadership\. Neither has there been any move towards true open democracy in Board membership\. A sparkling precedent exists that free\-for\-all openness works\. The Internet we have today would not exist if Bob Kahn, Vint Cerf and others at DARPA had taken the same stance that we see the openEHR Board of Directors taking today\. Even though they worked for the US Department of Defense\. They realized that autonomous but cooperating groups was the best way to ensure \(and insure\) global uptake of the TCP/IP specifications\. Even if they weren't perfect \(the 32 bit address space being a glowing example\) they were a perfect starting place\. The fact that they could be passed around, translated, etc\. gave rise to the many implementations\. The comments regarding "protecting the users" is, IMHO, a Trojan Horse\. What I perceive that is inside the horse, I'll keep to myself for the time being\. So, Trojan Horse or Red Herring; it is a mis\-leading reasoning\. People need to be able to FREELY copy, derive and implement the specifications as they see fit\. No one is going to intentionally attempt to monopolize the specifications using an embrace and extend or any other approach\. To do so would simply isolate them\. But after nearly 10 years of trying to convince them otherwise I have given up on changing the minds and approaches of the central authority of openEHR\. This is why the Multi\-Level Health Information Modeling \(http://www.mlhim.org\) umbrella project was created\. In less than one year we are already seeing project funding and porting of existing projects to MLHIM\. Attitude makes a difference\. You are all welcome to join us if you wish\. Kind Regards, Tim --- ## Post #7 by @thomas.beale Tim, can I just get a few things straight here? - are you really talking about the openEHR board? ([http://www.openehr.org/about/bod.html](http://www.openehr.org/about/bod.html)). The openEHR board is like the board of a company; just sets vision and mission, and ensures the basic healthy functioning of the organisation. It doesn't perform operational duties; you would not normally expect to see the board being active on mailing lists etc. - If you are talking about the ARB, that has been pretty democratic, and included a self-nomination process, and you were on it for some years. - what do you want to convince the board of? - thomas beale [details="(attachments)"] ![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg) [/details] --- ## Post #8 by @David_de_Bhal Hear Hear David de Bhál [www.v-practice.com](http://www.v-practice.com/) --- ## Post #9 by @Hugh_Leslie1 Hi Tim I can't understand why you would suggest that someones concern at openness \(or lack of\) at the board level is irrevelant\. I can see from your email that you gave given up on openehr as an organisation which I think is a great pity\. It seems to me that as the take up and interest in openehr is increasing, it creates more anxieties around these issues of openness and control\. To date, the structure of openehr has been to have an active community with a small core of experts working on the specifications\. The process has been an engineering approach with change requests and decisions not being made democratically, but by those who have the expertise to do the work in a sensible way\. It's a completely different approach to the usual SDO democratic way of thinking and has enabled the specs to be developed rapidly and to a high quality\. I have no personal insight into how a decision was reached about the licensing, or if it is set in stone\. We probably don't have a really good process about making these kinds of decisions yet\. The structure of the foundation needs to evolve with the changing needs of the community and it is changing and evolving\. We have to remember that the current foundation has no funding apart from UCLs support and all work is currently completely voluntary\. As the foundation evolves, this will change and should enhance our ability to be better at communication\. I think that openehr is healthy and that the desire of everyone involved is not to control or prevent openness, but to make sure that the decisions made now work well in the future\. Let's keep talking \- there will always be differences of opinion\. Regards Hugh --- ## Post #10 by @system Hi All, I have added the following to the Wiki. Thanks to Eric for the excellent summary. My personal concerns are best expressed in the following way: - openEHR archetypes express (and may refine) clinical knowledge in widespread use - The openEHR specifications mean that sharing of archetypes is the basis for interoperability, the fundamental motivation for this work. Ensuring that archetypes derived from shared archetypes are also freely available seems a sensible approach to avoid any licensing issues for archetypes in use - CC-BY-SA is more restrictive than CC-BY and a shift from CC-BY-SA to CC-BY is far less problematic than moving from CC-BY to CC-BY-SA - Eric may be correct that specific provisions are not easy to express. By limiting the derived works to which this license applies to openEHR archetypes and templates would appear to avoid this issue. I wonder if there are others who have an opinion in this delicate decision. It would be good to have legal advice on what we would have to do if under CC-BY I issued a specialised archetype under my own copyright. I believe that I would have the right to provide formal agreement to anyone who wanted to specialise it further. Cheers, Sam --- ## Post #11 by @system CC SA clause for your information. (Otherwise the clauses are identical). You may Distribute or Publicly Perform an Adaptation only under the terms of: (i) this License; (ii) a later version of this License with the same License Elements as this License; (iii) a Creative Commons jurisdiction license (either this or a later license version) that contains the same License Elements as this License (e.g., Attribution-ShareAlike 3.0 US)); (iv) a Creative Commons Compatible License. If you license the Adaptation under one of the licenses mentioned in (iv), you must comply with the terms of that license. If you license the Adaptation under the terms of any of the licenses mentioned in (i), (ii) or (iii) (the "Applicable License"), you must comply with the terms of the Applicable License generally and the following provisions: (I) You must include a copy of, or the URI for, the Applicable License with every copy of each Adaptation You Distribute or Publicly Perform; (II) You may not offer or impose any terms on the Adaptation that restrict the terms of the Applicable License or the ability of the recipient of the Adaptation to exercise the rights granted to that recipient under the terms of the Applicable License; (III) You must keep intact all notices that refer to the Applicable License and to the disclaimer of warranties with every copy of the Work as included in the Adaptation You Distribute or Publicly Perform; (IV) when You Distribute or Publicly Perform the Adaptation, You may not impose any effective technological measures on the Adaptation that restrict the ability of a recipient of the Adaptation from You to exercise the rights granted to that recipient under the terms of the Applicable License. This Section 4(b) applies to the Adaptation as incorporated in a Collection, but this does not require the Collection apart from the Adaptation itself to be made subject to the terms of the Applicable License. Cheers, Sam --- ## Post #12 by @system Thanks Tom – it would be good to ensure that we are interpreting the license correctly. The SA clause begins: You may Distribute or Publicly Perform an Adaptation only under the terms of... I interpret this to mean that there is no restriction on local or private use. It only applies to publishing. More in line... --- ## Post #13 by @thomas.beale > Thanks Tom – it would be good to ensure that we are interpreting the license correctly. The SA clause begins: > > You may Distribute or Publicly Perform an Adaptation only under the terms of... This is the legalise from points a) & b) of the restrictions: [with respect to 'the work']: You may not distribute, publicly display, publicly perform, or publicly digitally perform the Work with any technological measures that control access or use of the Work in a manner inconsistent with the terms of this License Agreement. [with respect to 'derivative works']: You may not offer or impose any terms on the Derivative Works that alter or restrict the terms of this License or the recipients' exercise of the rights granted hereunder, and You must keep intact all notices that refer to this License and to the disclaimer of warranties. You may not distribute, publicly display, publicly perform, or publicly digitally perform the Derivative Work with any technological measures that control access or use of the Work in a manner inconsistent with the terms of this License Agreement. > I interpret this to mean that there is no restriction on local or private use. It only applies to publishing. More in line... well private use on your own laptop - like listening to a CD or mp3 on your own iPod, that is true. But as soon as there is any distribution whatever, it can only be open, not controlled in any way, such as pay-for, or under any conditions of use such as might apply in a commercial situation - which would typically at least prevent you from re-distributing the artefact from the commercial vendor. - thomas --- ## Post #14 by @system To make this clear for implementers, this kind of messages can cause panic, because people do not understand, they really mess things up all the time. I have a half day job explaining license issues to people, and I am only a programmer (maybe that is why it takes so much time) --- ## Post #15 by @thomas.beale Bert, I don't think there is any reason for panic, quite the opposite. The 2-line summary of the situation is: - everything is already open under either recognised licenses, copyright, etc, apart from archetypes, which don't have a proper license yet (but we treat them as being 100% open & free artefacts) - In the future, we want to improve the copyright covering the specifications to be a bit more standard, and designate a VERY open license for archetypes & templates. The recent debate is really about which of the CC licenses to use for archetypes and templates. openEHR is already about as open s you can get, and it is going to be even more so soon. I think this will remove any doubts and help all users and implementers. - thomas beale --- ## Post #16 by @Nsshiv Can u please remove me from the distribution list\. Thankyou\. S Sent using BlackBerry® from Orange --- ## Post #17 by @system I think, this is clear Thanks Thomas. Op 3-6-2010 20:18, Thomas Beale schreef: --- ## Post #18 by @Gavin_Brelstaff Tim, Despite any such obscurity of boards, licenses and standards \- perceived and actual \- and I too am slightly skeptical \- \.\.\. I think we cannot but applaud the openEHR in its putting online of the CKM system \- which democratizes the process of specifying archetypes \- in a way previously unheard in healthcare standards collaboration\. Okay if archetype specs are wrong then this collaboration is undermined, but the CKM is quite a leap forward after a decade or two \- don't you think? \\Gavin Brelstaff CRS4 --- ## Post #19 by @system Hi! Discussing openEHR community, governance, licences etc is neither completely clinical or technical, thus we tried to keep parts of the discussion regarding CC-BY-(SA?) for openEHR-hosted archetypes on the wikipage [http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal](http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal) Unfortunately the "oecom"-part of the wiki requires login*, so below those of you that don't want to create an account and log in will find an excerpt of the updates to the wikipage that have not already been posted to the lists. I'll post another update to the lists in a week if nobody else does it before me. Best regards, Erik Sundvall [erik.sundvall@liu.se](mailto:erik.sundvall@liu.se) [http://www.imt.liu.se/~erisu/](http://www.imt.liu.se/%7Eerisu/) Tel: +46-13-286733 *) Login for read access is an unnecessary hurdle if you want wide and accessible community participation (and a bit hard to motivate for a really open project), so please open up read access for that part. Login for write permission (as it is now as for the rest of the wiki) is reasonable though. Below you find new additions to the wiki page: #### Summary of views by Thomas Beale (preferring CC-BY) I think that the key things we need to preserve with respect to archetypes, & templates are: - A - allowing an entity or individual to create a private archetype or template (it is all the same thing in ADL 1.5 anyway). This is clearly needed for - purposes of research (where some kind of local sharing / distribution was happening) - purposes of local use, e.g. hospital-authored and -used templates - commercialisation of equipment whose data may be described by templates - building of application and other software based on archetypes and templates that may or may not be published openly - B - preventing an entity or individual from patenting or otherwise 'occupying' part of the archetype / template space, i.e. preventing others from authoring (nearly) the same archetype or template by their own means. - this point is roughly equivalent to the problem of patented software, which is by and large not an accepted practice (see [http://en.wikipedia.org/wiki/Software_patent](http://en.wikipedia.org/wiki/Software_patent)). - C - encourage openness, cooperation and innovation - note that, as with other technology, the latter might be best encouraged in some circumstances by private competition rather than single open source efforts. CC-BY-SA would seem to prevent all cases of the point A above, where the artefact in question was *derived from* some openly published CC-BY-SA artefact. It might technically prevent B, but B isn't likely to be supportable even with CC-BY for the same reason as software patents not being widely accepted. C is not a function of the licence, it is a function of the technology, formalisms, governance mechanisms, and general health of the community. On the other hand, CC-BY will allow A, probably make no difference to B, and won't get in the way of C. The incompatibility of CC-BY-SA with A) above could lead to a competitive archetype-authoring effort. #### Summary of views by Andrew Patterson (preferring CC-BY)- Patenting should not even enter into our thought processes when it comes to looking at licenses for archetypes and templates. Even in a jurisdiction with broad definitions for patentable subject matter, there is no possible way an artifact such as an archetype could possibly be patentable. This is for a whole bunch of reasons, including novelty (archetypes are essentially documentation of common medical knowledge), but mainly the fact that it is neither a manufactured item, nor even an algorithmic process. So don't even worry about it. And even if you want to worry about it, the reality is that it doesn't matter what copyright license you put on an archetype - if someone wanted to try to patent something in this area (perhaps a generic implementation algorithm for archetypes) - they can do it without any reference to specific archetypes, hence the license is irrelevant. - You can't solve everything with the law - commercial entities should want to maintain compatibility with offically published archetypes because the benefits of sharing/interoperability/community involvement outweigh any possible benefits they might get by keeping them secret. - Custom changes to common licenses are evil. Either CC-BY-SA or CC-BY - not CC-BY-SA with changes. **Comments (3)** 1. (old comment) 1. Jun 04 [Erik Sundvall](http://www.openehr.org/wiki/display/%7Eerik.sundvall) says: Sam, I need to understand your thinking/usecase better, can we have a dialogue h... Sam, I need to understand your thinking/usecase better, can we have a dialogue here in the comment field here on the wiki in order not to spam the lists? (Later we kan post a summary to the lists.) Feel free to ask questions back if you want me to clarify my reasoning. My basic question is why you think CC-BY-SA would serve openEHR better than CC-BY would. Your reasoning seems very vague to me, but what I sense is that it revolves mainly around making sure patient data is shareable and around community issues, so please speak up and clarify: - **Question 1:** Do you believe that it is easy/possible to split licensing requirements for different kind of derived works from the same origin (e.g. a derived screen form would not need to be SA but a specialiced archetype would need to be SA)? If so, please show how that would be done in a way that the community and companies easily trust and understand. I know a group of experienced lawyers could formulate a completely new licence type saying this, but that would not be a well recognised licence that people immedeately trust, you would lose the CC recognition. - **Question 2:** Do you understand the difference between these two: - 2a) Making sure nobody can distribute archetypes derived from openEHR-hosted archetypes under other licences than CC-BY-SA. - 2b) Making sure EHR owners understand that patient data (at least data that they at any point in the future may want to exchange with or transfer to other parties) is entered using archetypes with very open licences (such as CC-BY). In an earlier discussion (off-list I think) you believed that a licence would be the correct tool to guarantee that released archetypes would not be altered and later reissued under the same ID. You were shown (and accepted) that a technical solution with a mathematical checksum was the right tool, not the licence. I think you are again confusing what a licence could do and what is better done by other tools than licenses. In the case of 2b above, in addition to educating system owners, maybe there should be a technical import warning filter in openEHR based EHR systems that calls for the attention of system owners if clinical data that does not follow a CC-BY, CC-0 or similarly licenced archetype is imported. That would be a technical mean of detecting the stupidity earlier described in [http://www.openehr.org/mailarchives/openehr-technical/msg04631.html](http://www.openehr.org/mailarchives/openehr-technical/msg04631.html). Anybody **could** already today use **any** licence (or even full copyright) when creating archetypes from scratch and they can start distributing them and using them for patient data. (Even though it would be stupid.) What licence openEHR chooses for the archetypes that they host will only affect archetypes derived from the ones hosted/issued by openEHR. The technical stupidity-detection would on the other hand detect license stupidity no matter what source it comes from. I believe you really want 2b but have confused that with 2a. - **Question 3:** Is it the case that you belive that using CC-BY-SA would somehow cause less fragmentation in the archetype authoring community than CC-BY would do? If so, can you see the parallell to using e.g. GPL (CC-BY-SA like) v.s. Apache style (CC-BY like) licences? Both styles have obviously worked to form strong communities and excellent software. Do you have any special reason why a CC-BY style community would not work for openEHR? Personally I believe that CC-BY-SA would cause unnecessary fragmentation of the community since many vendors (and national organisations dependent on vendors) would not want to risk be "infected" by SA/GPL-requirements, thus they would feel forced to very soon start an alternative archetype repository and development process using something like CC-BY instead. - **Question 4:** Do you think my fears (of community fragmentation in thre case of CC-BY-SA) are ungrounded and irrelevant? If so please motivate why closed source companies and their customers should feel absolutely comfortable using archetypes issued under CC-BY-SA or a new home-made openEHR licence with partial SA-requirements. Sam, the licencing question is important and I think picking CC-BY-SA for archetypes would be a really big mistake that would hurt openEHR community in general and in particular would drastically deteriorate the confidence in the board competence and the trust in the governance process of openEHR. I don't want that to happen, that's why I am arguing and spending time on this. I'd much rather keep developing the LiU openEHR based Educational EHR Environment than discussing licenses. 1. Jun 04 [Thomas Beale](http://www.openehr.org/wiki/display/%7Ethomas.beale) says: Erik, I think the analysis above is pretty good. We cannot legislate against all... Erik, I think the analysis above is pretty good. We cannot legislate against all bad behaviour with licences, only try to enable good behaviour. But achieving the community behaviour we want is actually done by other means, including good tooling (including content management tools, checksumming etc), good governance, and easy ways to participate. I also believe that CC-BY-SA will scare off some otherwise perfectly good commercial vendors, and will potentially create distrust. In my view it is better to have a looser licence, and enable the community dynamic in other ways, for example, by funding and improving openEHR.org/knowledge, so that it becomes a lead supplier of trustworthy international archetypes (and other similar sites may pop up in the future - why not?). With the possible addition of IHTSDO backing, and integration with ref set building in the future, most users will automatically go to this resource because of its quality, not because they are prevented from doing other things by over-strict licences. The only thing I really want to prevent is any private entity trying to lock up any part of the archetype design space by patents or other means, and I don't see how CC-BY-SA helps this at all. --- ## Post #20 by @thomas.beale fixed now. I had not realised this before. Apologies. - thomas beale --- **Canonical:** https://discourse.openehr.org/t/message-from-the-board-openehr-intellectual-property/14998 **Original content:** https://discourse.openehr.org/t/message-from-the-board-openehr-intellectual-property/14998