openEHR Transition: two procedural and one licensing question
My suggestion is for the this point Begin an open source software project for tools, web-based if possible, to author archetypes, templates and terminology reference sets directly interacting with the Clinical Knowledge Manager and equivalent repository and review tools I agree with the first part (create web-based open source tools), but I think that the second part should be clarified. We should define a basic API to access repositories, to avoid doing ad-hoc implementations for each one of the possible repositories 2011/9/5 Erik Sundvall erik.sundvall at liu.se: Hi! Kudos for moving forward! Plans seem to take some promising directions even though that whitepaper at... http://www.openehr.org:/openehr/321-OE/version/default/part/AttachmentData/data/openEHR%20Foundation%20moving%20forward.pdf ...still needs some serious editing in order to better strengthen trust in openEHRs future. 1. First a procedural question: On Mon, Sep 5, 2011 at 03:00, Sam Heard (forwarded via Thomas Beale) wrote: 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... 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? I know for sure that some people in the acknowledgements... Acknowledgements: Thank you to David Ingram, Dipak Kalra, Thomas Beale, Martin van der Meer and Tony Shannon for assisting in the planning. ...would likely object to part of it's current content. 2. A second procedural question: What is the mandate period of the transitional board? When will the suggested new structure with an elected board start? That date seems to be missing in the mail and in the document, but having an end date is very likely important for building trust in any kind of stated interim governance system (ask the people in the middle east and northern Africa...). 3. A document content change suggestion: Remove the CC-BY-SA part in the licencing discussion (page 5) since it makes the document authors and anybody ratifying it look incompetent. Saying that original things are CC-BY and that derivative models should be CC-BY-SA is just plain stupid. Then the originals are NOT CC-BY. It's just as silly as saying that a piece of open source code is licenced under Apache II licence but that any derivative code must be licenced under GPL... 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. A more practical way is to enforce good licencing (e.g. CC-BY) upon import of archetypes and archetyped data in real systems and tools. That will at the same time protect against anybody sneaking in badly licenced stuff that is not derived from openEHR original archetypes (something that a?CC-BY-SA scheme never will be able to protect against.) There are many other interesting things to discuss and clarify in the white paper, but let's start here :-) Again, thanks for working towards a more understandable openEHR foundation. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/? Tel: +46-13-286733 ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
openEHR Transition: two procedural and one licensing question
Hi Diego, I understand from Sebastian that you have been exploring the current CKM web services. Do you think these might form the basis for an open repository API or do you have any other comments or alternative suggestions? Ian On Monday, 5 September 2011, Sam Heard sam.heard at oceaninformatics.com wrote: Thanks Diego [Sam Heard] This would be a step forward and would allow for slim and fat systems to offer the same basic calls. My suggestion is for the this point Begin an open source software project for tools, web-based if possible, to author archetypes, templates and terminology reference sets directly interacting with the Clinical Knowledge Manager and equivalent repository and review tools I agree with the first part (create web-based open source tools), but I think that the second part should be clarified. We should define a basic API to access repositories, to avoid doing ad-hoc implementations for each one of the possible repositories ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- 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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110905/107ae136/attachment.html
openEHR Transition: two procedural and one licensing question
Hi, I think Diego's point is to change this ... directly interacting with the Clinical Knowledge Manager and equivalent repository and review toolsto something like ... to interact with any Clinical Knowledge Manager through a standard API (to be defined). -- 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 21:49:01 +0100 Subject: Re: openEHR Transition: two procedural and one licensing question From: ian.mcnic...@oceaninformatics.com To: openehr-technical at openehr.org Hi Diego, I understand from Sebastian that you have been exploring the current CKM web services. Do you think these might form the basis for an open repository API or do you have any other comments or alternative suggestions? Ian On Monday, 5 September 2011, Sam Heard sam.heard at oceaninformatics.com wrote: Thanks Diego [Sam Heard] This would be a step forward and would allow for slim and fat systems to offer the same basic calls. My suggestion is for the this point Begin an open source software project for tools, web-based if possible, to author archetypes, templates and terminology reference sets directly interacting with the Clinical Knowledge Manager and equivalent repository and review tools I agree with the first part (create web-based open source tools), but I think that the second part should be clarified. We should define a basic API to access repositories, to avoid doing ad-hoc implementations for each one of the possible repositories ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- 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 ___ 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/20110905/d139ddbb/attachment.html
openEHR Transition: two procedural and one licensing question
Hi! Kudos for moving forward! Plans seem to take some promising directions even though that whitepaper at... http://www.openehr.org:/openehr/321-OE/version/default/part/AttachmentData/data/openEHR%20Foundation%20moving%20forward.pdf ...still needs some serious editing in order to better strengthen trust in openEHRs future. *1. First a procedural question:* On Mon, Sep 5, 2011 at 03:00, Sam Heard (forwarded via Thomas Beale) wrote: 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... 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? I know for sure that some people in the acknowledgements... Acknowledgements: Thank you to David Ingram, Dipak Kalra, Thomas Beale, Martin van der Meer and Tony Shannon for assisting in the planning. ...would likely object to part of it's current content. *2. A second procedural question:* What is the mandate period of the transitional board? When will the suggested new structure with an elected board start? That date seems to be missing in the mail and in the document, but having an end date is very likely important for building trust in any kind of stated interim governance system (ask the people in the middle east and northern Africa...). *3. A document content change suggestion:* Remove the CC-BY-SA part in the licencing discussion (page 5) since it makes the document authors and anybody ratifying it look incompetent. Saying that original things are CC-BY and that derivative models should be CC-BY-SA is just plain stupid. Then the originals are NOT CC-BY. It's just as silly as saying that a piece of open source code is licenced under Apache II licence but that any derivative code must be licenced under GPL... 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. A more practical way is to enforce good licencing (e.g. CC-BY) upon import of archetypes and archetyped data in real systems and tools. That will at the same time protect against anybody sneaking in badly licenced stuff that is not derived from openEHR original archetypes (something that a CC-BY-SA scheme never will be able to protect against.) There are many other interesting things to discuss and clarify in the white paper, but let's start here :-) Again, thanks for working towards a more understandable openEHR foundation. Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110905/bcfa284f/attachment.html
