Dr Nigel Brown <[EMAIL PROTECTED]> wrote: > > Regarding 'We have trademarked openEHR and do not release anything > without > copyright as there is a need for an authorative publisher of > archetypes.' > As the Free Commercial Licence says: > * where you modify, adapt, incorporate (in whole or part) the > Materials or create a work (in any form) which is derived from the > Materials > (Modified Work) you must cause the Modified Work to carry a prominent > notice > stating that you changed the Materials and the date of the change in > addition to the requirements of paragraph 1 immediately above. > * on each occasion on which you supply the Materials to a third party, > you shall supply a copy of the provisions of this Free Commercial Use > Licence to the third party. You may not impose any further restrictions > on > the third party with respect to the Materials. > > Doesn't that mean that after any archetype is released out into the wild > by > the authorative publisher you've granted the right to modify and further > distribute the archetype so that any other party can thereafter act as a > provider of those archetypes as long as the fact of modification is > noted.
Yes, that's correct. > Thus all commercial EHR's will quickly diverge to a set of non-aligned > versions. No, not necessarily. The situation is directly analogous to open source software. Anyone can modify such software and redistribute their modified version of it. That is called a "fork" of a software project. Common sense suggests that forks would happen all the time, because there are millions of programmers out there capable of making such forks, just as there are millions of health professionals out their capable of making changes to openEHR archetypes. However, in practice, forks of open source software projects happen rather rarely. The reason is that it is almost always easier to feed back desired chnages and improvements to the original authors for incorporation in a revised version of the original software, than it is to strike out on your on and start to support and maintain your own, independent, incompatible version. Where forks do occur, often due to personality differences as much as technical disagreements, they often peter out, or end up rejoining with the main project. Equally commonly, forks occur amicably and are intended as exploratory exercises. Sometimes there really are differing needs that can't be accomodated with a single software project. So, one would hope that the sociology of open source archetypes is similar. That remains to be seen. One difference is that there is a high overhead in maintaining a fork of a complex piece of software, whereas a fork of a single archetype involves far less of a commitment of future time and effort on the part of the forker. However, archetypes are intended to form a complex, interdependent fabric, and a fork of a whole raft of archetypes is a large commitment to the future. The other thing to remember is that archetypes are designed with backwards compatibility in mind - far more so than with software, where even the smallest chnage can render software code incompatible. By contrast, the archetype framework encourages specialisation which is still backwardly compatible, but makes incompatible forking much harder. Having said all that, I think that the idea that one set of achetypes or standards can meet all needs is a pipe dream, and that there are real advantages to moderate degrees of plurality. It is a bit like human language. As an Australian, you are not forced to speak English, although it is vastly more convenient to use English in most day-to-day dealings with others than not. But sometimes it is better to deal with certain groups of other people using other languages. > As Hugh Leslie wrote: > "You are absolutely right that having a centralised archetype repository > that > is properly managed is important. openEHR won't work if everyone is > using > different archetypes for the same thing." > but as a centralised repository isn't enforced by the licence isn't the > practical conclusion therefore that 'openEHR won't work' ? Or perhaps > that > the defacto central repository will be the repository of modified > archetypes > maintained by the dominant commercial player? Yes, it takes time and effort to maintain a repository. There may well be more than one, but there is unlikely to be an unmanageable number. And having a handful of them may be better than having just one. Tim C > -----Original Message----- > From: Sam Heard [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 4 January 2006 9:20 PM > To: [EMAIL PROTECTED]; General Practice Computing Group Talk; Dipak > Kalra > Subject: Re: GP Requirements - was [GPCG_TALK] Re: The Dreaming > > > Tim > > I think this is a very helpful suggestion. We have trademarked openEHR > and > do not release anything without copyright as there is a need for an > authorative publisher of archetypes. The openEHR Foundation will not > accept > any archetypes that are not free to use to be labelled with openEHR. > > Cheers, Sam > > Tim Churches wrote: > > Dr Nigel Brown <mailto:[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > wrote: > > > > I also note the "copyright (c) 2004 Ocean Informatics" on the archetype. > > > > > > See http://www.openehr.org/about_openehr/t_licensing.htm > <http://www.openehr.org/about_openehr/t_licensing.htm> for details of > the > licenses under which this and other openEHR material is distributed. A > reminder: open source does not mean "no copyright" - in fact, the > opposite: > open source licensing relies on assertion of copyright and observance of > copyright law. However, the copyright holder then uses an explicit > license > to grant additional rights to end users, as copyright law permits the > copyright holder to do. > > > > However, I think that it would be useful to provide a pointer to the > licensing provisions in each and every archetype published by openEHR > (and > others) - make it part of the archetype metadata. > > > > Tim C > _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
