Just for curiosity, is that license available anywhere?
2011/9/7 David Ingram - UCL account <rmhidxi at live.ucl.ac.uk>:
> Hi Pablo - re- your important observation below.
>
> It was a difficult decision to go with a proprietary product to underpin the
> openEHR CKM, but at the time there was no apparent open source tool to
> provide the first stage functionality required. It is complex and expensive
> software to develop and maintain and, through the good offices of Sam and
> Ocean, we secured a free license to support the CKM repository, which we
> were thereby enabled to make quickly available for experimental use. Of
> course, open-source tools are not cost and resource neutral options, but it
> is certainly easier for many to engage along an open source pathway of
> development. That said, I believe that going with the proprietary CKM was a
> sensible decision at the time (it was and had to be Dipak's and mine, I
> should say, and in no way an Ocean decision). It has certainly been fully
> vindicated, in my eyes, by the free use that has been made of it, which we
> can observe day by day, within both the openEHR community and several
> cognate groupings, all over the world, exploring and working with the
> archetypes now residing in the public CKM repository that Ocean has
> generously created and maintained throughout, for the openEHR community.
>
> Looking forward, Ian's link with Derek Hoy/Snowcloud and the offer he has
> made, is interesting and potentially a very useful new thread in the tooling
> agenda for openEHR. I don't think anyone imagines we are near to an ideal
> tooling environment to support effective clinical engagement with
> archetype/template/terminology development and support. The field will
> undoubtedly benefit from concerted and coordinated efforts to create new and
> better open source tooling in this area - a goal that is dear to many
> clinicians' hearts, I know - Tony Shannon and Dipak Kalra, to name but two!
>
> Forgive my inquisitiveness, Pablo, but I have just located and read your
> impressive CV and you seem exactly the right sort of person to join with
> others discussing here, in taking forward an initiative like that for the
> openEHR community. Once Sam and the new board (fully operational from
> October 1st) has given time for its current consultation about future
> governance to evolve into decisions about next steps, I very much hope there
> will be a way for you to do so.
>
> David I
>
> On 07/09/2011 19:03, pablo pazos wrote:
>
> Hi,
>
> I agree that we need localized CKM's and clear governace rules technical
> (e.g. free&open tools, common API) and behavioral (e.g. versioning).
>
> I've answered this on other thread, I think this is the correct one:
> ------------
> Hi David,
>
> You mention a big issue: we want to build local archetype and template
> repositories but we don't have the tools to do it in a coordinated way with
> the openEHR CKM.
>
> I think it would be great to have an open & free CKM to start with, and a
> common generic API to connect our local CKMs to regional CKMs and regional
> CKMs to the global CKM in a controlled way (in this scenario the versioning
> of artefacts is a big issue and I think it is not solved at the tool level
> yet).
>
> AFAIK the to install the global CKM we have to buy some licenses.
> ------------
>
> --
> 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
>
>> From: yampeku at gmail.com
>> Date: Wed, 7 Sep 2011 10:36:45 +0200
>> Subject: Re: openEHR Transition: Community Knowledge repository
>> To: openehr-clinical at openehr.org
>>
>> I completely agree with you, but if we do that, we need a very clear
>> governance and versioning policy (and be willing to stick to it).
>> And define the minimal access API as soon as possible ;)
>>
>>
>> 2011/9/7 Ian McNicoll <Ian.McNicoll at oceaninformatics.com>:
>> > Hi Diego,
>> >
>> > I am strongly in favour of establishing a community-led/
>> > lightly-governed clinical knowledge repository as suggested by Shinji,
>> > particularly if we can arrange some sort of federation between this
>> > and a number of locally or regionally managed repositories.
>> >
>> > However, these must sit quite separately from the openEHR CKM or any
>> > other nationally governed repositories. I would anticipate that many
>> > of the archetypes from this repositories would find there way into the
>> > governed CKMs but Shinji's comments about needing the freedom to
>> > experiment outside the necessary restrictions of CKM are absolutely
>> > correct. I appreciate that many of the current archetypes are still in
>> > draft and as you say 'use at your own risk' but we are trying to avoid
>> > having competing representations in this 'interoperability' space.
>> > That is not to imply that Shinji's work is poor or incorrect, just
>> > that it often uses different design patterns and approaches. If we
>> > adopt a free-for-all approach to CKM now, it will become impossible to
>> > resolve later. However, IMO, this also makes the establishment of a
>> > community repository even more essential so that some of the excellent
>> > ideas that Shinji and others are developing have a place to grow and
>> > flourish.
>> >
>> > I would welcome suggestions for a repository framework e.g GitHub that
>> > might support a community repository, particularly one that supports a
>> > distributed/federated approach.
>> >
>> > Snowcloud have an open-source collaborative tool that has been used by
>> > both ICNP (nursing terminology) and Wm Goosen's Netherland's DCM group
>> > as a front end for their collaborative working. Derek Hoy, who runs
>> > Snowcloud, would be happy to assist in setting up an instance for
>> > openEHR, though we would have to consider hosting etc.
>> >
>> > This would not be trying to compete with the governed CKMs, rather
>> > allow more free-flowing collaboration and early work-up of ideas. The
>> > Foundation should, I believe, be prepared to support and endorse this
>> > effort but I would expect it to be almost wholly community-driven and
>> > governed.
>> >
>> > Further thoughts would be very welcome.
>> >
>> > 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 17:24, Diego Bosc? <yampeku at gmail.com> wrote:
>> >> 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 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-clinical mailing list
>> > openEHR-clinical at openehr.org
>> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
>> >
>>
>> _______________________________________________
>> openEHR-clinical mailing list
>> openEHR-clinical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
>
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
>
