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): > >> >>> 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 repositories, not just discuss the > >> > current openEHR-hosted CKM. > >> > > >> > _______________________________________________ > >> > openEHR-technical mailing list > >> > openEHR-technical at openehr.org > >> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >> > > >> > >> _______________________________________________ > >> openEHR-technical mailing list > >> openEHR-technical at openehr.org > >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at openehr.org > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at openehr.org > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110908/95620d14/attachment.html>
