openEHR Transition: two procedural and one licensing question
Hi! On Thu, Sep 8, 2011 at 16:54, Sam Heard sam.heard at oceaninformatics.com wrote: Let's stay with the issue of how we stop someone copyrighting and charging for a specialised archetype? Or a template that is fundamental to health care (like an antenatal visit)? So, Sam have you finally dropped the thought that CC-BY-SA would protect against patent system abuse? We have not gotten a clear answer to this yet. Is your only remaining concern now that you believe copyright law might be so strong that it would stop possibilities to do specialisations with the same main functionality as possibly copyrighted useful specialisations? Is that your only remaining SA motive? Sam, since you are and have been so extremely powerful in the formal openEHR decision process, we really need to understand your thoughts, thus I and others have been probing to figure out your reasoning for years. On Fri, Sep 9, 2011 at 00:21, Timothy Cook timothywayne.cook at gmail.com wrote: Maybe that isn't such a bad thing. ?They are only roping themselves into their own corner. :-) We as a community could always provide help in highlighting those ropes via: - Technical means: license detection upon import of archetypes and EHR data (as described on the wiki) - Social political means: questioning the fairness and wisdom of parties trying to block the common good of semantic interoperability. Their income often somehow originates from public funding and they should be concerned about potential badwill. We can probably also get around the hypothetical/potential problem by making a similar (hopefully even better) specialisation ourselves (not an exact copy) that covers the same needs. It will be hard for the copyrighting and charging-bad guys to claim that another implementation of the idea is a verbatim copy (prohibited by copyright) and that their work has enough innovation height that is not obvious to skilled persons (and thus patentable). The same argument goes the other way too - even ideas from a CC-BY-SA licensed archetype from openEHR may be fairly closely re-implemented as completely closed/copyrighted and it would be both hard and time-consuming for the openEHR foundation to try and stop this (anti-interoperable) approach, so let's reduce the temptation by simply using CC-BY. Copyright does not stop ideas the same broad way patents do. To software people I believe it's obvious that improvement-ideas in commercial closed source forks of e.g. apache-licensed software projects does not prevent the open source original project to reimplement similar ideas (as long as the closed source code is not copied). Copyright is not nearly as harmful as patents in these cases. On Thu, Sep 8, 2011 at 01:37, Sam Heard sam.heard at oceaninformatics.com wrote: Our advice was that having copyright simplifies the world. Having said that the same archetypes now exist in other repositories with copyright assigned to the national provider, so it is already murky. Well, if the national providers had been encouraged to use CC-BY instead of CC-BY-SA then it wouldn't matter at all who had the copyright (as Tom has pointed out several times over the years)... On Fri, Sep 9, 2011 at 05:25, Sam Heard sam.heard at oceaninformatics.com wrote: ...government agencies and companies will want to know that no one has recourse to legal action if they use an archetype. Is that a copy of the ideas behind my argument _against_ CC-BY-SA? :-) 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 Sam, Let's stay with the issue of how we stop someone copyrighting and charging for a specialised archetype? Or a template that is fundamental to health care (like an antenatal visit)? Cheers, Sam Why we need to define a license to stop someone to copyright or charge for a specialized archetype? I think this could be done by defining user terms to the archetypes downloaded from the CKM (and every CKM around the world must have the same use terms. You can include something like this on the user terms: all artefacts (archetypes, templates, term sets, etc) downloaded from *here* are public and free to use and to specialize. All artefacts derived from those, alse must be free. This is a copyleft scheme. If I want to use artefacts from a public CKM, I must follow those rules. Of course, anyone can create its own CKM and create artefacts from scratch and do whatever they want with those artefacts. I think you can charge for the time you invest in specialize artefacts from public CKMs, but not sell the artifact itself. If you create the artefact from scratch its the creators desition to charge or not. 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/20110912/1cdf546a/attachment.html
openEHR Transition: two procedural and one licensing question
Hi Tom It is normal practice with CC to include clarifications and the whole structure of the license is designed to do this. Let's stay with the issue of how we stop someone copyrighting and charging for a specialised archetype? Or a template that is fundamental to health care (like an antenatal visit)? Cheers, Sam -Original Message- From: openehr-technical-bounces at openehr.org [mailto:openehr-technical- bounces at openehr.org] On Behalf Of Thomas Beale Sent: Thursday, 8 September 2011 10:30 AM To: openehr-technical at openehr.org Subject: Re: openEHR Transition: two procedural and one licensing question On 07/09/2011 21:46, Sam Heard 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. I don't think actually changing the text of any accepted, well known license is a good idea at all - then it becomes something for which no legal analysis is available, and won't be trusted by anyone. Instead, openEHR should simply state which kinds of artefacts require which kinds of license (if any). - thomas ___ 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
Well that may be true but government agencies and companies will want to know that no one has recourse to legal action if they use an archetype. Cheers Sam Sent from my phone On 09/09/2011, at 8:21 AM, Timothy Cook timothywayne.cook at gmail.com wrote: On Thu, Sep 8, 2011 at 16:54, Sam Heard sam.heard at oceaninformatics.com wrote: Hi Tom It is normal practice with CC to include clarifications and the whole structure of the license is designed to do this. Let's stay with the issue of how we stop someone copyrighting and charging for a specialised archetype? Or a template that is fundamental to health care (like an antenatal visit)? Maybe that isn't such a bad thing. They are only roping themselves into their own corner. ___ 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
Thank you Shinji, this is an excellent idea - to really put support for language and other localization at the heart. I would propose that one Organisation become an associate and manage local activites - which Organisation should be by a vote of local associates. This prevents the need for a lot of administrative activity. What do others think? Cheers Sam Sent from my phone On 07/09/2011, at 10:15 PM, Shinji KOBAYASHI skoba at moss.gr.jp wrote: 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.
openEHR Transition: two procedural and one licensing question
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 -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110908/b6e24d5e/attachment.html
openEHR Transition: two procedural and one licensing question
Tim, There are two possibilities for archetypes that are donated to a place like CKM in openEHR.org. 1. copyright remains with the originator 2. copyright goes to the publisher, which could be openEHR.org, or some national e-health programme, or some other body When there is a license attached (e.g. CC-BY), it doesn't matter that much, since the rights of the user are defined mostly by the license rather than direct reversion to copyright law in some country. However, as with most open source code, it probably makes sense if the copyright is given to openEHR or other publishing entity (e.g. some national e-health programme), since this avoids fights about which of the 20 contributors to an archetype should have copyright. In the end, copyright is a nearly useless concept for changing artefacts, it only really works with unchanging ones like books and paintings. As long as attirbutions to original author(s) and contributors are made in the artefact text, I would say that making the artefact copyright to the relevant publishing organisation makes more sense. Many archetypes won't really have any 'original author' - just contributors, due to being truly team-built artefacts. - thomas On 08/09/2011 00:05, Timothy Cook wrote: 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 Heardsam.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 Verlindenstef 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 -- Ocean Informatics *Thomas Beale Chief Technology Officer, Ocean Informatics http://www.oceaninformatics.com/* Chair Architectural Review Board, /open/EHR Foundation http://www.openehr.org/ Honorary Research Fellow, University College London http://www.chime.ucl.ac.uk/ Chartered IT Professional Fellow, BCS, British Computer Society http://www.bcs.org.uk/ Health IT blog http://www.wolandscat.net/ * * -- next part -- An HTML attachment was scrubbed... URL:
openEHR Transition: two procedural and one licensing question
On 07/09/2011 21:46, Sam Heard 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. I don't think actually changing the text of any accepted, well known license is a good idea at all - then it becomes something for which no legal analysis is available, and won't be trusted by anyone. Instead, openEHR should simply state which kinds of artefacts require which kinds of license (if any). - thomas
openEHR Transition: two procedural and one licensing question
Hi Tim, It is tangled up with the CC-BY-SA question. Some one needs to have the copyright or there is a license agreement that is evoked as you enter the the archetype in the repository. Our advice was that having copyright simplifies the world. Having said that the same archetypes now exist in other repositories with copyright assigned to the national provider, so it is already murky. The real point is that interoperability depends on sharing archetypes, which need to be available for use without regard to others. By that, I also mean I can freely use ANY archetype or template out there if I need to. Cheers Sam Sent from my phone On 08/09/2011, at 9:05 AM, Timothy Cook timothywayne.cook at gmail.com wrote: 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 ___ 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
I agree with you Shinji, well said! -- 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: Wed, 7 Sep 2011 21:15:34 +0900 Subject: Re: openEHR Transition: two procedural and one licensing question From: skoba at moss.gr.jp To: openehr-technical at openehr.org 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
openEHR Transition: two procedural and one licensing question
On Thu, Sep 8, 2011 at 16:54, Sam Heard sam.heard at oceaninformatics.com wrote: Hi Tom It is normal practice with CC to include clarifications and the whole structure of the license is designed to do this. Let's stay with the issue of how we stop someone copyrighting and charging for a specialised archetype? Or a template that is fundamental to health care (like an antenatal visit)? Maybe that isn't such a bad thing. They are only roping themselves into their own corner.
openEHR Transition: two procedural and one licensing question
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 would be interested enough and have time to take licensing issues and community feedback seriously, let's hope that the board does a bit more research and community dialogue before ratifying a new version of this whitepaper. Could somebody from the board please confirm that you'll take a serious look at this in the near future? Erik wrote: What is the mandate period of the transitional board? When will the suggested new structure with an elected board start? On Mon, Sep 5, 2011 at 17:58, Sam Heard sam.heard at oceaninformatics.com wrote: [Sam Heard] I for one am very happy to express a date for elections if organisations embrace these arrangements. Clearly if there is no interest in participating from industry or organisations then we would have to think again. I suspect we will then move to election of the Board by Members but it is our wish to provide a means of determining the governance for openEHR?s key sponsors. The aim is to balance the Members with governance from the funders and sponsors. Some may prefer a democratic organisation top to bottom; we do not think this will achieve the best results. So there is no absolute end date set. :-( The if organisations embrace these arrangements part is worrying, especially since we already have seen failed attempts at getting buy-in from organisations. Can't you set an absolute latest date (e.g. at the very latest December 31, 2012) when the new arrangements will start
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
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: 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
openEHR Transition: two procedural and one licensing question
Hi Erik Plans seem to take some promising directions even though that whitepaper at... http://www.openehr.org:/openehr/321-OE/version/default/part/AttachmentDa ta/data/openEHR%20Foundation%20moving%20forward.pdf ...still needs some serious editing in order to better strengthen trust in openEHRs future. [Sam Heard] Getting the balance of top down governance and sponsorship and bottom up participation and 'ownership' is difficult and we have worked hard to get it right. This paper is seeking to set the scene and morph into one or more clear statements of intent. 1. First a procedural question: 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? [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. 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. [Sam Heard] It is obvious that there will be parts of the document that are not considered ideal by all the participants in its development. These have been thrashed out and we have presented the best first cut. 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...). [Sam Heard] I for one am very happy to express a date for elections if organisations embrace these arrangements. Clearly if there is no interest in participating from industry or organisations then we would have to think again. I suspect we will then move to election of the Board by Members but it is our wish to provide a means of determining the governance for openEHR's key sponsors. The aim is to balance the Members with governance from the funders and sponsors. Some may prefer a democratic organisation top to bottom; we do not think this will achieve the best results. I am interested in the views of Members. 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... [Sam Heard] The point you are making I think refers to: --- Clinical Models Archetypes, Templates and Terminology subsets developed by the community Creative Commons for organisational and individual use. CC-BY-(SA) The Share Alike (SA) is specifically applied to derived archetypes and templates only. --- [Sam Heard] The text may not be sufficiently clear but the intent is. We are drawing attention to the fact that the intent is that the SA part of the license is only applied to derived archetypes and templates. That is, it is a CC-BY-SA license with specific exclusion of all derivations except archetypes and templates. This means that anyone creating a template from archetypes cannot claim that they own it and no one else can use or copy it. They can keep it secret. I apologise if this is not clear. 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+Propos al?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. [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. 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.) [Sam Heard] The intent is not to stop the use of any archetypes whatsoever, for any purpose. It is not policing. Rather , the intent is to ensure that people cannot stop anyone using an archetype or template without any recourse to action by others. There are many other interesting things to discuss and clarify in the white paper, but
openEHR Transition: two procedural and one licensing question
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 Transition: two procedural and one licensing question
In my experience. you only need 2 or 3 CKM web services: search (with different kinds of search) download. I think those two are really basic, and are also the ones that every repository must have (and depending on the application, those are enough). Some of the other web services (like freemind generation) are useful, but I wouldn't put them in a generic API. 2011/9/5 Ian McNicoll Ian.McNicoll at oceaninformatics.com: 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
openEHR Transition: two procedural and one licensing question
Thanks Pablo ? this is very helpful. Sam From: openehr-technical-boun...@openehr.org [mailto:openehr-technical-bounces at openehr.org] On Behalf Of pablo pazos Sent: Tuesday, 6 September 2011 8:42 AM To: openehr technical Subject: RE: 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/20110906/0d940784/attachment.html
openEHR Transition: two procedural and one licensing question
Hi Pablo, I agree with your and Diego's suggested change. That was the intended meaning of the original statement but yours expresses this more clearly. I was just interested in Diego's actual experience with the CKM web-services as the basis for a generic API. 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 00:11, pablo pazos pazospablo at hotmail.com wrote: 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.McNicoll at 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 ___ 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
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 would be interested enough and have time to take licensing issues and community feedback seriously, let's hope that the board does a bit more research and community dialogue before ratifying a new version of this whitepaper. Could somebody from the board please confirm that you'll take a serious look at this in the near future? Erik wrote: What is the mandate period of the transitional board? When will the suggested new structure with an elected board start? On Mon, Sep 5, 2011 at 17:58, Sam Heard sam.heard at oceaninformatics.com wrote: [Sam Heard] I for one am very happy to express a date for elections if organisations embrace these arrangements. Clearly if there is no interest in participating from industry or organisations then we would have to think again. I suspect we will then move to election of the Board by Members but it is our wish to provide a means of determining the governance for openEHR?s key sponsors. The aim is to balance the Members with governance from the funders and sponsors. Some may prefer a democratic organisation top to bottom; we do not think this will achieve the best results. So there is no absolute end date set. :-( The if organisations embrace these arrangements part is worrying, especially since we already have seen failed attempts at getting buy-in from organisations. Can't you set an absolute latest date (e.g. at the very latest December 31, 2012) when the new arrangements will start 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
openEHR Transition: two procedural and one licensing question
Hi Erik, As one of the new transitional board members I would like to thank you for your comments and suggestions. I don't think any of us would consider the White Paper as near to being a finished article but there was consensus that, given the long wait, it was good enough to go to the openEHR community for what I hope will be robust discussion and criticism. As you say, there are a number of issues which lack clarity and need further discussion. The issue of CC-BY vs. CC-BY-SA has, of course, been extensively discussed and although the previous board took a decision to adopt SA, this is very much up for further discussion. Like many others, I did not get particularly involved in these discussions as it felt to me (perhaps incorrectly) to be a somewhat arcane and legalistic debate over a pretty fine point. What might be helpful to me and others would be some clear practical examples of the kind of scenario for which CC-BY-SA is thought to be required (rightly or wrongly). As I understand it the debate centres around whether this particular kind of 'misuse' can really be controlled by CC-BY-SA without imposing inappropriate restrictions on the corpus of work as a whole and sending the wrong message to interested parties. I did enjoy your reference to ''transitional arrangements' in North Africa and the Miiddle East :-) Much as I am attracted to the idea of participating in an 'interim' 25 year reign of terror, I am absolutely clear that the role of this board is to manage the transitional period as rapidly as possible. I think setting an end date is correct in principle but might be difficult to judge in practice. Having said that, Dec 2012 feels to me like a reasonable start point for discussion. I think the White Paper correctly identifies the need to engage institutional and commercial organisations directly in any new governance arrangements. openEHR benefits in many ways from not being an 'official' standards body,but the lack of organisational governance has been a significant barrier to engagement of potential institutional stakeholders. Whilst the core of openEHR activities should, I think, definitely draw heavily on an Apache Foundation-like approach, I am not convinced that this will be sufficient. Balancing this requirement against the legitimate needs of ordinary members will be challenging and I am sure you and others will have a number of ideas in this area. I expect there may well be some robust exchanges of opinion over the coming weeks and months but I am very confident that as a community we have a pretty coherent and unified sense of the end goal : An open specification, backed up by open source software, and open clinical knowledge artifacts, with as little encumbrance on further use as possible, commercial or otherwise, and community-led development very much in the mode of open-source software projects. This does need to be anchored by much more inclusive governance arrangements which blend the needs of community members and the 'open ethos' above, with the organisational checks and balances that institutional stakeholders will expect from a body which produces 'standard models'. After a period where we have moved from specification to development and now into real implementation, I am increasingly confident that openEHR has a solid and exciting future. I am looking forward to the challenge of helping get us into the right shape to support this future. Regards, 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 10:05, Erik Sundvall erik.sundvall at liu.se wrote: 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 would be interested enough and have time to take licensing issues and community feedback seriously, let's hope that the board does a bit more research and community dialogue before ratifying a new version of this whitepaper. Could somebody from the board please confirm that you'll take a serious look at this in the near future? Erik wrote: What is the mandate period of the transitional board? When will the suggested new structure with an elected board start? On Mon, Sep 5, 2011 at 17:58, Sam Heard
openEHR Transition: two procedural and one licensing question
Hi Ian! Nice to have more than one single board member to actually discuss with on the lists, this is already a great openEHR improvement! On Tue, Sep 6, 2011 at 15:07, Ian McNicoll Ian.McNicoll at oceaninformatics.com wrote: The issue of CC-BY vs. CC-BY-SA has, of course, been extensively discussed and although the previous board took a decision to adopt SA, this is very much up for further discussion. Good. Don't wait too long, there are several more interesting and fun things to discuss and work with once the licensing stupidity is solved. ?Like many others, I did not get particularly involved in these discussions as it felt to me (perhaps incorrectly) to be a somewhat arcane and legalistic debate over a pretty fine point. How can this be explained to clinicians of the board if what is already on the wiki... http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal ...is not enough? Just read through that page and follow the links to the messages in the cited mail debate dating years back, then ask again if any points are still unclear. Analogies can be misleading, but I'll try: What danger is a pretty fine point of a malign cancer cell cluster in a human body, why so much fuzz when you detect that? Whenever I talk to software people they seem to immediately understand the issue and importance of not having licence-contagious (GPL/SA-like) code getting into the wrong parts of closed source systems (if you want to allow closed source business models in your ecosystem). Software people also understand that you simply can't claim to publish something as CC-BY at the same time as you say that some derivative works based on it should be CC-BY-SA, that's just incredibly misguided and any governance body letting that slip through is not to be completely trusted regarding license competence until further educated... If you don't have people on the board understanding software industry basics, then the board is missing some vital competence and you should make sure to either get that competence into the board or take the advice of people like Tom Beale in these questions. Just as much as you'd probably consider it wise to consult a clinician rather than a software specialist regarding medical issues. The fine point of licensing is fundamental for most companies before deciding if they want to commit commercial resources into any software-related project. I have heard serious arguments in more than one country where companies/organisations are not wanting to use openEHR archetypes partly because of the SA licencing issue. They may have adopted the technical framework (RM etc) but are using their own set of archetypes, and as long as they don't exchange data outside their own systems then there is no perceived interoperability problem... *sigh* What might be helpful to me and others would be some clear practical examples of the kind of scenario for which CC-BY-SA is thought to be required (rightly or wrongly). Read that wikipage and the mail links again, there are several examples in those texts where CC-BY-SA would likely reduce trust in openEHR as a viable business option. One major short term risk I see currently is that the foundation will continue to be slow in response to licensing concerns and that as a result competitors to the openEHR-hosted CKM will pop up using better licenses (like pure CC-BY) for their non-openEHR-derived archetypes and that the archetyping community gets fragmented and semantic interoperability thus is reduced. Another short term risk is that fewer commercial entities might be interested in openEHR if there is a perceived lack of understanding of software industry needs in the board. But I think you find most of these arguments already on that wikipage and in it's linked mail discussion. http://www.openehr.org/wiki/display/oecom/openEHR+IP+License+Revision+Proposal Do read it. And the links. Please. // Erik
openEHR Transition: two procedural and one licensing question
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 would be interested enough and have time to take licensing issues and community feedback seriously, let's hope that the board does a bit more research and community dialogue before ratifying a new version of this whitepaper. Could somebody from the board please confirm that you'll take a serious look at this in the near future? Erik wrote: What is the mandate period of the transitional board? When will the suggested new structure with an elected board start? On Mon, Sep 5, 2011 at 17:58, Sam Heard sam.heard at oceaninformatics.com wrote: [Sam Heard] I for one am very happy to express a date for elections if organisations embrace these arrangements. Clearly if there is no interest in participating from industry or organisations then we would have to think again. I suspect we will then move to election of the Board by Members but it is our wish to provide a means of determining the governance for openEHR?s key sponsors. The aim is to balance the Members with governance from the funders and sponsors. Some may prefer a democratic organisation top to bottom; we do not think this will achieve the best results. So there is no absolute end date set. :-( The if organisations embrace these arrangements part is worrying, especially since we already have seen failed attempts at getting buy-in from organisations. Can't you set an absolute latest date (e.g. at the very latest December 31, 2012) when the new arrangements will start 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
openEHR Transition: two procedural and one licensing question
Good to hear about you! I hope everything is ok in Japan. I would encourage you to put the archetypes on the CKM anyway, as I would say that most of the available archetypes on the repository are in the same situation as your archetypes (the implicit 'use under your own responsibility') 2011/9/6 Shinji KOBAYASHI skoba at moss.gr.jp: 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 would be interested enough and have time to take licensing issues and community feedback seriously, let's hope that the board does a bit more research and community dialogue before ratifying a new version of this whitepaper. Could somebody from the board please confirm that you'll take a serious look at this in the near future? Erik wrote: What is the mandate period of the transitional board? When will the suggested new structure with an elected board start? On Mon, Sep 5, 2011 at 17:58, Sam Heard sam.heard at oceaninformatics.com wrote: [Sam Heard] I for one am very happy to express a date for elections if organisations embrace these arrangements. Clearly if there is no interest in participating from industry or organisations then we would have to think again. I suspect we will then move to election of the Board by Members but it is our wish to provide a means of determining the governance for openEHR?s key sponsors. The aim is to balance the Members with governance from the funders and sponsors. Some may prefer a democratic organisation top to bottom; we do not think this will achieve the best results. So there is no absolute end date set. :-( The if organisations embrace these arrangements part is worrying, especially since we already have seen failed attempts at getting buy-in from organisations. Can't you set an absolute latest date (e.g. at the very latest December 31, 2012) when the new arrangements will start 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
openEHR Transition: two procedural and one licensing question
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 would be interested enough and have time to take licensing issues and community feedback seriously, let's hope that the board does a bit more research and community dialogue before ratifying a new version of this whitepaper. Could somebody from the board please confirm that you'll take a serious look at this in the near future? Erik wrote: What is the mandate period of the transitional board? When will the suggested new structure with an elected board start? On Mon, Sep 5, 2011 at 17:58, Sam Heard sam.heard at oceaninformatics.com wrote: [Sam Heard] I for one am very happy to express a date for elections if organisations embrace these arrangements. Clearly if there is no interest in participating from industry or organisations then we would have to think again. I suspect we will then move to election of the Board by Members but it is our wish to provide a means of determining the governance for openEHR?s key sponsors. The aim is to balance the Members with governance from the funders and sponsors. Some may prefer a democratic organisation top to bottom; we do not think this will achieve the best results. So there is no absolute end date set. :-( The if organisations embrace these arrangements part is worrying, especially since we already have seen failed attempts at getting buy-in from organisations. Can't you set an absolute latest date (e.g. at the very latest December 31, 2012) when the new arrangements will start 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
openEHR Transition: two procedural and one licensing question
Hi Eric, Good that you bring up the SA + or - discussion again. In order to make the best decision can you please provide us with these arguments and, if possible, with the names of those companies/organisations. Cheers, Stef Op 6 sep 2011, om 16:51 heeft Erik Sundvall het volgende geschreven: I have heard serious arguments in more than one country where companies/organisations are not wanting to use openEHR archetypes partly because of the SA licencing issue. -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110906/0753a42b/attachment.html
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
