Thomas Beale wrote: > > Tim Churches wrote: >> Furthermore, if you want to add to your data, you will need to be able >> to modify the archetype definition used to store it. Thus, you will need >> > you cannot modify the definition of a released archetype. Well obviously > physically you could, but the checksum will no longer be correct, and > the tools won't use it. Instead you have to create new version(s) and > submit them to whatever is the appropriate level of QA process. (BTW - > the tools and ADL don't yet support the checksum, but it is coming, and > is technically relatively simple). > >> that right granted to you from the outset, in an explicit license, by >> the copyright holder of the archetype definition - otherwise you will >> need to beg their permission just to be able to modify how you store >> your data. >> >> > What is needed is the right to a) create new versions, and b) to create > dependent specialisations.
Yes, by "modify" I meant create new versions of archetype definitions which are owned by someone else. >> Sorry for the long-winded exposition, but these are the implications of >> moving most of the metadata and other "smarts" out from where it >> traditionally lies, which is in the back-end database schema and in >> middleware software layer, into archetype definition files. Note that >> even if the back-end database and the openEHR kernel/engine software are >> open source, if the data stored by them is done so using an archetype >> definition which does not have a suitable license, then your data is >> well and truly locked in to that archetype definition - whomsoever holds >> the copyright to the archetype definition will have your data by the >> short and curlies - just as much, if not more so, than traditional >> closed-source software does. >> >> > well, I don't know that I would go that far. It is pretty hard to claim > that data in a standardised, open format rather than a closed commercial > format is more locked into vendors. Yes, fair enough. But the issue I was hinting at is that although the openEHR technological developments aim to make systems which are "future-proof" or at least more readily upgradable to meet future needs, that promise will only be realised if end users have the necessary freedoms to do so, and those freedoms depend crucially on the appropriate licensing of archetype definitions. Perhaps this is obvious, but it had not fully dawned on me. > I would see it instead as about the > same problem as the re-usability of data that contains e.g. snomed-ct > codes or similar - the use of which are licensed by the CAP (currently, > but that should change in the future). Yes, I would agree with that. As I have opined before, SNOMED CT concept IDs should not be adopted as a lingua franca unless there is a perpetual license to use it freely available to everyone (at at least a national level). Tim C
