openEHR Transition: two procedural and one licensing question

[Timothy Cook]

On Thu, Sep 8, 2011 at 16:54, Sam Heard  
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 Announcement (about regional/national openehr organizations)

[Tony Shannon]

Thanks Pablo

It's great to see the proposals generate these discussions, which was
our intention as these discussions were needed..

Regarding tools, I'm a keen advocate for open source tools and believe
better tools will be key to more widespread use of openEHR..
..but know I you cant get them for free, so if we want more tools we can
share...
-the community needs to agreed a prioritised set of open source tools
-we need to establish how much they will cost
-we need to find ways to channel funds from those who need the tools to
those who are willing to do the work..

regards,

Tony

Dr. Tony Shannon
Consultant in Emergency Medicine, Leeds Teaching Hospitals
Clinical Lead for Informatics,Leeds Teaching Hospitals
Honorary Research Fellow, University College London
+44.789.988 5068tony.shannon at nhs.net


On 07/09/2011 18:49, pablo pazos wrote:
> 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
>
>  > Date: Wed, 7 Sep 2011 17:47:09 +0100
>  > From: rmhidxi at live.ucl.ac.uk
>  > To: openehr-clinical at openehr.org; Martin.Severs at port.ac.uk
>  > Subject: Re: openEHR Transition Announcement (about regional/national
> openehr organizations)
>  >
>  > Just to say, I think it would be great to support the excellent efforts
>  > represented in this discussion, to work towards locally governed
>  > repositories of archetypes/templates, evolving synergistically in the
>  > sort of way being outlined. There is an important parallel with
>  > requirements for governance of terminology.
>  >
>  > I tried very hard to align openEHR within the IHTSDO governance
>  > framework for combining local and global initiative for this sort of
>  > entity, but failed in this because the politics was too hard, as we
>  > reported at the time. IHTSDO seemed, and to me still seems to have the
>  > greatest chance of achieving useful progress towards effective standards
>  > and governance for clinical content, and openEHR should stay as close as
>  > possible to them in this, I believe. There are many clinical and
>  > professional issues still to be explored and resolved as to how
>  > terminology and archetypes should best coexist within such a framework.
>  > There are also licensing issues and realistically the licensing of
>  > archetypes for use in patient care at different levels will have to be
>  > acceptable to those groups responsible for ethico-legal standards that
>  > regulate the clinical professions, and, more immediately, for control of
>  > the licensing of international terminologies. Thus archetype/template
>  > licensing was always bound to be a very thorny and politicised issue for
>  > openEHR and, as a board charged with protecting the openEHR IP for the
>  > ultimate good of the healthcare community, we had to hear arguments from
>  > both within and outside the Foundation in deciding how we should hold
>  > the position. In truth, no one really knows how this issue will play out
>  > and we have to remain flexible in our policy, as we have said. I have
>  > been involved in working groups at a national level on reform of
>  > copyright law, where the kind of argument that is put forward within
>  > openEHR lists is advocated for publication more widely, with similar
>  > push back from interests dependent on controlling completely legitimate
>  > special interests. For what it's worth, I personally am in favour of
>  > society moving towards minimally restrictive licensing of knowledge
>  > artefacts, such as archetypes and terminologies, consistent with good
>  > order. I recognise that the many different perspectives in play about
>  > the underlying issues mean there will be fierce debate and honest
>  > disagreement about what that means and how it can be achieved. 'Twas
>  > ever thus!
>  >
>  > One of the huge difficulties I have observed over the past few years or
>  > so has been the ever growing number of ab initio and, in terms of
>  > outcome, mutually destructive, efforts to define and create standardised
>  > clinical content repositories - from hospital provider and clinical
>  > specialty to national, company product, regional and international
>  > levels. This is happening in many domains beyond healthcare, of course.
>  > There is a need for

openEHR Transition: two procedural and one licensing question

[pablo pazos]

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

openEHR Transition: two procedural and one licensing question

[Sam Heard]

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

[Sam Heard]

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

[Sam Heard]

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  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 :
>> Hi Pablo and Shinji
>> Supporting localization both technical and operational needs to be included.

openEHR Transition: two procedural and one licensing question

[Thomas Beale]

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

[Thomas Beale]

rmatics   *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: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110908/1d6fd73d/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: ocean_full_small.jpg
Type: image/jpeg
Size: 5828 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110908/1d6fd73d/attachment.jpg>