openEHR Transition: two procedural and one licensing question

Technical (archive)
1

Hi!

Kudos for moving forward!

Plans seem to take some promising directions even though that whitepaper at…

http://www.openehr.org:8888/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:

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 :slight_smile:

Again, thanks for working towards a more understandable openEHR foundation.

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

2

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

3

Hi Erik

Plans seem to take some promising directions even though that whitepaper at…

http://www.openehr.org:8888/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.

[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:

4

Thanks Diego

[Sam Heard] This would be a step forward and would allow for slim and fat
systems to offer the same basic calls.

5

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

6

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.

7

Hi,

I think Diego’s point is to change this "… directly interacting with the Clinical Knowledge Manager and equivalent repository and review tools"to something like “… to interact with any Clinical Knowledge Manager through a standard API (to be defined)”.

8

Thanks Pablo – this is very helpful.

Sam

9

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@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

10

Thanks for replying Sam!

Erik Wrote (to openEHR-technical@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?

[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?

[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. :frowning:

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.

[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@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.

11

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 :slight_smile:

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@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

12

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!

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

13

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.)

14

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')

15

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.

16

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

17

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

18

Hi Stef!

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 :slight_smile:

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

19

Hi Diego,

I have responded to your comments on the Clinical list under

openEHR Transition: Community Knowledge repository

as I think this a topic which properly belongs there and absolutely
merits further discussion.

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@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

20

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