openEHR Transition: two procedural and one licensing question
no matter if big organisations have made use of the introductory offer of buying a position in the board? If not, we risk having an interim board forever, and we really don't need any more delays in the journey towards community-driven governance. If you get buy-in from the number of big players you want before that absolute end date then there would be nothing stopping you from doing the transition earlier than the latest date. Erik wrote: The thoughts behind the third point in the Principles of licencing are understandable, but as stated over and over again, e.g. at... http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal?focusedCommentId=13041696#comment-13041696 ...the SA part of CC-BY-SA won't help against copyright and patent abuse. Only fighting possible upcoming bad patents in particular and bad patent laws in general might save the openEHR community form patent abuse. On Mon, Sep 5, 2011 at 17:58, Sam Heard sam.heard at oceaninformatics.com wrote: [Sam Heard] If this is true then the SA part of the license has no value. If this is true then I have not heard this before. I am very glad if you might have started to see the lack of value in SA for archetypes. Using pure CC-BY (for both archetypes AND specifications) would make the first six points under Principles of licensing unnecessary and reduce confusion. At the same time I am very worried about the totally amazing information blocking filter you must have built in if you have not heard this argument before. Several people have been questioning your reasoning on this very point for years! On the official openEHR-wikipage set up for this particular question when community feedback was requested... http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal ...you have several people (including Tom Beale) in clear text saying that CC-BY-SA will NOT protect against patent attacks. (Scroll down to the heading Discussion summaries regarding CC-BY versus CC-BY-SA for content models.) How on earth could you and the entire board miss that when writing up the draft for the transition whitepaper and when making earlier license decisions? One thing that however is very efficient in fighting patent trolls is prior art. Thus one of the best protections regarding archetypes etc. is to have as much as possible of development completely public, indexed and archived by trusted sites (like http://www.archive.org/). This means always making sure to allow enough search engines and not requiring login in order to read archetype discussions and thoughts in development repositories (things like the CKM). The earlier date the mention of an idea can be traced back to, the more patent claims it will protect against. Best Regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 P.s. I agree with Pablo Diego that we need to talk about communication between several repositories, not just discuss the current openEHR-hosted CKM. ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110907/38d2f4d0/attachment.html
openEHR Transition Announcement (about regional/national openehr organizations)
Thanks Pablo, I am aware of the very excellent work being done around the world, often with insufficient publicity and I too think that regional support should be added to the White Paper but we should discuss further what sort of top-down assistance might be realistic to achieve in the short-term. We all hope that the suggested changes lead to more resources becoming available but it would be difficult to assume that this will be the case, given that membership and access to Foundation materials will continue to be free of charge. So, my question back, is What sort of support would you like to see, given that significant central resourcing is not likely in the short term? I know Thomas has some ideas about ramping up the software repository and I am very keen on the idea of a non-CKM archetype/ template 'nursery' (more elsewhere) and I could imagine that one or both might be useful at regional level. Would it be sufficient for the Foundation to give 'official status' to regional affiliates e.g. openEHR Japan, or are there other practical suggestions as to how best to support regional affiliates? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care ?www.phcsg.org On 6 September 2011 16:38, pablo pazos pazospablo at hotmail.com wrote: Hi, Not so long ago we have discussed about a governance and organization model to the openEHR community, and we have talked about regional/national openEHR communities (http://www.openehr.org/wiki/display/oecom/Foundation+Organisational+Structure). I can't find this mentioned in the whitepaper. I think if we want to have a global impact on the ehr scene, we need to support those communities also, and define ways to coordinate the work of the community as a whole. What do you think? -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Mon, 5 Sep 2011 02:00:45 +0100 From: thomas.beale at oceaninformatics.com To: openehr-announce at openehr.org Subject: [openEHR-announce] openEHR Transition Announcement Dear All, I am writing on behalf of the new Transitional Board of openEHR to share our plans to take openEHR to a new level of operations; a new structure, business model and governance. Our vision is the creation of a thriving community that works collaboratively to benefit humanity through efficient and effective electronic health records (EHRs) that support the highest quality health care for the least effort. Until now, the openEHR Foundation has functioned as an owner of intellectual property, governed by University College London and Ocean Informatics, with board members Prof David Ingram (UCL), Prof Dipak Kalra (UCL) and Dr Sam Heard (Ocean). With the support of the considerable community of Members and via engagement of a new category of sponsoring organisational Member known as ?Associates? - Companies, Universities and Governments - the Transitional Board proposes a number of changes: The openEHR Foundation becomes an operational non-profit organisation with paid key staff and resources; The Board (of governance) of the Foundation is extended to up to 10 people with a shift to election by the openEHR Associates; Members who participate are recognised by their peers, may take on decision-making roles, and have the right to commit changes to the key development assets of the Foundation. The Members will participate individually and, through qualification by peer recognition, will control the development within the three Programmes that are building the key assets: The openEHR specifications of the logical health record and attendant services as well as the methods for describing the content using archetypes (Detailed Clinical Models) and templates; and The openEHR archetypes and templates to be used within systems and for message content between systems to achieve interoperability; and The openEHR software projects, to provide open source development of tools to support the uptake and use of the specifications and templates. A group of Members will be needed to bootstrap each of these programmes and determine the working arrangements that are suitable to the products that they are managing at the current stage of development. The Associates will determine who governs the Foundation by nominating and voting on new members of the Board. The Board will appoint key Operational staff and will approve the leader of each of the Programmes. The Programme Leaders will be appointed by Qualified Members working in that Programme, subject to Board
openEHR Transition Announcement (about regional/national openehr organizations)
Hi! On Wed, Sep 7, 2011 at 08:38, Ian McNicoll Ian.McNicoll at oceaninformatics.com wrote: So, my question back, is What sort of support would you like to see, given that significant central resourcing is not likely in the short term? [...] Would it be sufficient for the Foundation to give 'official status' to regional affiliates e.g. openEHR Japan, or are there other practical suggestions as to how best to support regional affiliates? I would guess that an 'official status' recognition and thus links in online (and some offline) information resources would be a major thing, more imoportant than funding, especially if this also allowed the regional organisation to arrange official openEHR gatherings/conferences etc. It would be reasonable if the local organisation could keep money left over from such (possibly partly commercially sponsored) gatherings/conferences. Of course it would be reasonable if the foundation had some requirements on official local organisations, like having: - open membership - statutes matching regional democratic traditions and the openEHR goals (internal governance rules or whatever the swedish word stadgar should be translated to) - proper accounting and audit - a duty to have a dialogue with the central openEHR foundation regarding plans involving using the openEHR tradmark for events etc - ...probably more... For local organisations I think bottom up comunity driven governance with elected boards etc is the only way to go, not top-down. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733
openEHR Transition: two procedural and one licensing question
Hi Stef! On Tue, Sep 6, 2011 at 22:15, Stef Verlinden stef at vivici.nl wrote: Good that you bring up the SA + or - discussion again. I wish I wouldn't have to. I'd rather focus on implementation and research. In order to make the best decision can you please provide us with these arguments The arguments AGAINST SA have been publicly available for years on the openEHR community wikipage set up by Thomas Beale for exactly that purpose: http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal Do read that wikipage and follow the links there to the mail discussions. What is it that you think is missing or unclear in the arguments against SA? The arguments FOR SA have, according to me at least, not been properly explained publicly, but some argument has obviously been strong somehow behind the locked doors in board discussions. Clarification from Sam and the board has been sought for several years, e.g. in the followup questions directed to Sam since 04-Jun-2010 at http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal?focusedCommentId=13041696#comment-13041696 and, if possible, with the names of those companies/organisations. No, because: 1. I don't know if it was said in confidence or not 2. It's about time they, and all other openEHR-related companies/organisations, engage themselves in the future of openEHR and figure out their possible positions in this ecosystem. Until now there has not been a proper chance for them to engage on the same premises as Ocean Informatics and UCL, but now it's about time to wake up :-) Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733
Bosphorus Web Services and an open source communication layer for openEHR implementers
Wonderful news Seref! I think we should take time to discuss some time soon in order to match efforts and reduce overlap. :-) I believe many things can complement each other nicely e.g. in a partly REST-based open source framework aimed for web-based approaches. // Erik On Tue, Sep 6, 2011 at 19:32, Seref Arikan serefarikan at kurumsalteknoloji.com wrote: We announced Project Bosphorus from UCL, CHIME at the end of 2010 ...
openEHR Transition Announcement (about regional/national openehr organizations)
Thanks Erik, These feel like very sound proposals, in particular the focus on bottom-up local development. Pablo, Shinji - would Erik's suggestions be the kind of support that you would hope to have? Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care ?www.phcsg.org On 7 September 2011 08:31, Erik Sundvall erik.sundvall at liu.se wrote: Hi! On Wed, Sep 7, 2011 at 08:38, Ian McNicoll Ian.McNicoll at oceaninformatics.com wrote: So, my question back, is What sort of support would you like to see, given that significant central resourcing is not likely in the short term? [...] Would it be sufficient for the Foundation to give 'official status' to regional affiliates e.g. openEHR Japan, or are there other practical suggestions as to how best to support regional affiliates? I would guess that an 'official status' recognition and thus links in online (and some offline) information resources would be a major thing, more imoportant than funding, especially if this also allowed the regional organisation to arrange official openEHR gatherings/conferences etc. It would be reasonable if the local organisation could keep money left over from such (possibly partly commercially sponsored) gatherings/conferences. Of course it would be reasonable if the foundation had some requirements on official local organisations, like having: - open membership - statutes matching regional democratic traditions and the openEHR goals (internal governance rules or whatever the swedish word stadgar should be translated to) - proper accounting and audit - a duty to have a dialogue with the central openEHR foundation regarding plans involving using the openEHR tradmark for events etc - ...probably more... For local organisations I think bottom up comunity driven governance with elected boards etc is the only way to go, not top-down. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 ___ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
CKM Archetypes in XML don't seem to validate properly against available XSDs
Hi Athanasios, I have updated CKM, hopefully fixing this issue. Let me know if this is working for you now Regards Sebastian Am 06.09.2011 11:49, schrieb Athanasios Anastasiou: Hello Thank you for your response Sebastian. Is it a small number of changes that i could perhaps apply to the XSDs temporarily or better wait for you to modify the serialiser and try to re-download the archetypes from the CKM? All the best Athanasios Anastasiou On 06/09/2011 09:53, Sebastian Garde wrote: Hi CKM is using the XML serialiser of the openEHR Java Reference implementation. It seems that the serialiser applies a different order to some elements than required by the schema. Not sure if these were turned around in the xsd at some stage maybe? While I don't really understand why these elements need to have an order, I believe the problem in the XML serialiser is quite easy to fix. Is anybody maintaining this code at present? Otherwise I can have a go. Regards Sebastian Am 05.09.2011 19:28, schrieb Athanasios Anastasiou: Hello everyone Maybe there has been some intermediate change that i am missing here but i am trying to validate openEHR-EHR-OBSERVATION.blood_pressure.v1.xml (downloaded as XML from the CKM editor today) through the available XSDs from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html and i am getting a very large number of errors. Just as an indication, all the errors are Invalid content was found mostly for the elements existence and lower_included (expecting rm_attribute_name and lower_unbounded respectively) Are there different XSDs for the structure of the CKM XML files? And if yes, are they available? Looking forward to hearing from you Athanasios Anastasiou P.S. Just as a note, Resource.xsd references basetypes.xsd instead of BaseTypes.xsd in both 1.0.1 and 1.0.2 versions (while it was BaseTypes.xsd in version 1.0). It seems that the intention is to preserve the letter case (e.g. the Resource.xsd and Structure.xsd reference BaseTypes.xsd). It's a tiny thing but, as you know, it makes a difference for case sensitive file systems :-)
CKM Archetypes in XML don't seem to validate properly against available XSDs
Hello Sebastian First of all, many thanks for the quick response. I have just given it one more try and it generates less errors: The complaints currently are: No child element expected at this point for property and terminology_id and that C_CODE_PHRASE and C_DV_QUANTITY can not be resolved because the type definition can not be abstract for element children. I hope this helps. All the best Athanasios On 07/09/2011 11:04, Sebastian Garde wrote: Hi Athanasios, I have updated CKM, hopefully fixing this issue. Let me know if this is working for you now Regards Sebastian Am 06.09.2011 11:49, schrieb Athanasios Anastasiou: Hello Thank you for your response Sebastian. Is it a small number of changes that i could perhaps apply to the XSDs temporarily or better wait for you to modify the serialiser and try to re-download the archetypes from the CKM? All the best Athanasios Anastasiou On 06/09/2011 09:53, Sebastian Garde wrote: Hi CKM is using the XML serialiser of the openEHR Java Reference implementation. It seems that the serialiser applies a different order to some elements than required by the schema. Not sure if these were turned around in the xsd at some stage maybe? While I don't really understand why these elements need to have an order, I believe the problem in the XML serialiser is quite easy to fix. Is anybody maintaining this code at present? Otherwise I can have a go. Regards Sebastian Am 05.09.2011 19:28, schrieb Athanasios Anastasiou: Hello everyone Maybe there has been some intermediate change that i am missing here but i am trying to validate openEHR-EHR-OBSERVATION.blood_pressure.v1.xml (downloaded as XML from the CKM editor today) through the available XSDs from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html and i am getting a very large number of errors. Just as an indication, all the errors are Invalid content was found mostly for the elements existence and lower_included (expecting rm_attribute_name and lower_unbounded respectively) Are there different XSDs for the structure of the CKM XML files? And if yes, are they available? Looking forward to hearing from you Athanasios Anastasiou P.S. Just as a note, Resource.xsd references basetypes.xsd instead of BaseTypes.xsd in both 1.0.1 and 1.0.2 versions (while it was BaseTypes.xsd in version 1.0). It seems that the intention is to preserve the letter case (e.g. the Resource.xsd and Structure.xsd reference BaseTypes.xsd). It's a tiny thing but, as you know, it makes a difference for case sensitive file systems :-)
CKM Archetypes in XML don't seem to validate properly against available XSDs
Hello Sebastian Many thanks, that was indeed the problem. I thought all necessary data structures would be referenced through the Archetype.xsd at some point. All the best Athanasios Anastasiou On 07/09/2011 12:38, Sebastian Garde wrote: Hi, Is it possible that these errors occur because you are using archetype.xsd as your top-level schema? In that case, try using the OpenehrProfile.xsd as the top-level schema instead (which then includes the archetype.xsd). The openehr profile defines the extra C_CODE_PHRASE and C_DV_QUANTITY (and a couple others) Cheers Sebastian Am 07.09.2011 13:13, schrieb Athanasios Anastasiou: Hello Sebastian First of all, many thanks for the quick response. I have just given it one more try and it generates less errors: The complaints currently are: No child element expected at this point for property and terminology_id and that C_CODE_PHRASE and C_DV_QUANTITY can not be resolved because the type definition can not be abstract for element children. I hope this helps. All the best Athanasios On 07/09/2011 11:04, Sebastian Garde wrote: Hi Athanasios, I have updated CKM, hopefully fixing this issue. Let me know if this is working for you now Regards Sebastian Am 06.09.2011 11:49, schrieb Athanasios Anastasiou: Hello Thank you for your response Sebastian. Is it a small number of changes that i could perhaps apply to the XSDs temporarily or better wait for you to modify the serialiser and try to re-download the archetypes from the CKM? All the best Athanasios Anastasiou On 06/09/2011 09:53, Sebastian Garde wrote: Hi CKM is using the XML serialiser of the openEHR Java Reference implementation. It seems that the serialiser applies a different order to some elements than required by the schema. Not sure if these were turned around in the xsd at some stage maybe? While I don't really understand why these elements need to have an order, I believe the problem in the XML serialiser is quite easy to fix. Is anybody maintaining this code at present? Otherwise I can have a go. Regards Sebastian Am 05.09.2011 19:28, schrieb Athanasios Anastasiou: Hello everyone Maybe there has been some intermediate change that i am missing here but i am trying to validate openEHR-EHR-OBSERVATION.blood_pressure.v1.xml (downloaded as XML from the CKM editor today) through the available XSDs from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html and i am getting a very large number of errors. Just as an indication, all the errors are Invalid content was found mostly for the elements existence and lower_included (expecting rm_attribute_name and lower_unbounded respectively) Are there different XSDs for the structure of the CKM XML files? And if yes, are they available? Looking forward to hearing from you Athanasios Anastasiou P.S. Just as a note, Resource.xsd references basetypes.xsd instead of BaseTypes.xsd in both 1.0.1 and 1.0.2 versions (while it was BaseTypes.xsd in version 1.0). It seems that the intention is to preserve the letter case (e.g. the Resource.xsd and Structure.xsd reference BaseTypes.xsd). It's a tiny thing but, as you know, it makes a difference for case sensitive file systems :-) -- Ocean Informatics Dr Sebastian Garde Senior Developer Ocean Informatics /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Skype: gardeseb
openEHR Transition: two procedural and one licensing question
Hi Sam and all Thank you for comments about localisation. First of all, I emphasize LOCALISATION is not ISOLATION. Only to fork and arrange global resource for local usage is isolation. True localisation is to feed back such experience to enrich core implementation. I think endorsement program at page 4 of white book should include localisation as global promotion, and endorsement / promotion program should have a board like other specification / clinical modeling / software engineering. Because local activity management depends on its own domestic situation, local governance should be decided by local community. However, bad localisation disgrace all of our community and makes people unhappy in its area. So I think local activity requirements are, * Keep contact with global community * Implement openEHR clinical models for domestic use. * Provide proper translation, specialised implementation for their domain. * Promote openEHR specification for their domain.(Web/mailing list) * Governance of local community as good status * Feed back localisation experience to global community. I also think two or three of these conditions are enough to be a local activity. These are my requests from Japan(probably from other local activities, too) * Permit to use openEHR name and logo for domestic promotion. * Publish local activity directory for whom need to contact with them on the openEHR.org web. * Disallow to use openEHR name and logo whenf you think we are not worth to use. * Keep contact with local activities. Cheers, Shinji KOBAYASHI 2011/9/7 Sam Heard sam.heard at oceaninformatics.com: Hi Pablo and Shinji Supporting localization both technical and operational needs to be included. The no language primacy principle is a real winner, different written forms of the same language is not covered as yet. How local groups run is another, clearly these can be national or context based. Thanks for the input. Cheers Sam Sent from my phone On 07/09/2011, at 2:38 AM, pablo pazos pazospablo at hotmail.com wrote: Hi Shinji, That's exactly what I tried to point in another mail to the lists: local and regional openEHR organizations should be supported by openEHR and we need to put it into the white paper. -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos Date: Tue, 6 Sep 2011 19:13:45 +0300 Subject: Re: openEHR Transition: two procedural and one licensing question From: skoba at moss.gr.jp To: openehr-technical at openehr.org Hi All, I have been suffered by sever jet lag after long trip, while I have been thinking about this new white paper and our local activity. I could not find such localisation activity in this white paper, but please consider and mention about such local activity. I would like to show these two proposals. 1) Local activity support. As a global standard, localisation to each country or area is necessary. My three years experience to implementation of the Ruby codes, archetypes and template, we need lots of localisation efforts for Japanese use. I think this experience may be available to localise for other countries. East Asian countries people is keen in openEHR development and their engagements are promising for their health care. 2) Premature artefact repository CKM provides us well-considered archetypes and templates. This is a great knowledge resource for mankind. However, to incubate archetype as a common concept takes long time like vintage wine. On the other hand, I need more agile movement for daily development. I have developed about 50 archetypes and 6 templates. These artefacts are still premature to evaluate on CKM, but I would like to discuss about my artefacts on line with many people. Yes, it will be a 99% junk repository, but 1% diamond would be a precious for our community. As Major league cannot exist without minor leagues, I think CKM needs such minor artefacts groups. I am preparing to share them on GitHub, because anyone can use repository for each use by fork and merge request is useful. I think the licence of this repository would adopt CC-BY-SA, is this OK, Erik and Ian? Cheers, Shinji KOBAYASHI(in Japan, a path of typhoon.) 2011/9/6 Erik Sundvall erik.sundvall at liu.se: Thanks for replying Sam! Erik Wrote (to openEHR-technical at openehr.org): Was that whitepaper formally ratified by the new board, or by the old board, or is it's current state just a suggestion by Sam? On Mon, Sep 5, 2011 at 17:58, Sam Heard sam.heard at oceaninformatics.com wrote: [Sam Heard] The whitepaper was ratified by the participants in the planning process, the current Board (Profs. Kalra, Ingram and myself) and the new Transitional Board. This is a bit worrying for the period until a broader board can be elected. I was hoping that somebody within the new board
openEHR Transition: two procedural and one licensing question
Op 7 sep 2011, om 09:55 heeft Erik Sundvall het volgende geschreven: Do read that wikipage and follow the links there to the mail discussions. What is it that you think is missing or unclear in the arguments against SA? That they're hidden in a lot of text form which one has to follow through hyperlinks and read even more text. You stated somewhere - correctly - that companies want to avoid risk, similarly decision makers want to avoid reading through lengthy discussion (from which they have to draw there own conclusions:-) ) If I understand you correctly your main argument is that: the share alike (SA) requirement will create a risk for lengthy juridical procedures - in every country they operate - for companies who include openEHR archetypes or derivatives thereof in their systems. Since companies avoid risk, they will choose other solutions without an SA requirement. The reason for this is that it's not clear what SA exactly means. For instance in the context of building archetype-based GUI- stubs, forms etc. in proprietary systems. As a consequence it could be possible that companies are forced - unwillingly - to open up the source of their proprietary systems. It will take years and many court cases, in different countries, to sort this out. Until then (the large) companies will stay away from openEHR. This problem can be avoided completely by dropping the SA requirement. So I guess the first question is: who has a solid argument against Erik's argument. The second question is: what are the exact benefits of the SA requirement and are they worth the risk of companies not using openEHR at all (presuming that's a real risk). Cheers, Stef -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110907/d2a043db/attachment.html
openEHR Transition Announcement (about regional/national openehr organizations)
Hi Ian, So, my question back, is What sort of support would you like to see, given that significant central resourcing is not likely in the short term? I think we (local/regional organizations working with and on openEHR) need formal support from the openEHR fundation. One basic form of support is to recognize the local/regional openEHR organizatons as such. Other is to recognize our contributions to the community, like mentioning our work on presentations, publications and other public communications (I think a public communications strategy should be traced by openEHR foundation). If we think of money, there are ways of money support without giving real money: we need software tools (archetype template editors), we need access to events far away, we need books, educational resources, etc, etc. The foundation should draw yearly general goals, to the openEHR project as a whole, and to the local/regional representatives. And should follow and coordinate the work and evaluate the results. Those goals could be technical, educational, communicational, among other kinds. Here is a related thread with some other ideas: http://www.openehr.org/mailarchives/openehr-implementers/msg00889.html What do you think? Regards, Pablo. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110907/e2f181c7/attachment.html
openEHR Transition: two procedural and one licensing question
Sam, Just to be clear. Is it yours and the boards intent that all archetypes and templates be marked as copyright openEHR Foundation? Thanks. On Wed, Sep 7, 2011 at 15:46, Sam Heard sam.heard at oceaninformatics.com wrote: Thanks Stef The previous Board did not want to make an error and use too loose a licence given that there is no going back. Our concern is that someone could specialize an archetype and claim copyright, or create a template and do the same. It is our intention at this stage to have a specific clause in the licence that limits it to derived archetypes and templates. At all discussions with industrial parties this has been acceptable, many see it as positive as the corollary of Eric's approach (which may be the best) is that there are heaps of archetypes out there that have openEHR attribution but are copyright to other parties. Is it clear what I am saying. It is a conundrum - and needs careful appraisal before going to BY alone. Cheers Sam Sent from my phone On 07/09/2011, at 10:38 PM, Stef Verlinden stef at vivici.nl wrote: Op 7 sep 2011, om 09:55 heeft Erik Sundvall het volgende geschreven: Do read that wikipage and follow the links there to the mail discussions. What is it that you think is missing or unclear in the arguments against SA? That they're hidden in a lot of text form which one has to follow through hyperlinks and read even more text. You stated somewhere - correctly - that companies want to avoid risk, similarly decision makers want to avoid reading through lengthy discussion (from which they have to draw there own conclusions:-) ) If I understand you correctly your main argument is that: the share alike (SA) requirement will create a risk for lengthy juridical procedures?- in every country they operate -?for companies ?who include openEHR archetypes or derivatives thereof in their systems. Since companies avoid risk, they ?will choose other solutions without an SA requirement. The reason for this is that it's?not clear what SA exactly means. For instance in the context of building archetype-based GUI- stubs, forms etc. in proprietary systems. As a consequence it could be possible that companies are forced - unwillingly - to open up the source of their proprietary systems. It will take years and many court cases, in different countries, to sort this out. Until then (the large) companies will stay away from openEHR. This problem can be avoided completely by dropping the SA requirement. So I guess the first question is: who has a solid argument against Erik's argument. The second question is: what are the exact benefits of the SA requirement and are they worth the risk of companies not using openEHR at all (presuming that's a real risk). Cheers, Stef ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Timothy Cook, MSc LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook Academic.Edu Profile: http://uff.academia.edu/TimothyCook
